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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 1 Aug 2012 10:30:19 -0300
From: Pablo Ximenes <>
To: andfarm <>
Cc: full-disclosure <>
Subject: Re: 
	Security Problem with Google’s 2-Step Authentication


On Mon, Jul 30, 2012 at 1:46 PM, andfarm <> wrote:

>  Invalidating the entire window would make you unable to authenticate
> using OTP more than once every 10 minutes.

You´re right, it would have a hard impact on usability. Maybe just
invalidating closeby tokens would do, like the 2 or 3 next ones.

> In any case, I'm having a hard time imagining what sort of threat model
> which make this necessary -- if you can somehow predict a user's OTP code
> for some point in the future, you could go ahead and predict one that's
> even further in the future (outside the window of invalidated keys), and
> use it when that time arrives.

I don´t know if it answers your question, but have you got the chance to
examine my PoC?

It´s a phishing verion of that steals two OTP
passwords  and gets you authenticated with one of them while it "saves"
the other in a usable state (it issues an error message in order to trick
the user into entering the code again). This way, the user is lead to think
all the 2 codes entered were invalidated because of the successful login,
which is obviously not the case in the PoC. If  the "invalidate the next X
tokens"  approach were in place, this threat wouldn´t be possible.



Content of type "text/html" skipped

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists