If you are using HTTPS, you are equally as good as any other login form.
Some have suggested using JavaScript to encrypt passwords before send - but in my opinion, this is generally stupid because it breaks support on browsers without JavaScript, and this doesn't protect you from the server at all because a hacker could just change the JavaScript to send plaintext copies somewhere. You are reliant on the server being a source of truth either way.
Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server.
https://en.m.wikipedia.org/wiki/Password-authenticated_key_a...
Yes - it does - but I am having a hard time thinking that this actually matters in the real world.
I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent?
If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I could change the login form to stop hashing them client-side and instead send them over to the server for hashing and inspection.
It's theoretically more secure... but against what? Accidental logging? I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript.
In my opinion, client-side hashing is security theater. It sounds impressive, but it doesn't really stop any real-world attacks, and the attacks it does prevent can be prevented using simpler methods. Ironically, the other methods (i.e. making sure your logs are clean) are so much simpler to implement it's probably more secure than trying to build a secure client-hashing implementation in the first place.
But as the other comment pointed out the current situation with web form login is that password is sent to server so it wouldn’t be worse than the the status quo.
A compromised website that was well designed should not leak your password any more than a client-side hashing implementation. This is because the passwords are hashed in the database. Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that.
And credential stuffing? Client-side hashing does absolutely nothing to prevent credential stuffing other than that you may need a GPU to do a lot of hashes quickly. Client-side hashing doesn't make a server handle more or less authentication requests.
Ah yes, "if nobody makes any mistake there's no problem", that's worked so well forever hasn't it?
> Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that.
That makes quite literally no sense, did you miss the entire thing and go off with whatever?
The request here is to make the browser's support for HTTP authentication better. The entire point is that there is no "quick code edit" without owning the entire browser at which point you're quite thoroughly owned anyway.
If the server issues a different challenge each time, decrypting one response doesn't buy you anything.
Which can safely be assumed to happen whenever the equipment is provided by another party such as an employer. All in the name of security, just not that of the user.
If a zero knowledge (ZK) system combined with HTTP Basic was used, then account entry would come from the browser itself and not a web form that could be intercepted by JavaScript.
Further, a ZK system would help with the silliness of folks using bad algorithms (straight MD-5 / SHA-1) to store passwords, or even storing them in plain-text.
I'm arguing here more against some people who think that using a JavaScript-based system to hash the password entry before sending it to the server is a good idea.
So you're arguing against something nobody is arguing for?
- If a site is attacked, there is no risk that password material was extracted from application memory — site operator can dump session tokens and safely re-auth users.
Zero Knowledge Proofs would be awesome (something like WebAuthn/FIDO right now?) but I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones.
1. There is, of course, a way to implement it in your web app. I don't know what you mean by "no secure way" ?
> I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones.
Even a trivially implemented client side hashing approach protects against a number of attacks.
How would I implement PAKE login for my users? How would I get every user to log in with PAKE? How would I ensure that my code for PAKE could not be overwritten if a hacker took over part of my server?
It doesn't exist, AFAIK, on a user-facing front at this time in a secure way that a hacker couldn't just change the logic for.
I know nothing of framework support, I don't use frameworks. I'm likely going to contribute some open source code in the near future from my company to simplify things though.
But you could also just have your client do:
salt = sha256("your company name goes here" + username)
password_hash = pbkdf2(plaintext_password, salt)
> How would I ensure that my code for PAKE could not be overwritten if a hacker took over part of my server?
Depends on the server and the level of control. But it'll help in a number of cases. You're assuming the attacker has full control over the web-page's contents (among other things - even if an attacker had the web page's contents CORS means they couldn't send http only cookies to an attacker controlled server), which is a very specific, powerful position to be in.
You are still exposing the password_hash to the server and any compromise there (software or hardware, as described in your link) would still let an attacker grab password_hash, craft a custom client, and send it as if the original client had hashed the plaintext_password to begin with.
The attacker doesn't need to know plaintext_password, just the string you use to authenticate with in order to replay it. The password_hash becomes the new password.
Then due to the salt being on the client, it still opens the password up to rainbow table attacks etc.
That's really the main benefit of this approach - it reduces the impact of password reuse.
From a corporate perspective, with a segmented + well-firewalled architecture, and a lot of surface area for injection vulns, I totally agree with you. The article was priming me to think of a flat, single-box solodev environment, where if someone breaks in, they own everything - which is why I think the original post above us mentioning PAKE is getting a lot of questioning.
I would happily sign up and reuse a password for a website that I didn't trust if it were as secure as described (PAKE + browser built-in login)
In the 90s and early aughts it was fashionable for php sites to store passwords hashed, usually some combination of a salt with md5 and later the SHA variants.
For a brief few years there were entire communities on IRC and elsewhere dedicated to making rainbow tables for cracking stolen password hashes.
Often the salt would be common across all passwords, so if you got a database dump it was a gold mine for credentials.
That didn't need client-side hashing to fix it.
a) Add a static value to the salt ie: your company's name
b) Add the user's email address to the salt
The "right" way would be a zero knowledge proof.
Yes, it happens all the time that passwords get logged.
> I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript.
I have no idea what "set up your logs correctly" is supposed to mean but clearly no one's doing it. What is a "clean log" ?
> If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I could change the login form to stop hashing them client-side and instead send them over to the server for hashing and inspection.
This assumes you have full control over the client page. But that's not necessarily (or often? most people don't serve JS from the same code that serves their auth API) the case.
1. The JS could be loaded from a CDN, not the same service that has access to the password. You may have absolutely no control over the JS on the page.
2. Every point between the browser and the password DB is a point where the password is in cleartext. So a compromise of any of those, including any logging paths, is a compromise of the password.
3. I don't think anyone cares about breaking login for users who don't use JS, nor should they.
What's more, ZKP means that if your password database is owned the impact is far less. If you're doing things right for password storage on top of ZKP you can practically make your password db public.
Even if we're talking about a basic client side hashing approach you're significantly improving security, but to be clear, the parent poster is talking about ZKPs, which involve more than that.
As you admitted, passwords get logged "all the time." So the reasonable solution in most cases would be to ensure all applicable logs were clean and not logging passwords, not over-engineer a JavaScript-powered client-side-hashing algorithm. That's like taking a sledgehammer to a nail.
a) Tractable
b) Simple or straightforward
compared to client side hashing is absurd.
Client side hashing is a one time solution forever that exists in one place, requiring no 'cooperation' from other code to be safe. "Cleaning logs", which you still haven't defined at all, is going to be a constant maintenance burden that can break in any place where you log ie: absolutely fucking everywhere by absolutely fucking everyone.
If it was a consumer-facing web app, it's not like your password is logged in a million different places. It's possibly logged by your web server software (nginx in my case), and it's possibly logged by your web app framework's requests handler. It's not terribly hard to ensure that these points where the password passes through do not have passwords in their logs, or to ensure that said passwords are not logged to begin with.
If it was a massive enterprise system, I would hope that you would use a single-sign-on system with a centralized login page rather than exposing passwords to every web app within it. And then, just ensure that said passwords are not stored in logs. This is what I meant by clean logs - anywhere the password is used, ensure there is no record. How much code and how many layers does a password need to go through?
And yes, maybe client-side hashing does resolve some attacks, but I remain convinced that it is overkill and less protective than it initially seems. And in the future we would move to Zero-Knowledge Proofs but we aren't there yet for general users.
@path("/login")
def login(request):
print("I have a bug, I'll just log the whole request real quick to see wtf is up!", request)
> I would hope that you would use a single-sign-on system with a centralized login page rather than exposing passwords to every web app within it
Implementing SSO is a great idea. Not everyone wants to use SSO though. If I were hosting a porn site I wouldn't expect my users to happily "sign in with Facebook". It's also much more work than a basic client hash.
> This is what I meant by clean logs - anywhere the password is used, ensure there is no record. How much code and how many layers does a password need to go through?
You underestimate the places logs can be generated or passwords can be accidentally persisted.
1. Your proxy
2. Crashes, stack traces, segfaults, core dumps, thread dumps, VM snapshots, free'd memory
3. Firewalls, both network and host
4. Audit logs for security, such as via ebpf or other auditing frameworks
5. The application, at any layer. In Python, did you know I can get a reference to the calling function? I've done this for logging purposes before, in fact. So even if your caller is super careful not to pass the password in, saving me from accidentally logging it, I can crawl back up the stack and get it anyway.
6. Your database logs
7. Services/ RPCs that sit between your auth API and your database
And as your business grows and your code changes you'll have to track all of that.
Orrrrrrrrr, you can just hash your password on the client side and significantly reduce the damage of a leak. Or put the extra work in to implement OPAQUE. Or use webauthn, that's cool too.
With public key crypto you can implement a challenge response. Server generates random garbage, send to client, client signs the garbage using priv key, sends it back as a hash that the server can verify using pub key.
Another version of this is with shared secrets instead of public/private, by replacing the signature with simply HMAC(secret, garbage) and keep rest of flow same as above.
Or just use a client side TLS certificate to authenticate instead of or in addition to the username and password.
Edit: alright, I saw that you mentioned password reuse in another reply, fair enough, it does help against that.
Maybe, but as a client I can't verify that this happens. So never sending the cleartext password is the only solution.
You have full control over it, as long as you don't embed any third-party maps or crap like ads.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
And the nice thing is that browsers already implement that, no need for Javascript. The bad news is that the UX sucks so much that you just can not use, so it's as useful as it not being there.
But digest password authentication protects against nearly none of those errors. On this case, leaking a digest is just as bad as leaking a password.
That's a little confused. PAKE usually still stores a password or hashed password on the server, with the password potentially recoverable by brute force reversing the hash. What it avoids is transmitting a hash over the wire that can be reversed into a password, the way HTTP digest auth allows. The stuff transmitted over the wire by PAKE instead reveals no info about the password.
Most login pages on web sites today send the cleartext password underneath the https encryption layer, so the server sees the password (though hopefully stores it in only in hashed or MAC'd form). That is equivalent to http basic auth sent through https.
I use basic auth + https for my own stuff (where I don't care about styling) and it suffices for most things. Obviously you can escalate from there to 2fa, client certificates with credentials wrapped in hardware tokens, or whatever. I haven't needed that for personal stuff so far.
Modern PAKE implementations, like SRP, don't store the plaintext password on the server side, but rather store a "verifier", which is essentially a hashed and salted version of the password. This way the server never sees the actual password, even at the registration phase.
The problem is with the hashing function though. For instance, all the SRP implementations I've seen use fast hash functions like SHA-1, SHA-256 or Blake2b by default. But contrary to folk wisdom (which is unfortunately often repeated here as well), hashing and salting a password is not enough. This is not 2003 anymore, and rainbow tables are not your main threat - your main threat is a cluster of fast GPUs demolishing your hashed passwords at rates that often just start at 1 GH/s.
The best practice nowadays is to use a function which is both computationally expensive and memory-hard such as scrypt or the newer Argon2 (and not PBKDF2!). You could very well do that with a PAKE, but now you run across a nasty UX trade-off: the computationally expensive function would have to be executed on the client side every time the client authenticates. There are WASM implementations of Argon2 out there, so this is probably not a big issue on a beefy PC, but you'll have to aim for the lowest common denominator here, and tune your function for a low-end smartphone.
tl;dr: In practice, with a carefully implemented PAKE, you'll give the attacker a 10-100 times faster hashrate than you would with a plain-text password authentication approach implemented with the same amount of care. In real practice, you'll probably use whatever defaults your library gives you and give often end up with a ridiculously weak hash.
Now, I said this is a trade-off. If you implement PAKE well, you will reduce the resiliency of your stored password hashes against brute force attacks, but this is what you get in return:
* Protection against password sniffing at TLS-terminating proxies
* Protection against hackers taking over your server and stealing user passwords as they login (Online password leak)
* Protection against MITM with a stolen CA key[1]
All of these things are still an issue with clear-text passwords even if you're using TLS. If any of these issues are a concern for you, this means you consider your users' passwords to be significantly more sensitive than the data that flows between your clients and servers, but that could be a valid threat model. In this case PAKE looks like a nice solution.
For everything else, I don't recommend PAKE. It is harder to implement correctly (with library defaults being insecure as I mentioned above), and this is more important than whatever theoretical strengths it has. Cryptographic systems are generally broken because of incorrect implementation rather than theoretical weaknesses in the algorithm.
[1] Not very common, but that did happen in the past: https://en.wikipedia.org/wiki/DigiNotar
PAKE is interesting mostly because we have some infrastructure for dealing with passwords already, but passwords in any form are not optimal.
Scenario 2: The ecommerce site has upgraded to SHA512, so cracking isnt an option. But the site is relying on basic auth, so the attacker simply sniffs your password when you auth.
Scenario 3: the ecommerce site is using a secure zero-knowledge auth against a hashed/salted/peppered/whatever credential. They cannot brute force it, and the server never sees your password. They can mess around with the ECOMMERCE_SITE but cannot pivot to any of your other logins.
>If I was a hacker, I can add JavaScript to send plaintext somewhere.
We've just shifted from "quiet, persistent threat" to "hacker announces to the world that he's in". Changing javascript on a prod website is going to trigger alarms.
While I'd like that to be true, it really isn't. There have been loads of card skimming operations injected into production sites which weren't noticed for sometimes months.[0][1][2][3]
[0]: https://blog.malwarebytes.com/hacking-2/2020/03/criminals-ha...
[1]: https://www.wired.com/story/british-airways-hack-details/
[2]: https://www.riskiq.com/blog/external-threat-management/magec...
But the phishers could do a slight variation. They could create a website that looks very similar to the browser's Basic Auth popup, but implemented in HTML and Javascript. Most people won't notice the difference. Most people don't understand the line of death[1].
[1] https://textslashplain.com/2017/01/14/the-line-of-death/
In the context of the pop-up: a simple pop up can be faked. But what if the browser would flash all the borders (and other stuff outside the line of death) when the real popup is displayed?
I'm not saying any of this is 100% foolproof, just that we should be doing some UI experiments on real people to see what works better.
[1] https://en.wikipedia.org/wiki/EROS_(microkernel)
EROS used capabilities to enforce such rules. If you lack a capability to be a system window, you can't pretend to be one.
I can imagine keyboards having a special “password” key and trying to train people that all passwords start with the password key. I don’t know if this would work, but it can’t be worse than Ctrl-alt-delete.
Yes, it would. A further improvement to an improvement doesn't take away from the first improvement. Don't let the perfect be the enemy of the good.
Server sends client a salt, client hashes the salt and password and sends back to server.
Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).
The point is that a malicious or badly-secured site can't use your password on other websites, because ultimately most people use the same password on many different sites.
1) A different salt each time, meaning the server must know your plaintext password to validate, or 2) The same salt every time, in which case the hash is essentially the password since that's all the attacker has to pass to the server next time.
Please, stop using those strawman arguments
In any case, though, it seems likely to reduce the impact of a compromise.
Or equally as bad. TLS only protects you from sniffing, not the server seeing your password in cleartext.