Storing passwords

Posted Oct 12, 2011 12:14 UTC (Wed) by epa (subscriber, #39769)
In reply to: Storing passwords by mordae
Parent article: WineHQ database compromised

Just have site return an unique ID in HTTP header or meta tag

I was hoping for something that browsers could implement immediately without any co-operation from sites, since it's clear that a large number of websites won't put any effort into improving password security.

Storing passwords

Posted Oct 12, 2011 12:56 UTC (Wed) by iq-0 (subscriber, #36655) [Link]

Well the idea of PwdHash matches almost perfectly with how eg. Firefox stores you credentials in the password manager. So it could do this 100% client side for all cases where you would normally get the "do you want to remember this password?" popup (and no this doesn't mean you have to use the password manager itself, you'd just use the same username/password/site recognition heuristics as the password manager would use).

But a more tightly coupled approach with you password manager can improve a bit on this scheme (probably only really sensible when using firefox sync if you work on more than 1 computer) by adding another piece of random data that is stored in you password manager (still regardless of whether it would include you password itself).
This way you have a predictable salt which will still help against plain reuse of your password on other sites and against rainbowtable attacks, but which would be relatively easily thwarted with a good password cracker.
And you have a random salt which would effectively make it impossible to do guess safe for a brute-force attack and would thus give additional protection by making it almost impossible to guess what the password is that you memorize.
And lastly, even if they knew your password, they'd still be unable to use it without the random data stored in your browser.

Also they could improve on it by using their crypto backend especially when one has a hardware cryptoki. Most browsers already support this for logging in using client certificates. This could be used to sign the username/site pair with your key and use that as a password. Effectively limiting the use to 1 site. Though you'd still want to add state to the browser, otherwise you'd be unable to generate a distinct password for a site once it has been restored after hack and the attacker could still access the site as you (or you'd have to create a new username, but that would be a stupid restriction). That state by the way doesn't have to be secure, you could just put it on some publicly readable site (eg. in your facebook profile description, than it would at least be put to good use :-D)