[unisog] Admin Access to Servers

Saqib Ali docbook.xml at gmail.com
Sat Nov 25 22:40:20 GMT 2006

This is pretty cool. I was looking for something like this. I
especially the 2 logon failure = successful login policy. It is
important to have such functionality.


On 11/23/06, Farmer, Jacob <jpfarmer at indiana.edu> wrote:
> 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
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog


More information about the unisog mailing list