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: <200609081551170677.57AE695F@smtp.1and1.com>
Date: Fri, 08 Sep 2006 15:51:17 -0700
From: "Matthew Leeds" <mleeds@...leeds.net>
To: hadmut@...isch.de, full-disclosure@...ts.grok.org.uk,
	bugtraq@...urityfocus.com
Cc: 
Subject: Re: RSA SecurID SID800 Token vulnerable by design

You might want to look at:

http://www.networksecurityarchive.org/html/Web-App-Sec/2005-02/msg00089.html

for a discussion of this issue and the soft token issue.

----------
---Matthew
*********** REPLY SEPARATOR  ***********

On 9/7/2006 at 8:49 PM hadmut@...isch.de wrote:

>Hi,
>
>I recently tested an RSA SecurID SID800 Token
>http://www.rsasecurity.com/products/securid/datasheets/SID800_DS_0205.pdf
>
>
>The token is bundled with some windows software designed to make
>user's life easier. Interestingly, this software provides a function
>which directly copies the current token code into the cut-and-paste
>buffer, when the token is plugged in into USB. This is weak by design.
>
>The security of these tokens is based on what RSA calls "two-factor
>user authentication": It takes both a secret (PIN) and the
>time-dependend Token-Code to authenticate. The security of the
>Token-Code depends on the assumption that the token is resistant
>against malware or intruders on the computer used for communication
>(web browser, VPN client,...).
>
>However, if the Token Code can be read over the USB bus, this
>assumption does not hold. A single attack on the PC where the token is
>plugged in would compromise both the PIN (e.g. with a keylogger) and
>the token itself (e.g. writing a daemon which continuously polls the
>token and forwards the token in real time to a remote attacker.
>
>Ironically this could make an attack even easier: If some malware
>simultaneously monitors the token and the keyboard, it is much easier
>to detect that the keystrokes are actually related to some login
>procedure:
>
>Whenever the 6-digit token code appears in the keyboard or
>cut-and-paste input stream, you can be pretty sure that in a sliding
>window of about the last 100-200 keystrokes both the PIN and the
>address of the server to login is contained. Makes it really easy to
>automatically detect secrets in the input stream.
>
>Thus, two different authentication methods are together weaker than
>each single one.
>
>regards
>Hadmut



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