Hacker News Reader

Comment by aimor | Hacker News Reader

Why has authentication moved away from making passwords safer? I like to imagine a system where the only thing that ever sees my easy-to-remember password is the browser, everything downstream gets a unique client-side hash. We did this manually in the past with various schemes, we do this today with extra steps using password managers, why aren't browsers simplifying this? (or maybe they are?) My understanding is that these schemes (say, hash your password with the domain name) are vulnerable with enough samples, but it's still better than sending your easy-to-remember password out to the internet. The answers I hear online are that there's no value added since everyone should use unique passwords to begin with, but people don't do this because it's extra work even using a password manager is extra work, the default needs to be more secure.

View on HN

My take on client-side hashing schemes is that they help with raising the floor -

  - they ensure that the backend application never sees your password in plaintext , and prevent the worst case scenario of a plaintext data dump
  - password hashing is CPU intensive by design, and pushing that work to the client means you can have them do the work and increase # of iterations far more aggressively

but fundamentally still leaves users vulnerable compared to other approaches. For example, client-side hashed passwords can still be phished, and are not domain-bound like Passkeys are.

I think with the "X can be phished" argument, there is a massive tradeoff to keep in mind: Everything where you as a user have direct access to the key can in theory be phished. So the only way to make credentials unphishable is by hiding the key from yourself and entrusting it to a third party, in the way that passkeys work. However, now you're entirely dependant on that third party. The question is if, everything considered, this is really such a big security improvement for you.

I think an alternative approach would be to accept a certain risk that credentials can be stolen and improve the ways in which stolen credentials can be revoked.

What sort of hashing algorithm do you use?

I think this would complicate salting (making rainbow tables or brute force attacks easier). The client needs to know the salt so on a fresh device I think you're limited to - using the username as a salt - adding a second secret input field for the salt - allowing the client to request a salt without authentication (which would verify the existence of an account)

& after trying to solve those problems, there's still mTLS or passkeys that offer better security anyways.

A password manager may be extra work but it's pretty minimal nowadays. On Chrome, it will automatically offer to generate passwords in signups and save them. If you add a Google, it will sync passwords between devices. Sure, everyone may not want this, but it's easy for less tech savvy people and still fairly secure

If you want to log in from a different browser or device they need to agree on how this hashing works. This also means that everyone else knows how this hashing works and can construct rainbow tables for it.

Still better than plain text but nothing stopping a determined hacker.

Anything else is just encrypting the transport, which we already do with HTTPS.

Otherwise there is the ongoing work to of passkeys.

Because 2fa lets password breaches be blamed on the user.

You trust your browser?

Reply on news.ycombinator.com