Lyal Collins
12/09/06, 02:20
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@lists.grok.org.uk
[mailto:full-disclosure-bounces@lists.grok.org.uk] On Behalf Of Bojan =
Zdrnja
Sent: Sunday, 10 September 2006 8:51 AM
To: 3APA3A
Cc: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com
Subject: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by =
design
On 9/9/06, 3APA3A <3APA3A@security.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=20
> weak side of this technology, it means, if single account on any=20
> network host is compromised, this account is compromised in=20
> whole network, because any resource can be accessed from compromised =
> host. An ability to read current key from device is required to=20
> 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=20
> 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=20
> (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/
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@lists.grok.org.uk
[mailto:full-disclosure-bounces@lists.grok.org.uk] On Behalf Of Bojan =
Zdrnja
Sent: Sunday, 10 September 2006 8:51 AM
To: 3APA3A
Cc: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com
Subject: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by =
design
On 9/9/06, 3APA3A <3APA3A@security.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=20
> weak side of this technology, it means, if single account on any=20
> network host is compromised, this account is compromised in=20
> whole network, because any resource can be accessed from compromised =
> host. An ability to read current key from device is required to=20
> 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=20
> 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=20
> (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/