[<prev] [next>] [day] [month] [year] [list]
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D2FD72@uxcn10-tdc02.UoA.auckland.ac.nz>
Date: Sat, 30 Mar 2013 06:09:55 +0000
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Re: Suggestion: API should include a verifier function
Jeremy Spilman <jeremy@...link.co> 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
>'IsThisYourPassword'.
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".
Peter.
Powered by blists - more mailing lists