Sms based otp

SMS-based Two-Factor
Authentication
SMS-based Two-Factor Authentication - Risk analysis
© 2005 VASCO Data Security. All rights reserved. Page 1 of 11
Risk analysis

Disclaimer
Disclaimer of Warranties and Limitation of Liabilities
All information contained in this document is provided 'as is'; VASCO Data Security
assumes no responsibility for its accuracy and/or completeness.
In no event will VASCO Data Security be liable for damages arising directly or
indirectly from any use of the information contained in this document.
Copyright
© VASCO Data Security 2005. All rights reserved.
Trademarks
DIGIPASS and VACMAN are trademarks of VASCO Data Security.
All other trademarks are trademarks of their respective owners.

Table of Contents
Disclaimer ...................................................................................................... 2
Table of Contents............................................................................................ 3
Reference guide....................................................... Error! Bookmark not defined.
1 Introduction.............................................................................................. 5
2 SMS-based two-factor authentication ....................................................... 5
2.1 SMS-based user authentication ............................................................. 6
2.2 SMS-based transaction authentication.................................................... 7
3 Threats ..................................................................................................... 8
3.1 Security............................................................................................. 8
3.1.1 Security of SMS-based user authentication .......................................... 8
3.1.2 Security of SMS-based transaction authentication................................. 9
3.2 Reliability......................................................................................... 11
3.3 Cost ................................................................................................ 11
4 Conclusion .............................................................................................. 11

Document history
Version Author Comments Date
1.0 Frederik Mennes Creation of document October 17, 2005

1 Introduction
This document analyses the risk associated with deploying SMS-based two-factor
authentication.
Section 2 presents the concept. Section 3 outlines a number of threats. We draw our
conclusions in Section 4.
2 SMS-based two-factor authentication
In this section, we shortly describe the concept of SMS-based two-factor
authentication.

2.1 SMS-based user authentication
When a user wants to authenticate himself to the Internet banking application of a
bank, the process goes as follows (see Figure 1):
• The user surfs to the Internet banking application and provides his username
and static password to the application. The application sends username and
password to the banking server. The banking server verifies the
username/password combination. (Steps 1, 2)
• If the combination is valid, it generates a one-time password. The banking
server sends this one-time password to the user via an SMS-message. (Steps
3, 4, 5)
• Upon receipt of the SMS-message, the user provides the Internet banking
application with the one-time password. The application sends this one-time
password to the banking server. (Steps 6, 7)
• The banking server verifies whether or not the one-time password provided by
the user matches the password it has sent out. If this is the case, the user has
successfully been authenticated. (Step 8)
Figure 1: SMS-based user authentication

2.2 SMS-based transaction authentication
We assume here that the user has successfully logged into the Internet banking
application. When a user subsequently wants to sign the data of a financial
transaction, the process goes as follows (see also Figure 2 below).
• The user enters the data of the financial transaction (e.g. amount, account)
into the Internet banking application. The application sends this data to the
banking server. (Steps 1, 2)
• The banking server generates a signature and sends this signature, together
with the transaction data, to the user via an SMS-message. (Steps 3, 4)
• Upon receipt of the SMS-message, the user verifies whether or not the data in
the SMS-message match his transaction data. If they match, the user provides
the Internet banking application with the signature and transaction data. The
application sends this signature to the banking server. (Steps 5, 6, 7)
The banking server verifies whether or not the signature provided by the user matches
the signature it has sent out. If this is the case, the financial transaction is conducted.
Figure 2: SMS-based transaction authentication

3 Threats
3.1 Security
3.1.1 Security of SMS-based user authentication
Following attacks are possible against SMS-based user authentication as described
above :
• Eavesdropping. SMS-based two-factor authentication systems are
characterized by the fact that the end-user does not control the generation of
the one-time password. On the contrary, it is the bank that provides the user
with the one-time password. This delivery process may give rise to a weak link
in the authentication system, because several entities can eavesdrop on the
communication link between bank and end-user. The eavesdropper can then
use the one-time password himself, effectively impersonating the genuine user.
o Members of staff of the bank can learn the one-time password.
o The link between bank and operator can be eavesdropped.
o Members of staff of the telecom operator can learn the one-time
password.
o The link between operator and user can be eavesdropped (only the link
from the base station to the mobile phone is encrypted in case of GSM).
• Man-in-the-middle attack. An adversary can lure a user to a fake web site,
and have the user disclose its username/password/one-time password. When
the user authentication has been performed, the adversary hijacks the banking
session, conducting transactions on behalf of the user. This is a real-time
phishing/pharming attack, where the adversary monitors the traffic between
bank and user.

3.1.2 Security of SMS-based transaction authentication
An adversary can conduct man-in-the-middle attacks against SMS-based transaction
authentication. We differentiate between two types of man-in-the-middle attacks.
A) Adversary controls traffic between user’s PC and bank
A number of different man-in-the-middle attacks are possible, depending on the
nature of the signature:
• Signature is random number. Suppose that the signature is a random
number. The adversary watches the traffic between the banking server and the
user. When the user has entered the signature into the banking application, the
adversary changes the transaction data (e.g. amount, account). If the banking
server does not check the data again, the adversary’s transaction will be
executed.
• Signature is hash. Suppose that the signature is actually a hash of the
transaction data, computed using, for example, SHA-1, SHA-2, RIPEMD-160,
etc. Suppose also that the adversary learns which hash function is used to
compute the hash values. When the user has entered the signature into the
banking application, the adversary changes the transaction data (e.g. amount,
account) and hash. If the banking server only checks whether or not the data
and signature match, the adversary’s transaction will be executed.
• Signature is Message Authentication Code (MAC). Suppose that the
signature is actually a MAC of the transaction data, computed using a secret
key. In this case, the adversary is not able to compute matching data/signature
pairs of his own, because he does not possess the secret key.
Figure 3

In order to protect against these attacks, we have following recommendations:
• Do NOT use random numbers as signatures.
• Do NOT use hash values as signatures.
• Do use Message Authentication Codes (MAC’s) as signatures.
• Do verify whether the submitted signature matches the received signature.
• In Step 7, send only the signature, and not the transaction data, or verify
whether or not the transaction data are always the same.
B) Adversary controls traffic between user’s PC and bank and between bank
and mobile phone
In this case, the adversary can launch very powerfull attacks. When a user submits a
transaction, the adversary hijacks the session between user and bank. He then
changes the transaction data at his will, and submits the new transaction. The bank
generates a signature and sends an SMS-message to the genuine user. However, the
adversary intercepts the SMS-message and conducts his transaction.
This type of fraud can typically be conducted by members of staff of the telecom
operator, as they have full control over the SMS-messages. However, an adversary
can also conduct this type of attack if he intercepts the traffic between bank and
operator or between the operator and the mobile phone.
Figure 4

3.2 Reliability
Following factors influence the reliability of SMS-based two-factor authentication.
• SMS delay and loss. According to a study of KeyNote Systems, Inc.
(http://www.keynote.com), an average of 94.7 % of SMS-messages arrive at
their destination in an average of 11.8 seconds. This means that 5.3 % of the
messages arrives late or does not arrive at all. As an example, if you have
100,000 customers requesting one SMS-message per week, 5300 messages
will arrive late or get lost every week.
• Coverage. In order to receive an SMS-message, one has to be in an area with
coverage for cellular phones. If this is not the case, it is not possible to conduct
an Internet banking session.
• User acceptance. Not everyone has a cellular phone, and not everybody
knows how to read SMS-messages.
3.3 Cost
• Sending SMS-messages to customers comes with a certain cost. The cost per
SMS-message is dependent on the local mobile phone operator, but $0.10
might be a possible average.
• Moreover, the cost of sending SMS-messages is ever-increasing, hence not
fixed. For example, if a customer requests one SMS-message per week, this
would cost already $5 per year if an SMS-message costs $0.10.
Users might not be happy to pay for this cost.
4 Conclusion
It is up to the bank to assess the potential impact of the threats presented above. The
bank then has to decide whether or not the risk is acceptable.

Sms based otp

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Sms based otp

Similar to Sms based otp (20)

More from Hai Nguyen

More from Hai Nguyen (20)

Recently uploaded

Recently uploaded (20)

Sms based otp