A very negative article - unduly so for me

Posted Mar 3, 2017 2:52 UTC (Fri) by ras (subscriber, #33059)
In reply to: A very negative article - unduly so for me by tialaramex
Parent article: The case against password hashers

> The paper gtg linked, http://www.flypig.co.uk/papers/dlj-gr-passwords16.pdf
>
> ... actually does illustrate the thing you'd saying is unlikely.

Yeah, OK, mea culpa. They targeted leaked password databases that had unsalted (and in one case plain text) passwords (something I see they only mention in the body of the paper), but I guess the argument is you should be safe regardless of what the web site does. It's not an unreasonable argument.

There are two fixes: include the login name in the hash, or use a costly hash (eg pbdkf2, scrypt) to make the pre-generation of the hashes for all common passwords too hard. (Now I see both were mentioned in the referenced paper under "Mitigation".)

That said, if you are using a weak password it's not just the hashes stored on foreign server you log into that are insecure, the database used by the password manager is also equally insecure. If the answer to the latter is "don't use a password manager that might leak your database (such as lastpass)", then the a similar answer for password hashers is "only use one implemented well".

to post comments

A very negative article - unduly so for me

Posted Mar 3, 2017 13:11 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I talked to a co-worker about this and what he does is have a unique salt for every site. It makes changing passwords simple (change the salt), breaking one doesn't grant any others (without the database), but is currently tied to an extension that isn't allowed on multiprocess Firefox yet. Personally, the browser link kills it for me (I use git annex to sync a KeePass database instead), but it does seem like an improvement over the schemes described here (except for the state sync requirement).