There are also other flavours of authentication that can be used in this context, like Digest, supported by all major browsers and only sending hashed passwords (even on plain http connections).
In the most secure configuration of digest auth, the server stores MD5(username:realm:password), and to authenticate, the server sends server_nonce, and the client sends back client_nonce and MD5(MD5(username:realm:password):server_nonce:client_nonce). The nonces are used to avoid a replay attack. The server MD5s its stored hash with server_nonce:client_nonce and checks if it matches against what the client sent.
But if those stored hashes get leaked, an attacker can use them to authenticate. You're in a better position than storing plaintext passwords, because the underlying cleartext probably won't be leaked (they're hashed with MD5, so it's not certain), so your users' credentials can't be used in future credential stuffing attacks, etc. But the attacker still has their credentials on your site.
In the other configurations of digest auth, the server ends up storing plaintext passwords (or reversably-encrypted passwords, which is just as bad).
See also https://en.wikipedia.org/wiki/Digest_access_authentication#D...
Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point.
HTTPS is a huge waste of electricity.
A more frugal way of securing logins is to use this RFC: https://datatracker.ietf.org/doc/html/rfc2289
Registrations would need additional security but HTTPS with centralized root certificates is NOT one of them.
My point is that storing passwords in a way compatible with using Digest authentication is essentially equivalent to storing your passwords in plain text, at least with respect to your own site’s authentication.
And then you send a server salt/nonce and the browser hashes the plain text password with the salted hash in your database and then with the server salt/nonce.
Still HTTPS solves nothing of that.
I don't even know what Digest is... I'm talking this RFC:
client_nonce?
This is how the RFC works: Hash(Hash(username:password):server_nonce)
What is the difference between Hash1 and Hash2?
Hash(username:password) is what you store in the database != plain text.
Also what is realm?
Yes, the client also generates a nonce that is included in the digest. The full digest (according to RFC 2617) is (assuming qop is used):
request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <">
> What is the difference between Hash1 and Hash2?
Hash1 is the hash algorithm for the authorization digest, so MD5 or maybe SHA256 (although only firefox currently supports that). Hash2 is the hash algorithm (including salting) used on the server to hash the hash of the username password before storing in the database.
> Hash(username:password) is what you store in the database != plain text.
The password isn't plaintext, but if the Hash(username:password) is compromised that gives an attacker enough information to impersonate that user. The attacker can just use that `Hash(username:password)` to compute the digest, they don't need to know the original password.
And who cares if you need a rainbow table?
Ignoring all the other benefits of HTTPS, it means you can securely transfer the password itself to the server, or a deterministic hash of the password which the server hashes again. Not to mention that you can use a stronger hashing algorithm, like bcrypt. There might be other ways to do this, but https is definitely the most practical.
> who cares if you need a rainbow table?
If the passwords are moderately strong and you are using a good hashing algorithm (that is salted), then creating a big enough rainbow table (or brute forcing) is intractable.
If it's an attack you can do after the database is compromised it's not very interesting, and if it's an attack you can do over the wire then you can just limit the number of login attempts per some duration no?
There are numerous ways to accidentally introduce a weakness to 2nd preimage resistance. Using an HMAC is a way to “reset” the entropy of a hash key and eliminate any unwanted source of information leakage.
BUT if you trust it with anything it's a password so that only you can prove that you are you. And then you use server side nonce hashing to ONLY compute that part securely wasting only the required cycles one each end to proove you are you period!
Then, if for some reason you need additional security on some ulterior action, say a payment, you just do the same trick again. That way you save your servers and the electricity grid from encrypting every meaningless cat picture in the world just because you are paranoid.
Electricity is not an energy source, we are going to pay a very high price for it soon. It's the most liquid energy form we have and therefor when oil becomes illiquid (both litteraly and economically because the quality of oil is degrading at a rapid pace) prices in electrons (which have no quality properties that differ) will explode!
Again read the RFC https://datatracker.ietf.org/doc/html/rfc2289, and think about where you want to spend you energy, more customers or less energy for your own kids.
Okay, so your proposal is to never use any private info, anywhere, ever on the internet?
> Again read the RFC
Page 2 of that RFC says
> It does not prevent a network eavesdropper from gaining access to private information and does not provide protection against either "social engineering" or active attacks
How do you propose to prevent MITM attacks? How do you propose to be able to send private data to a server in a way that is readable by the server?
Embrace the chaos, hide in the noise and save energy!
You've reduced your own argument to a non-answer.
Surely you understand that there are different types of "privacy":
- things that only you know (that aren't sent anywhere and maybe even are encrypted at rest)
- things that only a set of trusted parties are supposed to know
Suppose that you have no encryption but have the best authentication system in the world. What's to prevent some hacker from setting themselves up in the middle between you and the e-commerce site that you're on and messing with requests however they please, showing both you and the site what they want you to see? You tried to buy an HDD for 50$? They just bought themselves a laptop for 500$.
The fact that there's a very secure bit of information somewhere in the request does not protect you from the rest of JSON being changed to say whatever they want it to (unless you are signing the contents of every request, but at that point you're reinventing HTTPS in some capacity). Or even the fact that they could set themselves up in the middle, presenting themselves as you to the site and presenting themselves as the site to you, albeit with more effort.
Of course, an e-commerce site is a silly example, but what about you receiving a bill that tells you to send money to a different account than you should? What would your banking site look like without encryption? Is your suggestiong for no one to do online banking because "nothing is private", even though we already have HTTPS which addresses this very issue ALONGSIDE various authentication methods?
Totally makes sense...
But for the simple hashing it's an old RFC that I like to quote to HTTPS fools: https://datatracker.ietf.org/doc/html/rfc2289
Way better login than moving your whole site, including cat pictures, to encryption.
Glad that was a temporary state of things.