44 ms·
One thing I wonder about, as password hashes get both processor and memory-hard -- are we presenting a trivial DoS attack on our servers, by basically letting a
by jtheory 11y ago
One thing I wonder about, as password hashes get both processor and memory-hard -- are we presenting a trivial DoS attack on our servers, by basically letting any IP submit a request for a server to dedicate this (non-trivial) level of RAM and processor to a given task (hashing a random string to verify that this login is not correct)?
I suppose the answer is yes, but it's worth it. It's possible to fix this sort of hole (partially, at least) by capping the number of hashes processed concurrently. But most simple implementations will just assume "we're not likely to have more than X users every signing in concurrently, so we can set the work factors based on that plus some headrooom".
- frandroid 11y agoIf you throttle your password validations, a large enough attack will effectively be a DOS attack anyway since it would be processing more invalid than valid requests, even if your server is "still working".
- hynek 11y agoYou should rate-limit your logins anyway lest you want to end like Apple & Fappening.
- nly 11y agoIf you're not throttling the number of incorrect password guesses per IP, or per IP per account, or both, you're opening your users up to a dictionary attacks anyway. If I can get a box close your yours (~5ms is doable if we use the same colo), then it's completely feasible. You're right however that this is going to be painful, because most web frameworks don't have any of this throttling architecture (like persistent in-memory hashtables) in place, and as soon as they switch to Argon2/Scrypt, it's going to be an easy DoS vector... particularly for services running on weak VPSs. It's another reason why solid, secure password authentication protocols, that do client-side hashing, will eventually happen. Even in fancy zero-knowledge asymmetric protocols however, online rate-limiting is essential.
- tracker1 11y agoJust an aside, if you're using nginx, I'd look at ngx_http_limit_req_module which can alleviate this case.
- jtheory 11y agoRate limiting per-IP assumes an attack from a single IP, or a very small range of them (so, only defends against a trivial DoS, not DDos... which are sadly easy to set up these days). Per-IP per-account as well doesn't work if the attacker has a large list of usernames. Even brute-force "dictionary" attacks can dodge simple limiters by submitting one password with 2 million diff usernames, then a second password with 2 million usernames, etc.. I'm not saying these are bad (though if someone can trivially stop your real users from signing in by hitting the limit on their accounts, that's just a DoS in another shape). But we're agreed already... these are non-simple problems, really.