4 ms·

Personally as a developer I'm not thinking Facebook is bad but rather that in general we are bad and we pass over plain text passwords to endpoints (through SSL

Personally as a developer I'm not thinking Facebook is bad but rather that in general we are bad and we pass over plain text passwords to endpoints (through SSL) and just trust the data will not be abused (logging) but would be cool to have client-side encryption prior to sending to any 3rd party so figuring out a way to do that cleanly on different devices where a password, although the same everywhere possibly but is always encrypted uniquely for a particular company prior to going over the wire so even if compromised internally would only be for that particular service. This is probably just a legacy problem in the end where a new approach would simply make this problem obsolete like a yubikey or built in protocol at some point.

sebringj 8y ago
All the answers I see on stack say there is no gain to do hash or encrypt prior to sending. I'm not sure I can agree with this. Let's say you hash a password and some attacker gains this. They can now log into that website BUT NOT everyone else for your username if you happen to use the same password. Jeez am I wrong here?
- johnnyRose 8y ago
  I have looked into this in the past and came to the same conclusion. Essentially, the "password" sent to the website is the client-side salted/hashed version of the user's actual password. The server could then salt/hash the "password" another time before storing it. This could result in the same issue if the "password" is logged, but it protects the user's true password from being discovered. Maybe a security expert can weight in on this, because I don't understand why this wouldn't be the standard.
  - lixtra 8y ago
    Ideally the server doesn’t need to remember the salt it sent to the client, so it should be signed together with a timestamp to avoid reuse. While you’re at it you can also add some hash puzzle to be solved by the client increasing difficulty with failed logins.

sebringj 8y ago

All the answers I see on stack say there is no gain to do hash or encrypt prior to sending. I'm not sure I can agree with this. Let's say you hash a password and some attacker gains this. They can now log into that website BUT NOT everyone else for your username if you happen to use the same password. Jeez am I wrong here?

johnnyRose 8y ago
I have looked into this in the past and came to the same conclusion. Essentially, the "password" sent to the website is the client-side salted/hashed version of the user's actual password. The server could then salt/hash the "password" another time before storing it. This could result in the same issue if the "password" is logged, but it protects the user's true password from being discovered. Maybe a security expert can weight in on this, because I don't understand why this wouldn't be the standard.
- lixtra 8y ago
  Ideally the server doesn’t need to remember the salt it sent to the client, so it should be signed together with a timestamp to avoid reuse. While you’re at it you can also add some hash puzzle to be solved by the client increasing difficulty with failed logins.