[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1981639246.20060911155459@SECURITY.NNOV.RU>
Date: Mon, 11 Sep 2006 15:54:59 +0400
From: 3APA3A <3APA3A@...URITY.NNOV.RU>
To: "Bojan Zdrnja" <bojan.zdrnja@...il.com>
Cc: "Hadmut Danisch" <hadmut@...isch.de>,
full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re[2]: RSA SecurID SID800 Token vulnerable by design
Dear Bojan Zdrnja,
--Sunday, September 10, 2006, 2:51:06 AM, you wrote to 3APA3A@...urity.nnov.ru:
>> 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
Òàêèì îáðàçîì ýòîò ïóòü äåøåâëå è ê íåìó ëåã÷å äîáðàòüñÿ
òîìó, êòî â ñîñòîÿíèè äî íåãî äîáðàòüñÿ. (Òâåí)
Powered by blists - more mailing lists