RE: SMS Banking

["Thor (Hammer of God)" <Thor () hammerofgod com>]

And just how do you come up with the probability of compromising the SMS function and the user authentication method?

While little formulas may go well in meetings, this hardly helps the OP with his question.  You also failed to note 
that the overall risk figure you calculate has to be compared to something - what are you comparing it to?  If 
P(Compromise) turns out to be 42, what does he do with that information?

Regarding GSM, what "far more" information are you talking about?  The account number and PIN is all that is needed in 
the example given by the OP, and that is exactly what one would get from a GSM attack.

You should also note that "compromising GSM" is completely unnecessary if one does in fact have a select number of 
locations where the actual GSM signal is redirected.  Cracking GSM itself does NOT require being at a "select number of 
locations" if one can position one's self anywhere in the transmission chain.  

t

> -----Original Message-----
> From: listbounce () securityfocus com
> [mailto:listbounce () securityfocus com] On Behalf Of Craig S. Wright
> Sent: Sunday, February 07, 2010 8:06 PM
> To: 'Markus Matiaschek'; 'M.D.Mufambisi'
> Cc: pen-test () securityfocus com; security-basics () securityfocus com
> Subject: RE: SMS Banking
>
> The solution needs to be based on risk.
>
> 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 authentication
> method
>
>
> The user can be compromised by Trojan apps, poor pins that are pasted
> to a
> monitor etc.
>
> P(C.SMS) and P(C.PIN) are statistically independent and hence we can
> simply
> multiply these two probability functions to gain P(Compromise). The
> reason
> for this is that (at present) the SMS and web functions are not the
> same
> process and compromising one does not aid in compromising another. With
> the
> uptake of 4G networks this may change and the function will not remain
> as
> simple.
>
> It may be possible to compromise GSM, but the truth is that this must
> be
> done from a select number of locations and the attacker also requires
> far
> more information than the PIN and account number. This makes the attack
> far
> more difficult and far costlier to the attacker.
>
> This also means that the attack has to be targeted in place of scripted
> (as
> many bots already are).
>
> On the other hand, the probability that an SMS only system can be
> cracked is
> simply the P(C.SMS) function and this is far lower than a system that
> deploys multiple methods.
>
> This SMS only means would not be a good means of authentication a user.
> As a
> secondary factor, SMS adds complexity. By itself, SMS is a poor means
> of
> controlling risk.
>
> Regards,
> ...
> Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> Information Defense Pty Ltd
>
>
> -----Original Message-----
> From: listbounce () securityfocus com
> [mailto:listbounce () securityfocus com] On
> Behalf Of Markus Matiaschek
> Sent: Saturday, 6 February 2010 9:08 AM
> To: M.D.Mufambisi
> Cc: pen-test () securityfocus com; security-basics () securityfocus com
> Subject: Re: SMS Banking
>
> Hi,
>
> I'd just like to make some comments, i didn't think about a solution
> for your problem.
>
> First of all i think that my Budi wibowo got something wrong regarding
> who is sending the PIN.
>
> Second, GSM is cracked: http://reflextor.com/trac/a51 and can be
> intercepted and decrypted. You should take this into account.
>
> Third i think the only farely safe way to make money transfers is with
> transaction numbers, TANs. German banks send mobileTANs to
> preregistered cell phone numbers to allow a transaction (through
> online banking though).
> A "three-way-handshake" with a mTAN should pretty much prevent
> transactions through spoofed numbers.
>
> regards,
> Markus Matiaschek
> Absolute IT Consulting S.A.
> San José, Costa Rica
>
> -----------------------------------------------------------------------
> -
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an
> SSL
> certificate.  We look at how SSL works, how it benefits your company
> and how
> your customers can tell if a site is secure. You will find out how to
> test,
> purchase, install and use a thawte Digital Certificate on your Apache
> web
> server. Throughout, best practices for set-up are highlighted to help
> you
> ensure efficient ongoing management of your encryption keys and digital
> certificates.
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be44
> 2f727
> d1
> -----------------------------------------------------------------------
> -
>
>
> -----------------------------------------------------------------------
> -
> This list is sponsored by: Information Assurance Certification Review
> Board
>
> Prove to peers and potential employers without a doubt that you can
> actually do a proper penetration test. IACRB CPT and CEPT certs require
> a full practical examination in order to become certified.
>
> http://www.iacertification.org
> -----------------------------------------------------------------------
> -


------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------