Full Disclosure mailing list archives
Re: Re: RSA SecurID SID800 Token vulnerable by design
From: "Bojan Zdrnja" <bojan.zdrnja () gmail com>
Date: Tue, 12 Sep 2006 12:01:15 +1200
On 9/10/06, Lyal Collins <lyal.collins () key2it com au> wrote:
If there's malware on the machine, and there is a connected USB token, then authentication is only as good as the password - malware can probe the connected token as often as desired.
Read my post again. That's not necessary true. The RSA SID800 token has a smart chip running Java on it. While I don't know how the whole thing works (that's why I asked the OP to sniff the USB traffic and see what's going on), it's possible that the actual OTP generated by the token is encrypted. In this case your malware can probe as much as it wants, but it won't get anything - what you need is a directed attack on the host part of the RSA authenticator (something what 3APA3A mentioned, by changing the GINA dlls) - same as with rootkits, lower level wins.
And this data stream to the authentication host is still subject to a variety of MITM attacks.
There is no perfect security.
In the event of an unconnected OTP token, a variety of MITM attacks still applies to OTP tokens - in the SecurID-style form factor, printed lists or anything similar. In theory, with trusted data paths everywhere (internal to worksation as well as he network) OTP is better than passwords alone. But since this data patch assumption is rarely 100% valid, OTP is as good as a password alone. In the situation where data paths are trust-able, OTP is a somewhat better than passwords alone. Does the risk justify the costs involved (tokens, token management, authentication host, and trusted data paths)?
What you're missing here is a pretty common problem today called keyloggers. And 2FA like this effectivelly raises the bar *quite a bit*. Sure, you can intercept some things, there are MitM attacks and so on, but if your employee, who is using a machine on an airport wants to log in (and there's a keylogger running), it *will* help. This also helps when talking about brute force attacks - it makes them even more difficult, and you don't have to worry about your users using "fred" as password. In security it's always about raising that bar a bit more. Bojan _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: RSA SecurID SID800 Token vulnerable by design, (continued)
- Re: RSA SecurID SID800 Token vulnerable by design Bojan Zdrnja (Sep 08)
- Re: RSA SecurID SID800 Token vulnerable by design 3APA3A (Sep 09)
- Re: Re: RSA SecurID SID800 Token vulnerable by design Brian Eaton (Sep 09)
- Re[3]: RSA SecurID SID800 Token vulnerable by design 3APA3A (Sep 11)
- Re: Re[3]: RSA SecurID SID800 Token vulnerable by design Brian Eaton (Sep 11)
- Re[5]: RSA SecurID SID800 Token vulnerable by design 3APA3A (Sep 11)
- Re: Re: Re[3]: RSA SecurID SID800 Token vulnerable by design 3APA3A (Sep 11)
- Re: Re: RSA SecurID SID800 Token vulnerable by design Brian Eaton (Sep 09)
- Re: RSA SecurID SID800 Token vulnerable by design Bojan Zdrnja (Sep 09)
- RE: Re: RSA SecurID SID800 Token vulnerable by design Lyal Collins (Sep 09)
- Re: Re: RSA SecurID SID800 Token vulnerable by design Brian Eaton (Sep 09)
- Re: Re: RSA SecurID SID800 Token vulnerable by design Bojan Zdrnja (Sep 11)
- Re[2]: RSA SecurID SID800 Token vulnerable by design 3APA3A (Sep 11)