mailing list archives
Re: SMS Banking
From: Sunnet Beskerming <info () beskerming com>
Date: Wed, 10 Feb 2010 23:13:30 +1030
I don't normally weigh into mailing list arguments, especially not those spammed across multiple mailing lists (yeah, I
know this reply does that, too), and it's hard to find the appropriate point to interject comments, but this exchange
has stirred the blood and irritated me to the point of throwing out my own point of view. I'm not sure if we have all
just been trolled expertly, but it seems serious enough to reply.
Thor, the following isn't really directed at you, I just chose your message as the one to reply to.
First, some background. It has been a number of years since I formally studied statistics and failure modelling,
though I am fairly current on James Reason's human failures modelling as it applies to aviation and at least one
variant of risk management modelling and mitigation (even if it is largely a crock the way it is implemented). As a
result, there may be some errors in my arguments below.
I read through the post that Craig has placed online and there are a couple of seemingly critical faults in the model
that have a massive effect on the overall reliability / strength against attack / resilience / number of kittens per
square inch saved that a system displays.
It looks like Craig has defined parts of his model too narrowly, claiming that the probability of compromise is only a
factor of the risk of compromise of the SMS system and the user authentication methods, which he claims are independent.
They are, to a point, and this is where I think Thor has the edge and will ultimately triumph in any real world test.
The factors are related, since most SMS systems are utilised as a second channel of authentication, but ultimately all
the critical communications for a transaction session pass through the user's web session, where they have already
provided their static user authentication (it doesn't really matter if we talk about pRNGs, it's static for the purpose
of the transaction session). It also doesn't matter whether the SMS is provided as transaction authentication, second
channel authentication, or whatever, it ultimately provides the financial institution with a means to try and make the
user liable for any subsequent breach.
The common weak point is the computer system.
It could be argued that the system is really part of the user authentication method, being critical to the method
actually working, but it doesn't really fit into Craig's formuala. The P(compromise) he puts forward is more the
probability of compromise of the system prior to the transaction commencing, since it can be considered completely
independent from the computer system at this stage.
If the user has had their mobile stolen and the thief also happens to know their authentication details, the compromise
is complete, and the thief can then authenticate happily and Craig's formula holds up.
The downfall is that if this doesn't take place and the system being used for the transaction has been compromised,
then the model has failed. It doesn't matter what the original probabilities were for the user authentication or the
SMS system were, the fact that the computer system is compromised means that the probability of compromise is now 1.
Pushing past this probability, the modelling used for expected system life (failure modelling) doesn't seem to match
with what reality seems to indicate. To fit an exponential failure density function, it implies that any system is
secure when initially released, rapidly becoming more insecure, to an inflection point whereupon the rate of insecurity
increase tapers off over time, never becoming completely insecure.
Again, this is true to a point. The problem is that the full failure model is not taken into account, merely the
introduction of the lifecycle when the product comes out of Beta testing. The system starts inherently insecure,
gradually increasing in security during development, until at release, it is relatively secure. Immediately following
release, glaring errors are quickly found and this represents the exponential failure density function Craig puts
forward. This may or may not be a significant jump, but it does baseline the security of the system into the longer
A system that is maintained displays more of a sawtooth curve along this long-term period, ideally improving
reliability following maintenance, but history has shown that the curve can trend towards more security or less, each
time maintenance is applied. If the system is not maintained, and even if it is, then it may be a significant period
of time before its security is fundamentally broken. At the point that security is broken, it can be considered that
the system is completely failed. With the key requirement to enact failure being knowledge and system accessibility,
the moment that knowledge is public, or shared, then the system is inherently insecure. Taking the overall system
lifecycle (including development) into account, this gives a bathtub curve, with a sawtooth following system release
and following maintenance activity.
The ASCII Insecurity vs Time curve.
\ ____ ___|\----/
1 2 3 4 5
1 - Development and release - one of the most secure points in the product lifespan
2 - Craig's failure model - immediately post release, insecurity jumps as obvious issues are found, but then tapers off
into maintenance mode
3 - System maintenance - system security is improved, but bugs are introduced that are found over time, returning
security to previous levels
4 - System maintenance - reactive maintenance to a security problem (the uptick at the start), however the baseline
system security is now more insecure
5 - Inherent Insecurity - security is fundamentally broken and either no maintenance is possible, or it is no longer
maintained. Sharing of knowledge makes any system implementation after this time inadvisable without other protections.
The problem faced is how do you know when the curve is going to tick up (or in Craig's models shoot down) at the end of
the viable secure lifespan? Thor's argument is that you don't. It is effectively impossible to reliably predict when
this will take place, but until it does it makes the modelling Craig puts forward seem relatively viable. The downside
is that it doesn't work as a reliable predictor, and you're going to be left stuck when the uptick takes place, having
been encouraged to place faith in a model that doesn't appear to replicate the overall lifecycle effectively.
The slanging match that evolved has seemed to hinge on this. Craig argues that he can reliably predict system security
using his models, while Thor says he can't. In the testing proposed, Craig asserts that his model will work (even
though it has just been shown to only affect a very small section of the overall product lifecycle), while Thor's goal
is to bring the end of the bathtub curve (the uptick) as far forward as he can. With the vagaries and difficulties
associated with development, and the problem that no one really understands the security domain well enough to have a
really secure product that is actually usable, backing Thor and his team would be a very safe bet. Even if the bathtub
curve can't be completely shortened, enough of an uptick can be caused (the sawtooth bits) to exceed any threshold set
Ad hominem attacks aside, I think Thor definitely has the upper hand in this particular case. It is not possible to
effectively predict when these upticks in insecurity are going to take place, nor how significant they are going to be,
only that they will take place (the old when, not if argument) and this has a real, definite effect on system security
predictability. For all the fudge factors involved, you might as well use the Drake Equation as a quantitative
predictor of system security.
Just some discussion points, that's all.
info () beskerming com
Since we're spamming internet posts, the following discuss some of the issues with trusting SMS details just a little
 - http://www.beskerming.com/commentary/2005/10/31/65/'Tis_a_Fragile_Thing
 - http://www.beskerming.com/commentary/2006/01/02/74/An_Inauspicious_Start
 - http://www.beskerming.com/commentary/2007/05/25/96/Free_Flight_Deal_Exposes_Customer_Data
On 10/02/2010, at 4:09 AM, Thor (Hammer of God) wrote:
I'm looping in the FD list because often my replies don't make it to Pen-Test, and this has hit a nerve with me.
I've looked over your post at:
Once I was able to get past the overwhelming egoism and self-substantiating claims of your contributions to the
industry, I arrived at the conclusion that the only portion of the aforementioned page that is not complete drivel
and even laughable to anyone who has actually worked towards ascertaining actual risk in production environments, is
where you describe your own words as "ravings." Ravings, of course, means "delirious, irrational speech."
I'm fine with you sitting back and gloating about the Security Hero award you got from Northcutt, but when I see that
you are actually contributing to ANY level of Critical Infrastructure Protection, it makes me fear for anyone who
might be counting on your presumed skillset to actually make intelligent decisions about risk where human safety is
at stake. Your "risk formula" is ridiculous. What number would your formula have yielded 2 weeks before SQL Slammer
was released? Where is the variable for unpatched systems? What number do we plug in for malicious employee
factorization? More importantly, where is the calculation for self absorbed snake-oil selling academics with no
real experience using their calculator to come up with magic numbers that represent the risk of a nuclear power plant
Since you are (self-described) as "currently the only GIAC GSE (Compliance) holder globally and the most highly
accredited Global Information Security Professional" and thus (presumably, if only in your mind) the greatest
security mind in the world, how about accepting a challenge to an open debate on the subject at Defcon? People like
you are dangerous and need to be exposed before someone in a position of power actually believes that you know what
you are talking about. Bring your abacus.
From: Craig S. Wright [mailto:craig.wright () Information-Defense com]
Sent: Monday, February 08, 2010 3:40 PM
To: Thor (Hammer of God); pen-test () securityfocus com; security-
basics () securityfocus com
Subject: RE: SMS Banking
" And just how do you come up with the probability of compromising the SMS function and the user authentication
Actually, fairly simply using Bayes' formula.
I have posted on this at:
The comment was that GSM itself can be made more secure if it is coupled with another means of securing the
"if one can position one's self anywhere in the transmission chain." This is a select number of locations. It is
not everywhere. Though the number of locations may be large - it is not infinite. It is also not all points on the
As can be seen in the post, what the effect of an SMS only based solution is a time degrading function. This is, the
longer that the SMS application runs (alone), the greater the risk until eventually, the risk is maximised at
Adding a second function, such as a non-SMS based sub-function can help to mitigate this, but a well chosen
sub-function is more effective alone without the addition of the SMS measure and hence a better option.
The SMS function alone can befit from a second function, but this is only warranted if the SMS function is an
essential process for some reason.
... irrelevance cut for brevity ...
Where a system uses an SMS response with a separate system (such as a web page), the probability that the banking
user is compromised and a fraud is committed, P(Compromise), can be calculated as:
P(Compromise) = P(C.SMS) x P(C.PIN)
Where: P(C.SMS) is the probability of compromising the SMS function and P(C.PIN) is the compromise of the user
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
Re: SMS Banking Craig S. Wright (Feb 10)
Re: SMS Banking Sunnet Beskerming (Feb 10)
FW: SMS Banking Thor (Hammer of God) (Feb 10)
FW: SMS Banking Thor (Hammer of God) (Feb 10)
- Re: Risk measurements, (continued)
- Re: SMS Banking Christian Sciberras (Feb 11)