full-disclosure - 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: <bf0173120609091551t27b3677erb7c4a6a34dcd82b2@mail.gmail.com>
Date: Sun, 10 Sep 2006 10:51:06 +1200
From: "Bojan Zdrnja" <bojan.zdrnja@...il.com>
To: 3APA3A <3APA3A@...urity.nnov.ru>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: 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/