On Fri, 11 Jan 2013, John Stoffel wrote:
"Tracy" == Tracy Reed <[email protected]> writes:
Tracy> On Fri, Jan 11, 2013 at 08:41:35AM PST, Bryan Ramirez spake thusly:
at work we're having a discussion about 2 factor authentication. We're
comparing the traditional RSA token with Symantec's VIP Access solution.
Tracy> Be sure to consider Google Authenticator. It is free, a well-studied open
Tracy> standard (always a good thing in crypto) and hasn't been hacked in the
past
Tracy> (unlike certain other solutions).
We use both the traditional RSA tokens, plus some of us have their
soft-tokens on our BlackBerry phones, which is convenient. And I
*still* need to enter a pin into the device to get back a number to
punch in to access my VPN. So it's still two factor.
One problem I have with every commercial soft token that I have every seen is
that an attacker that gets their hands on the system running the soft token can
brute force the PIN
Even if the soft token wipes itself after too many failed logins, the attacker
can just restore from backup and try again until it wipes (it slows them down,
but since PINs tend to be rather weak, I don't think it makes it hard enough)
What soft tokens should do is accept any PIN and give a response, but do it in a
way that makes it so that the response will not be valid if you give it the
wrong PIN
My approach to this is to hash the PIN and then XOR the result with the seed/key
that's stored in the soft token. If you give the wrong PIN, the soft token will
be using the wrong seed/key and give the wrong answer. The only way the attacker
can check if it's right or not is to try and login to your system. This gives
you at least a chance of detecting multiple failed login attempts and locking
the user at the server side. This doesn't work if the attacker can just use a
keylogger to collect the PIN, so I would still require that the soft token not
be on the laptop that they are using to access the system (even on a phone it's
two devices the attacker needs to compromise)
Personally, I like the challange/response token approach where the server sends
me a random number, the token encrypts it with the shared secret, displays part
of the result, and I type that response into the server. This isn't quite as
convienient as the time-based tokens that just change their displayed value
periodically, but I think it's more secure.
David Lang
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
