Hacker News Reader

Comment by bullen | Hacker News Reader

I only use single serving server salt hashing for authorization and identification. It requires two requests but it's secure for login and most importantly it's simple enough to implement in javascript.

                   client --- server

    salt?            ->         ->  generate salt
    hash(pass+salt)  <-         <-  salt
         -"-         ->         ->  verify hash
    done             <-         <-  auth

View on HN

Congratulations, if I'm not mistaken you just defeated the entire purpose of hashing passwords.

The point is that the server doesn't store what's used to verify directly, it needs to provide something that can generate it. The way you're doing it, someone can dump your DB and login as anyone. If you want a secure way to do this maybe look into SRP or similar PAKE protocols.

This is why you shouldn't "innovate" with encryption unless you are a trained cryptographer (or equivalent). Cryptographers may be programmers, but programmers are not cryptographers.

You don't need to be a cryptographer to know that you don't do plaintext passwords.

But it seems it wasn't obvious to bullen that this way the password is essentially sent in plain text. So yes, let your authentication be analyzed by an expert or use standard software.

to state the obvious: there are other things you don't do

Just to be clear with you, the mistake here is that the salt is being generated. This means that you are not storing H(salt, pass) in your DB but probably something that is “password-like,” in that if you know it you can log in as that user.

In a more secure auth flow you instead have:

    Request 1:
      -> Can I get a login CSRF token for `crdrost`?
      - generate random string and store on the users table with an exp date
      <- Sure here is a login token
    Request 2: 
      -> Here is my token and my plaintext password. (!)
      - Users table: select CSRF token, salt, KDF(salt, pass) previously computed
      - compute KDF(salt, pass), compare with previous computation
      - generate session token
      <- Sure here is your session token

In terms of KDFs you might use Blowfish or PBKDF2 or Scrypt or more recently Argon2, you can also HMAC or hash-concat if you have strong enough complexity requirements that you are not worried about brute force attacks, e.g. “when you sign up I will generate a random password for you.”

The remaining security vulnerability is typically that you accidentally auto-log plaintext passwords so this requires vigilance around that.

But the point is that at no time does the database store anything which can be used to complete a login. Suppose I do the KDF on the client side, then its output is “password-like” and if I know that output by reading a row accidentally from the users table, I can log in as that user. Similarly by overhearing an HTTP login over WiFi, I can log in as that user.

Similarly you have a “challenge/response” system because you don't want plaintext passwords to even make it to the API, this is a noble aim but it absolutely requires public key crypto to be done correctly: you store a public key derived from the private key; login page uses password to generate private key and then signs a request to sign in, you confirm the signature with the public key. A full scheme, so that you are not rolling your own crypto, is described by the Secure Remote Password protocol.

The security risks there are just that the process has become very complex and complex things are easier to get wrong.

> but it absolutely requires public key crypto to be done correctly

It actually doesn't, have a look at how the Firefox Account Login protocol works, essentially using only hashing and KDFs:

https://blog.mozilla.org/warner/2014/05/23/the-new-sync-prot...

It doesn't really achieve challenge-response without it, but it does mean at least that the server never sees the plaintext password.

Yeah I mean that comment is about achieving challenge/response without storing something password-like; obviously a non-challenge/response login is not going to be a counterexample.

While CR does not need the full force of public key crypto it has properties which require a distinctive subset of those features in this context—I want to be able to take a password and derive two values (K, V) such that g(V, f(K, s)) = h(V, s) for some large family of s'es, but f(K, s) cannot be computed as j(V, s) efficiently. Public key crypto is more or less the case where h(V, s) = s, giving an option to maybe do something interesting when h is nontrivial.

[Just to give an example that I should have given yesterday for anyone who finds this in the future, in particular if you omit some of the safeguards of SRP then the “core” of it has h(V, s) = V^s (mod N) for some N and in some sense it is not doing full public key crypto but rather the seemingly-weaker subset that is Diffie-Hellman key exchange. But of course then ElGamal came and proved that at the core of Diffie-Hellman you can find a public key crypto algorithm so they are clearly very strongly related to each other even if this doesn't need to use the full force of it.]

You re-hash the client's hash on the server as part of the verification, no?

Yes, the server also knows the "pass" (can be salted hash if you wish, I use hash(pass+name) but it doesn't change the usefulness of this simple auth) and verifies the hash by re-hashing and comparing. Edit: Sad that most people misses the forest for all the trees, should have called pass secr. instead.

Does this not allow the server credentials to be stolen and then used to log in as you?

As a bonus you get to try all the passwords on popular websites.

Congrats, you have been proposed for this years "Plaintext Password Award", the trophy that every industry professional despises but somehow many still manage to obtain one!

> should have called pass secr. instead.

Even if you used a pre-hashed (well, preferably key derived using scrypt, argon2, etc) password, the problem is that if an attacker dumped your database they can still login to every account on your system without the original password.

To perform a full challenge response system, you'd need to get some public key crypto going, be that deriving ed25519 keys on the client or going to a full PAKE algorithm like SRP. Anything short of that means your challenge response is going to prove almost as bad as clear text if an attacker steals the secrets.

Sure, if the servers are compromised, they are compromised. So you prefer more complexity in your auth; so that something that should not happen, can happen? Simplicity is important.

Reply on news.ycombinator.com