|
|
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[2]: RSA SecurID SID800 Token vulnerable by design Sep 11 2006 11:54AM 3APA3A (3APA3A SECURITY NNOV RU) 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: RSA SecurID SID800 Token vulnerable by design Sep 08 2006 10:33PM Bojan Zdrnja (bojan zdrnja gmail com) |
|
Privacy Statement |
--Monday, September 11, 2006, 7:35:08 PM, you wrote to 3APA3A (at) security.nnov (dot) ru [email concealed]:
>> It means, if authentication schema is NTLM-compatible (it must be for
>> compatibility with pre-Windows 2000 hosts and some network
>> applications, like Outlook Express), attacker can use compromised
>> account to access network resources without having access to 2-factor
>> authentication device. How long he can retain this access depends on
>> how often account's NT key is changed (usually with password change,
>> but actually depends on implementation of authentication system and
>> may be never).
BE> Is this RSA whitepaper an example of what you are talking about?
BE> http://tinyurl.com/pb5n7
BE> The whitepaper refers to Kerberos tickets, but the mechanism sounds
BE> like it could work with NTLM as well.
BE> I think the situation you are pointing out is where an authentication
BE> process requires an initial two-factor authentication, but then issues
BE> some kind of session key that takes a very long time to expire. That
BE> would seem to defeat the purpose of the two-factor auth.
In case of Kerberos authentication there is also "session key" (TGT)
which is issued by default for 10 hours. But Kerberos controls IP
address of the client, it reduces the impact of ticket stealing. In case
of NTLM, this control is impossible, because domain controller is
contacted by server, not by client.
Regarding NTLM support it's not absolutely clear, but according to this:
-=-=-=-=-=- quote
? In this scenario, the first time end users are asked to RSA SecurID authenticate to
Microsoft Windows, users are asked for their Windows password. The RSA ACE/Sever
software captures and stores it. From then on, RSA Authentication Manager software
provides the Windows password to the Windows login process for the end user who does
not need to enter it.
-=-=-=-=-=-
NT key is probably generated and used by SecurID. And probably it's
worst possible case: NT key is derived from windows password and is
never changed. Of cause, it needs to be checked. If NTLM works (e.g. you
can connect to file server behind NAT or through mapped port) - it is.
--
~/ZARAZA
http://www.security.nnov.ru/
[ reply ]