Hacker News Reader

Comment by TheLoneWolfling | Hacker News Reader

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.

View on HN

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.

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

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.

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

Reply on news.ycombinator.com