SMS-based Authentication for Remote Access to Corporate Networks

advertisement
SMS-based Authentication for Remote Access to
Corporate Networks
Joachim.Posegga@SAP.com
Remote Client Authentication based on One Time Passwords
A common solution for authenticating remote clients connecting (e.g. over phone lines)
into corporate networks are one-time passwords (OTPs), e.g. based on SecurID as shown
in Figure 1; the procedure is essentially as follows:
Figure 1: Remote Client Authentication Using a Trusted Device
Prerequisite: Both the client and the server have one time password generators OTPC and
OTPS which are synchronized, i.e.: identical random numbers are generated with the
same time slot. The following authentication procedure can be used
1. Client connects to the Server, e.g. over a phone line to a modem pool.
2. Client transmits identification (User-ID) and the current one time password OTPC
3. Server compares OTPC against OTPS, the client is authenticated if both are equal.
The scenario usually involves also a PIN known to both sides: this PIN is either used for
the computation of OTPC and OTPS, or the client transmits both the PIN and OTPC to the
server.
The security of this authentication procedure relies upon the device generating OTPC,
which is a trusted source for one time passwords. The PIN prevents unauthorized usage
of OTPC. There are known attacks to this procedure, but these are real-time attacks which
are hard to carry out in practice.
Replacing OTPC by GSM Short Messages
If the server trusts in authenticity of the GSM signaling channel, and there is a GSM
phone capable of receiving SMS on the client side, then the device for generating OTPC
becomes superfluous (cf. Figure 2):
Figure 2: Remote Client Authentication using SMS
1. Client connects to server and transmits user ID
2. Server looks up the corresponding MSISDN of the client’s GSM phone
(alternatively: client transmits MSISDN)
3. Server generates a one time password OTPS and transmits it to client’s GSM
phone over SMS
4. Client transmits the received one time password to Server
5. Server compares the received password to OTPS and the client is authenticated if
both are identical.
As in the previous scenario, a mutually known PIN (transmitted from the client to the
server) can be easily included into this procedure.
Comparison of both Approaches
The basic differences between both authentication procedures are:
1. Cost
A SecurID card costs about 60 Euro and lasts for max. 5 years; one SMS is about
0.02 Euro for corporate contracts. If dial-in is used once per working day (which
is a lot), the SMS-approach adds up to 200 * 5 * 0.02 Euro = 20 Euro in 5 years.
Furthermore, there are no costs for handling the SecurID cards, etc.
2. Availability/Reliability
The SecurID token is an offline device, while the SMS-based approach depends
on the GSM network service. There is no guaranteed QoS in SMS, so latency can
be a problem. Although SMS usually arrives within 5-10 seconds in practice, the
SMS solution is less reliable than SecurID.
3. Additional SMS-based security
The SMS-based approach has the advantage that a user will realize attempts of
unauthorized dial-in, since an SMS will be received. This is not the case with
SecurID
4. Technical aspects of the dial-in procedure.
The client can transmit to all information needed for authentication when the
initial connection to the server is made with a SecureID solution; in the SMSbased case, the client needs to wait for an incoming SMS from the server before
all required information for authentication is available. This means that dial-in
scripts must be (slightly) adapted.
Most remote access procedures (dial-in scripts) should be able to cope with this. It
integrates nicely into callback procedures, but also one-step dial-in procedures
should be able to cope with an additional user interaction for querying the
password that arrived after the dial-in was initiated by the client. (In fact all all
SecurID authentication procedures require the server side to prompt the user for a
second one time password; this is needed if the clocks of both tokens got out of
sync.).
Download