4 ms·
It has to be plaintext in the db, because they can't reverse the hash back to plaintext to send to you.
by samspot 14y ago
It has to be plaintext in the db, because they can't reverse the hash back to plaintext to send to you.
- pbreit 14y agoNot quite true. It could be (and probably is) encrypted in the database.
- ghayes 14y agoThat doesn't make sense. Three days after you sign-up (i.e. no cache), if they are sending you your password, it can only be because it's plaintext. Unless they are bruteforcing the hash for your convenience... :-)
- pbreit 14y agoThey could two-way encrypt which seems safer to me than plain text but some disagree (I'm not sure why).
- Evbn 14y agoOnly if the keys are well controlled.
- NateDad 14y agoIf the keys were well controlled, you wouldn't have to worry about plaintext passwords in the DB either. But passwords get leaked all the time. If the key is sitting somewhere locally, when they break in to steal the passwords, they can steal the key too. There's no way the program can reverse the password without having the key pretty easily accessible.
- samspot 14y agoCan you elaborate? I don't know any way to take a hashed password and get the plaintext version. When you log into any app i've worked on, we hash the pw you send and match it with the one in the db. This is why you have to get a password reset most of the time, because the company literally does not know your password.
- brian_cloutier 14y agoA cryptographic hash is one-directional (among other things). However, encryption is the the same as hashing, and it can be decrypted. It is possible that they are not hashing your password, but encrypting it, before they put it into the database.
- BHSPitMonkey 14y agoEncrypted, not hashed. As in, encrypted with a key that can be used to then decrypt it later.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- cbsmith 14y agoI haven't seen where it pulls the password from, but in theory it could pull it local session cookie.
- deleted 14y ago[deleted]
- cbsmith 14y agoActually, technically it doesn't have to be in the database at all. I don't know if anyone has looked carefully at the JavaScript, but it appears the password, unlike everything else, is populated from client side JavaScript. It could be stored in a cookie or HTML5 local store or any number of other ephemeral client side storage tricks. It would be set when you login, from your browser. The server might only store an HMAC.