Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Passwords are unsafe

Passwords are unsafe for the same reason that roads are unsafe: human beings. Things work well enough for most people, most of the time. However, during certain situations, most people aren't trained correctly and often do the wrong thing. What's more, there's even an accepted culture of doing the wrong thing.



Extending the analogy, passwords could be much safer, just as certain roads are much safer (better engineering, guard rails, fluorescent markers, accurate speed limits for a given stretch of roads), police/EMT accessibility. Enforced requirements for complex passwords, required routine password changes, 2-factor auth, etc. They aren't perfect but they can exceed 'good enough' requirements.


I'm thinking more and more that the best way to do passwords is to not - you generate a random diceware passphrase (or similar) and give it to the user via a secure channel, run it through the KDF, and throw the original away. Preferably on an entirely separate server from everything else.

It still doesn't prevent users from being stupid w.r.t. writing down passwords, but it at least presents users with reasonably secure logins that are relatively easy to remember.


Best way is to not send credentials in plain text. I wish SRP had taken off and become standard.


This doesn't send credentials in plain text.


What is being sent to the server then?

And by plain-text, I mean the server receives information that could then be used to authenticate later.

For instance, if you send the sha of a password, and then store the sha of the sha, you're still sending the password in plaintext, it's just that it's not the password the user entered.


...Which is why I said "over a secure connection".

This method is no less secure than the standard "client sends server password over HTTPS" scheme.


> ...Which is why I said "over a secure connection".

... and how do you set up a secure connection without a pre-existing password?

Your solution has a chicken-and-egg problem.


SRP (e.g. TLS-SRP) doesn't require the server to have the plaintext password.

[0] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol


The guy I was replying to was arguing against SRP and proposing his own ad-hoc solution.


HTTPS, the same way everything else solves this problem.


HTTPS doesn't solve the problem of not having to send the plaintext password to the server.

SRP does.

[0] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol


The connection doesn't matter, you're still sending the plain-text password to the server. The server still has the password.


I'll add that passwords are used because they're the best default given all the constraints and risks:

https://www.lightbluetouchpaper.org/2012/05/22/the-quest-to-...

They fail when their correct use depends on human beings. Just like you said.




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

Search: