[unisog] Admin Access to Servers

Farmer, Jacob jpfarmer at indiana.edu
Fri Nov 24 03:08:23 GMT 2006


We use Secure Computing's SafeWord cards, which are not time-dependent
tokens, and they solve this problem in what I think is an ingenious way.
I've included an excerpt from one of their whitepapers
(http://www.securecomputing.com/index.cfm?skey=969) below.

It's worked really well for us and, in my opinion, are much more
convenient.

Jacob

========================================
Now let's suppose that Bill is all excited about his new authentication
token and walks around showing it to eight of his buddies. Each time, he
generates a new password but does not actually login. The counter in his
token now is set to nine. The counter in his record on the
authentication server however is still set at one. 

Now Bill goes back to his desk and attempts to login again. His token
increments the counter to 10, encrypts it and let's say the resulting
password is "732E0F." He enters it and it eventually gets to the server.
The server decrypts it and gets 10. Although it was expecting a value of
2, the authentication server automatically updates Bill's counter to 10
and grants Bill access to the system. Why did it allow him in? Because
the server can accept up to the next 16 passwords from Bill as all being
correct and still maintain a security ratio of one in a million odds.
The server will accept any of the next 16 passwords from Bill at all
times. 

Let's do the math. 16,777,216 possible passwords and at any given time
16 of them are correct. Dividing both sides by 16 we see that the odds
are 1 in 1,048,576 that an attacker would supply the correct password.
We can improve the odds by 16 times by using 7 character passwords if we
want, or even more with 8 but since we meet the standard, this is
sufficient for all but the most stringent situations. 

Now what would happen if Bill advanced his token 17 or more times ahead
of the counter in the server? First of all, that is pretty unlikely.
Bill would have to turn on his token, enter his PIN, get a password and
repeat that process at least 17 times. Even our huge customers with
hundreds of thousands of users tell us this rarely if ever happens
unless it is done intentionally to test that the system works. But let's
say Bill does this and gets the counter to say 50. When he next tries to
log in, the authentication server denies access because it is further
than 16 ahead of the expected value. However, the authentication server
makes a notation in Bill's record and saves the decrypted value of 50.
Bill meanwhile scratches his head and says "Hmm, I thought I entered
everything correctly? I guess I better try again." The second time
around the authentication server gets the value of 51. It then updates
Bill's counter to 51 and grants him access. It can do this because the
odds of a hacker being able to correctly present two correct passwords
back-to-back are enormously low. Much lower, in fact, than one in a
million. The server knows it has to be Bill, who is happily
resynchronized and connected. No involvement from a system administrator
is ever necessary. 
========================================

-----Original Message-----
From: unisog-bounces at lists.dshield.org
[mailto:unisog-bounces at lists.dshield.org] On Behalf Of Russell Fulton
Sent: Thursday, November 16, 2006 8:43 PM
To: unisog at lists.dshield.org
Subject: Re: [unisog] Admin Access to Servers

<...snip...>
We have had some grumbles from admins about requiring multiple 2FA log
ins (worst case 3 -- ssh gateway, account login, sudo) with up to a
minute wait for the token to role over (we are using RSA).  We did
consider 'crypto card' which had a feature that allow you to get the 
next number without waiting, the down side is that it is easy to get the
card out of sync by pressing the next button too many times (five ?). 
This requires the  tokens to be physically returned to base for
resynching.   We had visions of kids playing with keys and discovering
that they can change the number by squeezing the token -- hello! Mum(or
Dad;) is now locked out!  We were also worried about the less robust
nature of the tokens with a physical switch in them.

Cheers, Russell.
_______________________________________________
unisog mailing list
unisog at lists.dshield.org
https://lists.sans.org/mailman/listinfo/unisog



More information about the unisog mailing list