Re: Username password VS hardware token plus PIN

["Kevin Sheldrake" <kev () electriccat co uk>]

Frank Knobbe wrote:
<SNIP>
> That's why I was never happy with SecureID tokens since the PIN is
> transmitted during logon and thus subject to interception by an
> attacker. I preferred tokens that require the PIN to unlock the token,
> but never transmit the PIN.

Hashing the PIN+OTP locally would produce a different hash each time.  The  
PIN would never be transmitted, but the user experience would be identical  
to current systems where it is.  I don't know if this is how any token  
systems work; I just thought I'd chuck it in.

The main reason for the post is because I have a problem with PINs that  
unlock tokens (or smart cards for that matter) in order for some  
credential from the token to be used for authentication (in isolation of  
the original, or any other, PIN or password).  While I appreciate that the  
user requires "something he knows" (to unlock the token) and "something he  
has" (the token) in order to log in, I disagree that an attacker would  
necessarily require both.

Imagine a token (smartcard, PDA, smart phone, whatever) that usually  
operates in this fashion, but can be made to reveal its workings after it  
has been successful attacked.  In this situation, it would be possible for  
the attacker to steal the "something he has" and produce valid  
credentials.  In the case where the "something he knows" is transmitted to  
the server (or combined with the OTP and hashed locally) this would not be  
possible.

> The token alone should never be enough to let you log in.
<SNIP>

Exactly! :)

BTW, the "something you are" (biometrics) always makes me chuckle.  Using  
fingerprints for authentication is like writing your password on every  
surface you touch.  It doesn't take much imagination to conceive of  
devices that could scan faces, the iris, the retina, etc, yet appear  
innocuous.  It all depends how much you want the credentials.

Of course, specific biometric implementations do not need to fall foul of  
this vulnerability; when we (the industry) get past the hype and debate  
actual architectures, we might come up with something usable and secure. :)

Kev



--
Kevin Sheldrake MEng MIEE CEng CISSP
Electric Cat (Cheltenham) Ltd

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards