Hacker News Reader

Comment by nmc | Hacker News Reader

This "Facebook approach" almost certainly requires you to have, at least once, access to your users' non-hashed passwords.

Which is widely regarded as bad security practice because your users' passwords can be compromised by an attacker getting read-only access.

[EDIT] Well, good thing I used "almost", since I was wrong: of course, case-inverting the password and hashing the result could also be done client-side, silly me!

[EDIT'] Answers pointing out that you always have access to non-hashed passwords, and I believe this is wrong. When the user submits their password, it SHOULD be hashed client-side and only the hash SHOULD be sent to you.

View on HN

> When the user submits their password, it SHOULD be hashed client-side and only the hash SHOULD be sent to you.

No. If you are going to do something like this, do it properly with something like a zero-knowledge password proof.

As you describe it you are introducing a huge flaw: If your password database leaks, an attacker now has everything they need to log in to user accounts, no password hash attacking required.

You always have access to the user's unhashed passwords when they submit it. In authentication, hash the raw password and invert case and the hash that. Then compare the stored hash against both hashed passwords from the input.

There is no need to store the password in plain text in any form.

If you send a hash instead of a password, that hash _is_ your password. If I steal the hash but not the string it was derived from, I can pretend to be you and log in.

You do have access to their non-hashed password. When they type it into your form and press enter. You just invert the case and check it against the hash again.

Why not including the lowercase into the hash-algorithm?

A hashing algorithm specifically for passwords that would hash to the same thing based on inverted caps lock or other deterministic user errors (white space at the edges, maybe)? That sounds like a great idea.

If you hash the password client side, then the hash is the actual password and the server still sees the actual password.

You're right that it's bad to store non-hashed passwords, but your point about security is unfounded.

Facebook, and any other company you'll log in to, requires a non-hashed password at some point to check against the hash. You need a cleartext password at some point, otherwise the user can't send anything to you.

The best practice for security is to not store passwords in cleartext. You can certainly perform extremely limited actions on passwords in cleartext (like hash checking), and you inevitably have to.

Which brings me to my overall point - as the Facebook security team has explained before on their whitehat page, you do not practically reduce security by allowing caps lock inversion to check a hash.

What you're saying about Facebook having an abnormal process also isn't true either - Facebook does one of two things, both of which are secure:

1. Stores two hashes for each password, one the real password and the other the case inverted, or

2. Checks a password against a hash, and inverts the case and checks again if it fails.

There is nothing about this which is different from normal password transmission in cleartext, and Facebook doesn't store the cleartext password you send them.

EDIT to your EDIT:

No, no no no no, no. Don't do clientside things like that. Allowing a user to directly manipulate something as major as whether or not their password is hashed before it is sent to you is bad. It doesn't even matter that it's just them hacking themselves; it's just bad form to put that in their browsers' hands. Plus, a stored cross-site scripting error that went viral on the login page pre-auth could screw your password database, leading to a layup for mass cleartext password compromise. Or in a worse scenario, you're giving a user direct write access (and then maybe reads) to the password database.

It's much safer to do the industry best practice of destroying cleartext sensitive information upon successful hash.

Say no to clientside security. There are arguments for hashing clientside, but they can all be summed up by "You shouldn't let people potentially sniff users' passwords" - if you implement TLS/SSL correctly, this won't be an issue and the cleartext password will exist briefly, then get destroyed.

The one other argument is that someone could compromise the server handling the hashing process and write a script watching all the passwords. But this isn't a valid concern - if someone has backdoored your login server, it no longer matters if passwords are cleartext for the damage they'll do. The level of difficulty you introduce by having passwords hashed originally becomes moot at that point.

Finally, consider that a client-side hash of a password sent to a server becomes the effective password for that user, not the hash of the password. This means that, effectively, if no other action is done at the server, you're actually then storing the password in plaintext. If a user was MITM'd while sending the password, the hash can now be sent directly to the server in place of the user's password, because it is the de facto password.

The bottomline: client-side hashing offers no real addition to overall security posture under TLS/SSL, and removes most of the benefit of hashing.

> if someone has backdoored your login server, it no longer matters if passwords are cleartext for the damage they'll do. The level of difficulty you introduce by having passwords hashed originally becomes moot at that point.

If your hacker has a cleartext password and their login ID (email address), you've just given the hacker access to a bunch of their other accounts on non-compromised sites (for the significant % of your userbase that recycles passwords). I think the possible collateral damage creates a far more severe worst-case scenario.

That's a fair point, though it doesn't outweigh the myriad other reasons not to do client-side hashing.

Security is always a battle of usability and tradeoffs. Client-side hashing simply doesn't make sense for security. It removes the fundamental point of the hash in the first place and introduces an avenue for possibly attacking or manipulating your database.

In fact, there's hardly ever a reason to do client-side security.

Perhaps you can quality "client-side security"? You mean never trust the client right?

Yes, that's exactly what I mean. Treat all user-input (and by extension, client-side anything) as dangerous. A server putting a security protocol in the hands of the client when it is not unavoidable is usually bad.

If they have access to your server they can inline javascript that will do the same thing on the client. The client is not secure, ever. If the users are reusing passwords, it's not something you can same them from except not saving the cleartext password yourself. Database attacks are different from on line interception.

> Facebook, and any other company you'll log in to, requires a non-hashed password at some point to check against the hash. You need a cleartext password at some point, otherwise the user can't send anything to you.

No, they really don't need that. C.f. SRP (http://srp.stanford.edu/) and similar protocols, where the end user performs a local calculation and the remote party is able to verify identity without ever knowing the password.

This could be the workflow:

1. User enters email address at site. 2. Site sends an email containing a URL with a 512-bit query parameter (yes, this means that user's ISP—and anyone else with access to the email—could sign in once). This parameter might be HMAC(secret, address), enabling the server to store no state for unverified users. 3. User visits URL, and sees a form for email address and password entry. There are hidden fields for the crypto parameters. 4. The user's browser takes the user's address and password, generates a random salt, and calculates a function of the crypto parameters and the local CSPRNG to get the salt a function of the address, password and crypto parameters to get the password verifier. 5. The user's browser POSTs (address, salt, verifier) to the server

Then whenever the user logs in, the browser and server engage in the SRP exchange.

The server never knows the client's password, ever. Nor is someone who knows the verifier able to forge the password.

The best practise is never to transmit sensitive data in the first place.

Hashing client-side is not a good idea in practice — a leak of your password database leaks direct credentials for logging in. If you're going to go this route, something like the zero-knowledge SRP protocol is necessary.

Assuming that you run your own login service like Facebook does, you always have access to your user's passwords at least once because at some point you have to take the raw password and hash it. Facebook just creates two variations of the user's password and stores the hashes for all three of them.

All three of them? The Hash for the password as-typed, another for as-typed.invert(). What's the third? I feel like I'm missing something obvious. :-/

Mac-style caps-lock, which doesn't invert again with shift, and PC-style, which does.

First letter uppercase, for mobile devices that default to shift being on for just the first letter.

Possibly for the two different types of caps lock. The kind that inverts the case of everything and the kind that makes everything uppercase.

I never noticed that. (I switched to Macs around 8 years ago.) Huh.

In that case I guess I have to wonder what the point is? Why store three hashes as opposed to just upper-casing the plain-text before hashing? You end up storing fewer variations, and it makes no functional security difference to the front-end (since any attacker would just .toUpperCase() their inputs anyways)?

At least best I can reason.

> Answers pointing out that you always have access to non-hashed passwords, and I believe this is wrong. When the user submits their password, it SHOULD be hashed client-side and only the hash SHOULD be sent to you.

If you insist on doing this, you can always invert it and hash it on the client side, and send both hashes. You still have access to it, just on the client's computer (running your own code).

Reply on news.ycombinator.com