3 ms·
I disagree. I think millions of accounts are compromised because users are required give up too much information and can't verify that their user data is stored
by copsarebastards 12y ago
I disagree. I think millions of accounts are compromised because users are required give up too much information and can't verify that their user data is stored in a secure way. The solution to this is on the client side, in the browser, not in the server.
The core proposition of this article is that if we make it really easy to store user data correctly, people will do it. This proposition is simply not borne out by the data. Many parts of user security are easy. Take password storage, for example: it's so easy a caveman could do it. Every major languge has a library that takes a password and a salt and a number of iterations and runs it through pbkdf2 or scrypt. Many have these functions builtin. But do people do it? No. It seems like once a month some company exposes X-thousand passwords because they stored it in plaintext or MD5. And I bet a significant portion of HN readers think SHA1 is a valid way of storing passwords, eager to sacrifice security as efficiently as possible. pbkdf2 and scrypt aren't hard to use, people are just idiots.
Making a specialized database just gives people another easy thing to not use.
Ultimately there's no reason to be giving your password to a service in the first place. You only should be giving them cryptographic proof that you have your password, not giving them your password. This is possible with zero-knowledge password proofs[1], but it would require browsers and other client-side software to implement a ZKPP algorithm. This would force servers to either implement a ZKPP algorithm correctly or expose their incompetence to their users. Similar algorithms can be hypothesized for many other user data needs, but passwords would be an excellent start.
[1] https://en.wikipedia.org/wiki/Zero-knowledge_password_proof https://en.wikipedia.org/wiki/Zero-knowledge_password_proof