|
BugTraq
RSA SecurID SID800 Token vulnerable by design Sep 07 2006 06:49PM hadmut danisch de (Hadmut Danisch) (2 replies) Re: RSA SecurID SID800 Token vulnerable by design Sep 09 2006 09:41AM 3APA3A (3APA3A SECURITY NNOV RU) (2 replies) Re: RSA SecurID SID800 Token vulnerable by design Sep 09 2006 10:51PM Bojan Zdrnja (bojan zdrnja gmail com) (2 replies) RE: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design Sep 10 2006 02:27AM Lyal Collins (lyal collins key2it com au) Re: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design Sep 09 2006 02:12PM Brian Eaton (eaton lists gmail com) (1 replies) Re[3]: RSA SecurID SID800 Token vulnerable by design Sep 11 2006 02:55PM 3APA3A (3APA3A SECURITY NNOV RU) (1 replies) Re: Re[3]: RSA SecurID SID800 Token vulnerable by design Sep 11 2006 03:35PM Brian Eaton (eaton lists gmail com) (1 replies) Re[5]: RSA SecurID SID800 Token vulnerable by design Sep 11 2006 04:16PM 3APA3A (3APA3A SECURITY NNOV RU) Re: RSA SecurID SID800 Token vulnerable by design Sep 08 2006 10:33PM Bojan Zdrnja (bojan zdrnja gmail com) |
|
Privacy Statement |
--Sunday, September 10, 2006, 2:51:06 AM, you wrote to 3APA3A (at) security.nnov (dot) ru [email concealed]:
>> The only additional attack factor this issue creates is attacker can
>> get _physical_ access to console with user's credentials _any time_
>> while user is logged in, while in case token can not be red (e.g. it's
>> not plugged to USB) he can only access console short after user logs in
>> to compromised host (while token is not changed).
BZ> No - the OTP can be used only once, so even if you manage to get both
BZ> the PIN/password and the OTP (remember, you need both to login) you
BZ> can't use that because the RSA authentication manager (the server side
BZ> of the whole process) marked that OTP as used.
BZ> In this case an attacker can only try to brute force the OTP (after
BZ> all, it's only 6 digits), but RSA has excellent measures against brute
No. It actually changes nothing - if attacker trojanes GINA he can
forward entered OTP+PIN/password and use it anywhere while user is
logged in locally without any warning and without any OTP used. User
will not be able to use transparent authentication for network resources
until next logon - but who cares? It's possible to hide this situation
by making some hang-up or crash. Alternatively, you can ask user to
re-enter OTP+PIN saying one is wrong and to use this second OTP - how
many users care about that?
--
~/ZARAZA
Òàêèì îáðàçîì ýòîò ïóòü äåøåâëå è ê íåìó ëåã÷å äîáðàòüñÿ
òîìó, êòî â ñîñòîÿíèè äî íåãî äîáðàòüñÿ. (Òâåí)
[ reply ]