Folks might dig this...
Emerson, Tom (*IC) wrote:
> OK, now that I've got John busy reconfiguring his security system,
*snickers*
I've got a question for the rest of you: how "secure" do you think the
"safeword" password token generator is?
I haven't worked with this one in particular, but am familiar with the
RSA brand.
They are quite secure.
>
> [trick question, I know, because safeword was bought by McAfee]
:)
Let me clarify my above statement. The theory is sound, and the
particular reduction to practice by RSA inc is considered to be quite
secure.
>
> On the surface, I'm not convinced (as you might guess, I've recently been assigned one of these) There are two models they talk about - one that you need only "push a button" to get the (next) "one-time" password token, and another where you need to enter a "pin" and it will generate the next token for that PIN. (and a third option is proprietary software loaded onto your system or blackberry/phone)
The ones from RSA automatically produce the next number, others have you
request it.
In some of the documents, they mention that the tokens can be either
"time based" or "event based". (and I presume "event" means "token
generated", since I don't see any way the fob you carry and back-end
"validating" server would otherwise agree on what an "event" is)
I would say this is a correct analysis, but am not familiar with the
particular reduction to practice used by your vendor.
>
> The card generates what appears to be a 6 (hexadecimal) digit value (i.e., 3 bytes) I have the one where you enter a 4 (decimal) digit PIN (and per related documents I've received, if you get the pin "wrong", it generates an invalid token) Just breaking it down on that aspect alone, the token generator can generate up to 2^24 tokens of which (for the PIN based ones) 1 in 10000 are legit -- someone please check my math, because I only come up with 1677 valid passwords for the life of the token generator! (2^24 / 10000) heavy use of the device (10 validations/day) would kill that in less than half a year! (though I suspect "typical use" might be twice a day/weekdays only/50 work-weeks per year, or about 3 years of useful life [2 * 5 * 50 = 500 uses/year])
>
They are reissued every N years as a matter of course. Your correct. I
didn't validate your math, but 3 to 5 years is par for the course. Again
your particular implementation should be verified by your organizations
security personnel against their specific policies.
> Then there is the challenge of tracking "use" of the tokens - I can think of two methods (and I have an idea as to which was used) The "validating" server can generate every valid token and store that as some form of list, "crossing off" each token as it is used [more realistically, a 16-million-bit bitmask with "1"'s set for each valid token; as they are used, they get reset to 0] OR you prepare a database with 1677 blank entries, filling in each one "as used" (and doing a search each time a token is presented to see if it's been used) Either would work because the entire range of "valid" tokens pretty much "has to be" generated programmatically (and possibly modulated based on the time-and-date that the token is generated, but this "complication" only makes it more difficult for a "human" -- see below)
To my knowledge the seed is site/time specific.
>
> Since the guy that was activating my card indicated "this next step takes some time", I imagine the list is pre-generated (if you use a "bitmask" it would only need to be 2 megabytes long -- years ago, that would be a showstopper, but in today's age of terabyte drives...) I don't know offhand if my card is also time-based (but that's easy to test...)
>
> In any case, I can see that the "push for a new token" card wouldn't be terribly secure (if it is only "event" based) as someone could copy a block of tokens should they get ahold of the card (and since there is no indication of how many tokens have been generated, the user wouldn't necessarily know that he'd been compromised) The pin-based one is a little better as a "random guess" only has a 1-in-10000 chance of getting the correct PIN (or to put it another way, for an attacker to store off potential tokens for later use, they would have to generate/store 9999 other tokens as well) Of course, should the PIN be compromised, the device is no more secure than the single-push version [though, a thought occurs -- if the "PIN" that you enter is used in some way to modify the token generated, and that "method" becomes known, it would be trivial to convert any given result to what it would be with a different PIN - the attacker need only store tokens generated for PIN 0000...]
>
> The "time based" ones are, again, only marginally more secure since (I imagine...) there has to be some set algorithm to convert a "good" token to "good at /this/ moment" token, and if that's the case, chances are pretty good this algorithm can be reversed, and again, someone could extract any number of tokens and "adjust" for the time of day (by first back-converting to the base token, then at the time you wish to break in, convert any base value token to a current-time version...)
>
> Oh well, food for thought for the weekend... Gotta go...
>
Thanks for the post.
I don't do a lot of security work anymore, as I got tired of the very
long audit sessions and stating my name/position/responsibilities etc
for the permanent record, as well as the in depth background checks
required. However I have been directly responsible for some very large,
high profile security implementations, and consulted for several others.
So I hope I answered your questions. Perhaps someone can do a
presentation on two factor VPN authentication with open source software
at SGVLUG?
Apologies for the formal nature of my response, but I take security and
the protection of privacy as very serious matters (even though some of
my previous posts to the list today, may have not seemed so.:)) I'm
guessing you and the organization issuing you the key fob do as well.
I don't know your particular situation beyond the details provided here,
and claim no responsibility for, or accuracy of anything said above.
Please please please onsult with your organizations security and legal
professionals on the security/legal/privacy/compliance implications of
your particular solution and it's reduction to practice.
I really really really care when I'm paid to care, and I take reasonable
precautions during online activity of a non employment related nature.
