Hot Topics:


Why you don't store passwords, explained

From: Dave Brockman 
Hash: SHA1

Well written article with a mini crib-sheet guide included :)


Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird -


=============================================================== From: William Roush ------------------------------------------------------ Is running it through bcrypt SO hard? :( William Roush

=============================================================== From: James Nylen ------------------------------------------------------ Lol On Tue, Nov 5, 2013 at 3:47 PM, William Roush wrote:

=============================================================== From: Stephen Kraus ------------------------------------------------------ Its more 'why you don't just encrypt your password database with a broken encryption system' Hash storage is what they were supposed to do.

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No, it's "don't store passwords, including encrypted versions of passwords". Hashes != passwords. This isn't one of those applications that should actually save recoverable passwords. That's what KeePass is for, not Adobe's back-end licensing server(s). Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - iQEcBAEBAgAGBQJSeWvsAAoJEMP+wtEOVbcde0IH/2FvJKNYxjuwSYNzzs2McYSE NRJFUlLJqCUeEun/jUdkSvxw1auGa439Fu6vengGtcp2DUiggr19lfQrOsK6Yu4w j1g4wh20ySdOMfE7Q6fZL4/akBv7A6anNdDpnul4d9vs4Qg2edj9umWbM1CK6xSs PKLTnH1ZZ1Luz2vLm/dpLZtSxiUmMKuwrfE6asf6aE0OVWrJWpoUdwNpT5qT/Pnq IAd0sBLVRfdbdAq6qp5LbNia32+mGc3RBAwPGCfAAVK0A9+hiAkK/9X9c4uye6kS SLYf/cX+q5/2TWfTZZ6JWH52rjBU28KC2hzgc7es6saYGJgR5QIZ0x3OvC+55zs= =YrVA -----END PGP SIGNATURE-----

=============================================================== From: Stephen Kraus ------------------------------------------------------ Um, correct me if I'm wrong, but a back end for a licensing server for your products should have the usernames and passwords associated with the keys else would you associate an account with its users data? And correct me if I'm wrong but if I (Sagan forbid) lose the password associated with a very expensive product key, there had better be a recovery route.

=============================================================== From: Stephen Kraus ------------------------------------------------------ Let me clarify: the hashes are associated with the seperate usernames and passwords on a seperate database

=============================================================== From: wes ------------------------------------------------------ dave is drawing a distinction between an encrypted password and the password's hash. it's subtle, but it's there. -wes

=============================================================== From: wes ------------------------------------------------------ the passwords themselves don't need to be stored at all. just have the username and its password hash along with its license info and you're done. as for recovery, if the password's been lost by the user, having it stored in the DB isn't going to do anyone any good. it's not like we should decrypt it for them and send it to them in an email.... -wes

=============================================================== From: Dan Lyke ------------------------------------------------------ So you want to store some identifying information to manage ownership of the licensing data. Historically, this has been done with a unique identifier (User Name, email address, something else that's public and that you can use as a primary key) and a password (secret known only to the user that can be validated by the server), but there are lots of things it could be. For instance, in a perfect world you could imagine that you have a public/private key pair, and Adobe has a public/private key pair, and Adobe encrypts a encrypt a random number with their private key and your public key, sends it to you, you decrypt it with their public key and your private key, do some manipulation to it, and send it back encrypted with their public key and your private key. And this would all be done in the browser behind your back (there are initiatives in this direction). But for the password, what I, as a software developer making web sites that use usernames and passwords want, is a mechanism whereby I can say "this is the same password that the person with that primary key gave me last time". The way you do this is with a hash: You get the password on sign-up, and the first thing you do is munge it in a way that throws away information about that password, but in a way that is hard reverse engineer. And the difference between encryption and the hash is that encryption is reversible. It's not throwing away information. This is why a password is only one identifier stored with an account. Other identifiers include email addresses, phone numbers, other personal data. You don't ever say "here's your old password", you generate a new password, give it to them via these other identifiers, say "here's your one-time identifier, use this to change your other password". And, really, what you want isn't "user gave me this token so I'm sure it's the user", it's "user has presented these sets of identifiers (including, for instance, geolocating IP addresses and saying 'whoah, that dude doesn't live in Siberia') and we think it's probably the user. Identity is hard. Dan

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK, you are wrong. There is no need to store anything but a hash value, salted preferred. There is absolutely zero reason for the licensing server to know my password. You associate with the serial number of the product, tied to an email address, authenticated by the user by comparing the hash. At no point does the password need to be stored on the back-end server. Again, very easily accomplished. That's the reason why your password can be "reset", but you can't be told what the current value is. Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - iQEcBAEBAgAGBQJSeXetAAoJEMP+wtEOVbcddJMH/0hvDT3CyD9xcyknZO6NOGaP slT7XjJrrMVACesIvbwGYPv66Fvgq31B8YV/KL5pLLOqn3FSL3mI/Mwn8E1Mfh+C qBTfZ7qLFxZWKucLdx8CC4ARymMVVjevUTUNSPHX3f7Bmnc13uOCY9A8mGrvA229 k4nTptZgZL8St7/aFZdDNsVM39k/JazDYc7pBk32PgGMg5/sg1c2wUOrxfbRmnOz FmjW5bDBLBVAYxTI4Z1AQvMHxs55mJKdaWri4sSwEFOLCAqeF0Jy0qGcMiIsBpRK onK2yCm8hWx7C0odOecmtvFS/IFChr/CUQCUEiupIQEIeuSg9oXONAGLfH8luAY= =tGsZ -----END PGP SIGNATURE-----

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No, at no point does my password need to be in ANY database. The appliation needs to know how to recreate the hash, salt to taste, and compare that to what is stored in its tables. If they match, you are good. If they do not, you entered the wrong password. Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - iQEcBAEBAgAGBQJSeXgCAAoJEMP+wtEOVbcd9k0H/iNQurKdEhWyXvN22vuiKNYh M8d2sg3UX88ryHKB8AbubsDgs0Wy8NWAK5ZoA5eCtob5csvQuUHowcrZjp4gTP8o f9Nc/tm1mSbaluKbArX+S2aJYLIVn1w399psV3EVW+/XmvwXNGZJ/SZOhHicaLYX 3jGRdvxx2Dt6C6Kd7AC+I4XV3H1qiGqrhqaeu1bO44iGKU682wLtbDx5+g4ymPdn Z9c7IM1865qGaVIlczcqeeunrGYbcV6OJvwb+KER/S8gntW4VKXcO276+EfdvpKn K1cTvnBh1FTE34goiFro8bIxWp6fzUtGkZZuLufTqiZ+w3UwGyVpXTbMoVM7vKI= =jlEe -----END PGP SIGNATURE-----

=============================================================== From: Stephen Kraus ------------------------------------------------------ Ok, thanks for correcting me Dave. The more I know!

=============================================================== From: William Roush ------------------------------------------------------ Pfft, you're lucky they're not in plain-text. William Roush

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This! Also to Roush, enjoyed your blog :) Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - iQEcBAEBAgAGBQJSelXLAAoJEMP+wtEOVbcdcMQIAKFH6Ln5jdAAhfz1zdIdC5HW AbfxcNYBiERS4+PYYeXjOxgicMRoyo7p0ncLGd3KfcJBhRX/2pZ9tYcNRnBayuOV zVhdqtlSR/+24e0kJvXU1O/Hdnr9yf4uj14OnsW2my/bcytG5Lvg92xkktjmxcA2 KIZqEle7JyoF359wzaCKyVqRDK8m6U8N0ZbzC+OxuotXr+A/afjkDWyW+Akpd193 OAZdAvpL4i1WdhHgrmE5FQw2dZxzYWv7wlqxuloJ0NkisDoTAnmVGdI0alXKLQab ROoSIpxY0GbcB5XOXgcpVUEXgXOtU1hVQqMIjHpMVrItRjxYS0YKCypooFflje8= =+I8/ -----END PGP SIGNATURE-----

=============================================================== From: Mike Harrison ------------------------------------------------------ Not recovery, reset. Then if I socially engineer a password reset, and you try to login to your account, you should be alarmed that your password no longer works.