How would this work when you have to store the hash on a server? A hypothetical client-side hasher doing this means that an attacker would just...send the hash, acquired through nefarious means. Just as they'd send the password today. Server-side, that hash would be the password and that itself would need to be hashed before storage.

I don't know why you're talking about "custom hashing algorithms", in JavaScript or elsewhere; you pull a bcrypt/scrypt/Argon2 library and use it.

Yea you're right. But what about this, the client uses the password as a seed to create a public/private key pair, and sends the public key to the server. If it is during password creation, the server stores this public key in relation to the user, otherwise verifies it. Then the server sends a challenge* and the client uses the private key to sign it and return a response.

* actually the server would send the challenge ahead of time along with serving the web page

That sounds like PAKE. I'm not qualified to opine on that; it's above my pay grade. I can see a lot of implementation issues, though, if you wanted to make it a browser component outside the control of the developer.

Perhaps you'd be interested in reading about Secure Remote Password (SRP): https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

Copying the "layman's terms" from that page for your convenience...

In layman's terms, during SRP (or any other PAKE protocol) authentication, one party (the "client" or "user") demonstrates to another party (the "server") that they know the password, without sending the password itself nor any other information from which the password can be derived. The password never leaves the client and is unknown to the server.

Thanks, I thought there should be something like this.

There is no client-side security. If you hash on the client side then that hash becomes the password and you have plain text password storage.

One important reason we hash passwords is protect what is essentially a user secret (one which the user may use across many different services) from prying DBAs. In that respect client-side hashing (with salting) makes perfect sense.

The other major benefit of server-side hashing, to what you're correctly surmising, is that it prevents certain privilege escalations. A read-only database dump (from e.g. SQL injection in to a SELECT query) can otherwise be used to gain read-write access by simply copying dumped passwords from the database back in to the login form. The thing is, server-side hashing doesn't actually prevent this attack, it merely slows it down. It also doesn't help at all with weak passwords.

In any case, to address your concern you can also simply run the client-side hashed value (which could and should be produced by something like Argon2) through a single round of SHA2.

There are ways to improve security via encrypting the password clientside with a nonce and avoiding passing raw text over the request to the server (which should be https not http) but I believe it isn't considered necessary above the inherent security in most circumstances.

You could just hash the hash that the client sends, no? Then you never know their password and it's still stored securely.

If the client always hashes the password in the same way (no nonce or usage of encryption) then the password essentially becomes the hashed string with some extra clientside code you're burdened with forever. And since that same hashing will need to be done whenever they log in the hashing algorithm needs to be in the client side code sent to everyone... meaning an attacker would have a bit of obscurity in their way and just need to regenerate a rainbow table based off of your hashing algorithm to test common/weak passwords.

It's not about the security, it's about preventing side-channel leaks of the plain password (e.g. incorrectly sanitized logs or buffer overflows). Having a data breach of your site-specific hash is much better than leaking the user's password that an attacker could use on any website.

Your site specific hash, if leaked into logs and generated using a fixed hashing algorithm, would just be a step of obscurity, a rainbow table generated according to that hashing algorithm would be able to extract the original typed password pretty reliably for use in compromising other accounts held by the individual on other sites.

There are ways to actually add security above SSL but they require a per-session nonce. The most secure versions of these operate on some sort of out-of-band time-scrambling algorithm that's issued to users on an individual basis (usually a dongle) which is basically a nonce that's been pre-arranged a few years in advance, these can (if done correctly) provide all the security of on-demand generated nonces and physical keys combined.

Fixed hashing algorithms add such a negligible amount of security that I'd prefer to avoid them due to the tech debt their existence incurs outweighing their advantage.

Their password would have to already be in a rainbow table, and at that point nothing can help them. But I agree it's kind of pointless, I was just arguing that there is a benefit even if negligible. If you want real security, WebAuthn is the future.

I can’t think of any situation where password hashing should be happening on the client - that would eliminate a large part of the benefit.

The company not having any access to the plaintext password would already be a huge benefit. (many people are giving random companies access credentials to their e-mail, as it stands) Although that would be hard to enforce.

They would only be able to screw users by allowing access to their own service if they were forced to provide a salt and only be able to get the hash.

  <input type=password salt=687161>

would only return the salted and hashed value.

But at html level, everything is possible and this would be hardly possible to enforce, aside from informing the user that they are typing a password into unsecure password field (hard to do, not to be fakeable, too).

It would still be hackable, by bad actors by using a salt of a service they want to get pw for, but that would at least be detectable client side.

If the salt is static, the hash becomes the password. Nobody does this.

If the hash is dynamic, the password has to be stored in plaintext. Kerberos does something like this.

Neither of these are better than the current state of the art. Read up on SRP for a public-key based system that does something like what you want.

Third party data access should go through OAuth, not by sharing passwords to services.

People share passwords, and use e-mail address to create accounts on all kinds of websites.

Anything that would prevent the website's server from getting the plaintext password would be good. Salted hash is obviously not a plaintext password and can't be stuffed around to other services.

Thankfully people have realized this in settings like PHP leading them to drop the old suggested password hashing method... which at this point I can't recall, but it involved setting up salts manually and making sure you had a strong IV... which no common web devs would do.

Now you've just got to call these two:

https://www.php.net/manual/en/function.password-hash.php

https://www.php.net/manual/en/function.password-verify.php

and if you really want to tweak things you can, but the simple route is moderately secure

Its my understanding that the hashing should not be done client side, as that would expose the secret salt that is being used and reduce security?

Password salts aren't secret. They are stored alongside a password hash because they're necessary to reconstruct the hash from the plaintext. If you look at a bcrypt string, for example, the salt's encoded in it.

The problem is instead that now that the client-side hash is actually the password.

(edit: some people use a "pepper" at the application level and apply it to all passwords, which might be kind of what you're thinking of? Buy you don't need to do this with modern key derivation algorithms. You can if you want, it just doesn't really matter much.)

That's not why (the salt does need to be secret secret), but it is true that the hashing should not be done client side. It's more because it doesn't actually accomplish a whole lot. The hash basically just becomes the password, so you'd need to hash it again on the server to get the same level of security.

Mere hashing indeed wouldn't be useful, but there's SCRAM, and it's standardized as one of HTTP authentication mechanisms (see RFC 7804).

Edit: though perhaps it's worth noting that it won't force a server to store a password securely, but would facilitate it.

This issue only affect those account resetted by admin.

Time to introduce a new Postgre data type. (:troll:)