full-disclosure - RE: Re: RSA SecurID SID800 Token vulnerable by design

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <007501c6d480$b8f82390$6600a8c0@kpllaptop>
Date: Sun, 10 Sep 2006 12:27:54 +1000
From: "Lyal Collins" <lyal.collins@...2it.com.au>
To: <full-disclosure@...ts.grok.org.uk>
Cc: bugtraq@...urityfocus.com
Subject: RE: Re: RSA SecurID SID800 Token vulnerable by
	design

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.
And this data stream to the authentication host is still subject to a
variety of MITM attacks.

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)?

Lyal

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Bojan Zdrnja
Sent: Sunday, 10 September 2006 8:51 AM
To: 3APA3A
Cc: full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
Subject: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design

On 9/9/06, 3APA3A <3APA3A@...urity.nnov.ru> wrote:
> Dear Hadmut Danisch,
>
>  2-factor authentication is not a way to protect against malware.

Well, it protects - the authentication process.

>  SecurID  authentication  supports  single sign-on technology. As a 
> weak  side  of  this  technology,  it means, if single account on any 
> network  host  is  compromised,  this  account  is compromised in 
> whole network,  because  any resource can be accessed from compromised 
> host. An ability  to read current key from device is required to 
> support single sign-on.

It depends on the underlying SSO technology. In most cases today you have
web based SSO deployments which rely on a cookie. In this case, you don't
need to connect the token at all - all you have to do is login once and the
browser will take care of rest. As Brian noted in the following e-mail, if
an attacker can put a keylogger on your machine, he can certainly get the
cookie as well and use it.

>  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).

No - the OTP can be used only once, so even if you manage to get both the
PIN/password and the OTP (remember, you need both to login) you can't use
that because the RSA authentication manager (the server side of the whole
process) marked that OTP as used.

In this case an attacker can only try to brute force the OTP (after all,
it's only 6 digits), but RSA has excellent measures against brute force
attacks (basically, after a certain, configurable, number of unsuccessful
logins the token is disabled; what's even better is that it tracks number of
incorrect OTPs with correct PINs - if that is higher than a certain number,
it puts the token into "2nd OTP mode" which means you have to guess 2 OTPs
in a row).

I think these tokens offer excellent means for authentication. Sure, they
are not a silver bullet and don't solve all your security problems (nothing
does), but if you have users who have to login from a lot of insecure places
(airport lounges, cyber caffes) and are afraid of keyloggers stealing
passwords, two factor authentication really helps.

Cheers,

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/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/