Hacker News new | past | comments | ask | show | jobs | submit login

Actually, it doesn't.



In this case, it does. If the client's job is to hash the password then send it to the server for comparison, you've basically got plaintext passwords. They may be quite long, but we're at that place where things don't scale anymore.


Derive a 256-bit key from your password, then send that 256-bit key to the server. Nobody is ever going to perform a brute-force search against the 256-bit derived keyspace, so any attack will need to run the KDF against a list of likely passwords in order to get a list of likely keys.


"Never", huh? Seems to me like an extremely strong statement for a security officer for a major operating system to be bandying about.

Your proposal also treats a 2-way cryptographic function as a 1-way cryptographic function. That is, optimistically, a questionable thing to do.


I am perfectly willing to stake FreeBSD's security on the belief that nobody will ever perform a brute-force search against a 256-bit keyspace.

For that matter, Microsoft, Apple, RedHat, Debian, and Ubuntu all make the same or (usually) even weaker assumptions in their respective packaging and/or updating systems.


It's an idea roughly analogous to SRP, which is well-studied. Share a key, then later prove you still know it.

Client-side hashing would be great, if there was a way to do it that didn't involve Javascript.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: