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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date: Sat, 30 Mar 2013 06:09:55 +0000
From: Peter Gutmann <>
To: "" <>
Subject: Re: [PHC] Re: Suggestion: API should include a verifier function

Jeremy Spilman <> writes:

>Personally I was amused by an attack which involves hitting the login API
>millions of times. There are cases when timing attacks might conceivably go
>unnoticed or un-rate-limited, 

Twitter immediately springs to mind (they supposedly fixed it after they got
0wned this way a year or two back).  On the general web rate-limiting isn't
that common (if a site is using plaintext password storage they won't have a
clue about rate-limiting), and it's practically unheard-of in embedded devices
(I don't think I've ever found an embedded device that rate-limits, unless
it's running a general-purpose OS like Linux that happens to do it as part of
the OS config).

>but just trying the 'Top 10K' passwords would probably get you logged in
>faster if the target is allowing unlimited online attacks against

Absolutely, but we're supposed to be designing a general-purpose system that
matches all sorts of different circumstances, including ones that don't rate-
limit, use an all-zero salt, and so on.  It's far better to build in a defence
against all manner of attacks in advance rather than have to go back and say
"Oh, you're not supposed to use it like that.  Or like that.  Or that either".


Powered by blists - more mailing lists