4 ms·

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

• icebraining 7y ago
  You re-hash the client's hash on the server as part of the verification, no?
  • bullen 7y ago
    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.
    • SomeHacker44 7y ago
      Does this not allow the server credentials to be stolen and then used to log in as you?
      • kingludite 7y ago
        As a bonus you get to try all the passwords on popular websites.
    • zaarn 7y ago
      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!
    • buildzr 7y ago
      > 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.
      • bullen 7y ago
        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.
• buildzr 7y ago
  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.
  • tragicpapercut 7y ago
    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.
    • zaarn 7y ago
      You don't need to be a cryptographer to know that you don't do plaintext passwords.
      • pvorb 7y ago
        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.
      • kingludite 7y ago
        to state the obvious: there are other things you don't do
• crdrost 7y ago
  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.
  • buildzr 7y ago
    > 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-protocol/ 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.