Multi factor authentication

[ciph3r]

okay

Thanks i'll search for him

[astcell]

I am new here so whos kelvin!

Up top click on MEMBER LIST and find him, then send him a message.

[ciph3r]

more token info

I found this snippet while surfing google and it seems that a brute force attack on a particular bank of Securid's are impossible since part of the hash is of the individual tokens serial number

The classic SecurID, for 15 years, used a proprietary algorithm to
hash a token-specific 64-bit seed and Current Time. The new SecurID --
introduced at the beginning of 2003 -- uses the AES block cipher, in
standard ECB mode, to hash:

- a 128-bit token-specific true-random seed,
- a 64-bit standard ISO representation of Current Time
(yr/mo/day/hour/min/second),
- a 32-bit token-specific salt (the serial number of the token), and
- another 32 bits of padding, which can be adapted for new functions or
additional defensive layers in the future.

Conflated and hashed by the AES, these inputs generate the series
of 6-8 digit (or alphanumeric) token-codes that are continuous displayed on
the SecurID's LCD, rolling over every 60 seconds. (The standard mode of
use, as you know, requires two-factor authentication: the token-holder is
required to provide both a SecurID token-code and a user-memorized PIN to
the remote ACE/Server.)

ECB mode in AES is executed on 128-bit blocks, of course, so it is
obvious that RSA had to pad the standard 64-bit expression of Current Time
with another 64 bits. Using a token-specific salt blocks any attempt to
pre-calculate a library of possible token-codes for all 128-bit seeds. That
means that any brute-force attack on the AES SecurIDs would have be focused
on a particular token.

[ciph3r]

Sounds cool to me. I have never thought of hot wiring the token to spit out the code ahead of sequence! I am new here so whos kelvin!

[astcell]

You really need to hook up with Kelvin. I gave him three SecureID tags and he had some others. He was going to attempt to fool then unit into seeing time fly by twice as fast. If you can get the internal clock to tick faster, you can conceivably get the codes faster, then enter them at the correct time. THis can tell you about the factors usedto calculate the next code.

I have some secured file here that are about a year old, and they dongle to unlock them has been lost. I could have dedicated a few desktop boxes to take a crack at decoding them, it would at least show the time involves to try a given number of cracks.

[ciph3r]

Kane/Abel had a feature that would attempt to guess the next sequence of numbers but in testing i never found it much useful. Going after the ACE server would be the most direct route -- I also thought abouit setting up a rogue NTP server since the ACE server uses system time as a seed for the algorithm, but i'd still have to figure out what exactly it does -- oh well i'll stick to ettercap and taking advantage of bad implementations!

[noid]

I havent seen anything in a long time. Prior to RSA buying out SecureID, there were some time based attacks for SecureID. Even then, it really wasnt an exploit of the system itself, but rather taking advantage of the fact that SecureID keys remain valid for longer and longer periods of time to compensate for battery drain on the tokens. The new RSA ones may still do that. As far as a fault in the algorithm, I dont know of anything. They are time based, so i suppose theoreticaly you could probably do something based on that. You'd probably just be better off going for the ACE server itself

[ciph3r]

Yo guys

Anyone know of any faults in the RSA SecurID token algorithms ? I have been able to peform session reply attacks on our network were an authentication cookie and session id is stored on the client machine, but havent come across any tools to attempt to predict the number sequence.