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
| ||
|
Message-ID: <20150625055006.GA2242@openwall.com> Date: Thu, 25 Jun 2015 08:50:06 +0300 From: Solar Designer <solar@...nwall.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] Why protect against side channel attacks On Thu, Jun 25, 2015 at 01:40:46AM +0100, Peter Maxwell wrote: > Yeah, but on balance a constant-time implementation is still preferable to > even the remote possibility of opening up a new attack vector that hadn't > existed before... That's a common opinion, but not the only opinion. > would be somewhat embarrassing for the PHC if a few years > down the line it turned out that password data could be recovered from a > local timing attack that an unsalted md5 password hash isn't vulnerable to > :-) Sort of. However: 1. I wouldn't expect this to be treated as that much of a new finding - we're already aware of this possibility for when the salt is known to the attacker. 2. What do we optimize for: avoiding embarrassment or maximizing users' security? To avoid embarrassment, the most reliable way is to do nothing. Don't recommend any hashing scheme, and there will be nothing to be embarrassed for. To maximize users' security, we need to accept reasonable security tradeoffs and risks, and document them clearly. (I agree, though, that within reason it makes sense to err on the side of caution.) 3. Luckily, "unsalted md5" isn't state of the art prior to PHC. bcrypt and scrypt are, and these already use secret-dependent indexing. This is a reason why I find secret-dependent indexing (barely) acceptable when it helps achieve other security goals, but secret-dependent branching not acceptable at this time (that would in fact be accepting new risks, even if similar). > Admittedly, I'm still not convinced on the utility of most memory-hard > PDFs anyway. Put it this way, I'm working on a project just now that may > end-up serving a reasonably high load of login requests Can you be more specific? > and will choose > something *far* more light-weight for the password hash than has been > generally proposed on this list -- memory and compute cycles aren't free. Possibly you got confused by us typically talking of fairly high memory sizes. This does not necessarily mean that those same schemes wouldn't reasonably scale down to much lower sizes and much higher request rates. yescrypt is meant to be scalable down to kilobytes and 10k+ requests/s, while still providing good defense to the extent practical (better than PBKDF2, and on par with bcrypt at same defensive running time). > You get far more bang for your buck by giving users a swift swift kick up > the rear-end and forcing them to pick marginally better passwords. I think that's a wrong way to think of the problem. Here's what I think is a better way: more password stretching allows for a less annoying password policy. An exception to this, where I would agree with you, is with password hashing times that are so large they are actually noticeable to end-users, like hundreds of milliseconds or more. This is why I find it unreasonable to tune KDFs for more than 1 second: it is better to give the user a chance to type a few characters (or even words) more than to have them wait for a few seconds more. For password hashing on a server, we don't get anywhere close to those numbers, with the target latency being in the 1 ms to 100 ms range (and request rate on a multi-core server often in the 1k to 10k requests/s range). Password stretching should be the primary tool, as long as server resources permit (leaving some room for spikes). If you're using only the server resources you already have anyway, it's sort of free. Password policy should be secondary, since it has a cost to the users (and thus indirectly a cost to you). Of course, both should be used at once, but I'd skew the balance towards stretching and against policy to the extent practical in a given setup. Alexander
Powered by blists - more mailing lists