| 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
| ||
|
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