Storing passwords

Posted Oct 12, 2011 9:25 UTC (Wed) by mordae (guest, #54701)
In reply to: Storing passwords by epa
Parent article: WineHQ database compromised

This might actually work. Just have site return an unique ID in HTTP header or meta tag and use that ID, hashed master string user enters plus the password user types and send that with a special HTTP header indicating what you've done.

If this gets implemented properly and browsers inform user that they are sending over raw password, sites might actually implement that.

Storing passwords

Posted Oct 12, 2011 9:43 UTC (Wed) by bjartur (guest, #67801) [Link] (3 responses)

You're essentially describing HTTP Digest authentication w/o the randomized client nonce.
That has actually been implemented in most major HTTP clients. Does lwn support it?

Storing passwords

Posted Oct 12, 2011 12:08 UTC (Wed) by mordae (guest, #54701) [Link]

Ah, there is also the "registration password is hashed in the same way" part missing in my post. Once we've sent password to the server unencrypted, it's not sane to assume it have been stored securely even if we authenticate through digests.

Storing passwords

Posted Oct 12, 2011 20:18 UTC (Wed) by HenrikH (subscriber, #31152) [Link] (1 responses)

If I'm not mistaken HTTP digest requires the site to store the passwords as plain text since it has to perform calculations with it, so I hope that lwn doesn't support it :)

Storing passwords

Posted Oct 13, 2011 15:59 UTC (Thu) by beect (guest, #71486) [Link]

Sites using HTTP Digest can store MD5(username : realm : password). Not much protection, but better than plaintext.

Storing passwords

Posted Oct 12, 2011 12:14 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

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)