We didn't encrypt your password, we hashed it

I do think the message got a little lost in the post though, with the follow-on discussions of salting, bcrypt vs. md5, etc.

Reminds me of an experience I had in college. I was working phones over the summer at a call center and had this software developer call in. This was during the runup to Y2K, and I mentioned the "Y2K bug" and he starts ranting about how it's not a bug.

And I'm like, yes I understand it's not technically a bug, but most non-technical people don't know the difference.

I've never understood why people are like this with non-technical folks. If you're having a technical discussion with another technical person, then yes, the distinction absolutely matters. But to non-technical people? Who exactly benefits from that?

The sysadmin resigned, no tech person anymore. The boss got a lost password inquiry from a customer, panicked, called former admin for help, not a single word he understood, hit the forum.

And in the forum post he said the admin “wouldn’t cooperate”, “very adamant and confrontational” about “giving out encryption keys” to “decrypt valuable customer database we can’t afford to rebuild but might have to” and how it’s driving the company towards bankruptcy over last few days etc etc.

Eventually forum members realized he’s talking about a password reset, and convinced him it’s actually impossible to recover hashed password nor it’s necessary which is the point, you just verify identity and let them change the password etc etc, but it took hours for the community, on top of a day and half or so of tense hours for the boss guy’s company, to just understand the situation and act accordingly.

So I think it might be worth communicating how passwords work every once in a while.

And my mum who's not really techie does care because she gets emails from Yahoo and the like saying sorry we've been hacked yet again please reset your passwords and gets in a panic over it.

The problem is that the term is _inaccurate_ because it is _overly precise_.

---------------

When you find yourself arguing over details you find pedantic, then it is a sign that you either:

A. Are failing to realize why some detail actually _does_ matter in that context.

B. Are using overly-precise terms and should see if you can "go up one abstraction layer", likely by asking "why does someone care?"

Please don’t do this. For one thing, SMS is fundamentally broken as a secure delivery method. But more than that… it’s just so, so deeply annoying.

Literally this converted into:

1- Users abandoning on sign-ups "oh how am I supposed to find a password I will remember"

2- Users bashing us on the app store reviews: "make it super hard to sign-up" even though we only ask for username and password, not even an e-mail

3- Users logging in, liking the app, then a few months later when they got logged out for whatever reason, completely forgetting what their password was and not having a fallback e-mail.

We ended up pulling it back. We just have a small note now that says "easily guessable password" but allow them to proceed with registration.

This is both good and bad. When I needed a whole team to have access to my account, I just built a mailing list, and used that address for signing up. Yes, it was annoying that we'd all get email every time someone logged in on a new device, but it was also pretty straight forward to use.

I never hear about the term "workshopping copy" but I believe it is one of those underrated skills that is fundamental in communication online.

"Scrambled" is imprecise enough that it could mean either hashed or encrypted. In radio usage, it specifically refers to encryption, so someone researching "scrambling" would get confused very quickly by that explanation.

The main argument I've heard against pepper is because people are afraid of losing the pepper. It either needs to be directly in your code which is easier to leak, or out of band which is easier to lose.

edit: Does anyone else want to goto waffle house whenever they talk about salting and peppering their hash? Too bad the closest one is an hour away.

There are many attack scenarios in which storing a secret separate from the DB doesn't get you much at all. Suppose an attacker finds an RCE vulnerability in the application – then they can slurp up the contents of the DB, but they can read the pepper from the configuration too.

Suppose they just have a SQL injection – they can't directly get the pepper from a SQL injection, assuming it is being stored somewhere outside the database. But, it may help them do it indirectly – for example, they could UPDATE their account to have admin privilege, and then access admin-only features of the application which may end up revealing the pepper. I've seen many apps which have admin-only screens to run arbitrary scripts, view configuration files or environment variables, install plugins, etc – those kind of features are helpful in supporting the application, but can be used to turn a SQL injection into more complete control over it

Salting is easier since it can be completely wrapped up in the key derivation function. The programmer doesn't have to know anything about it, they just use generate_key(passwd) and check_password(passwd, key).

Upon password creation:

1. Generate hash as hash of password + salt.

2. Encrypt the hash with a public key from KMS (you can store the public key in your server code).

3. In your database store the encrypted hash, the salt, plus some "key ID" that identifies which KMS public key you used (this is so you can rotate keys later).

Upon user login to verify the password:

1. Retrieve the user's encrypted password hash, salt and KMS key ID from the database.

2. Make a call to KMS to decrypt the hash (KMS internally stores the corresponding private key but never lets you access it).

3. Then hash the password the user entered + salt and compare it to the decrypted hash to see if there is a match.

Benefits of this are:

1. If an attacker steals your database, they can't decrypt any of the passwords or the password hashes.

2. KMS never exposes the private key of the async key pair, so you know this won't get exposed either. The only way to decrypt something is to make an API call to KMS.

3. Thus, the only valid attack really is if the attacker is able to gain the same access privileges as your server. But even then they still need to call KMS one-at-a-time to decrypt hashes, and all of those KMS calls are logged in an audit trail, so it should be much easier to see if you have anomalous calls to KMS. There is a huge benefit here in that it is impossible to do bulk decryption without a giant audit trail.

Preferably one generated by a password manager, large and random and totally unrelated to any other password of the user.

The server would only ever have your 'public key'. I'm not sure where you get the saltiness to prevent lookup tables but still let me log in from three devices with the same credentials.

Indeed. I don't understand why challenge-response auth isn't more widely deployed, or even part of the web APIs.

Sure, it doesn't mitigate ALL attacks, but it does mitigate SOME attacks even if you're already on TLS.

You take your letters and substitute them for numbers, A = 1, Z = 26.

Like a checksum, you add all the letters together. The same word produces the same sum each time, but if I had the sum, I wouldn't know for certain what the original word was.

Just make sure you use a suiting AES mode. If it turns out that you xor'd all hashes with the same stream that depends on your pepper only, it's not really helpful :).

One, slightly longer password checks. And two, the temptation to lean on the AES key and set the cost of the hash too low. In the case the key does get out - we had an entire era where people stole environment variables from servers - then you decrypt the entire password file once and have cheaper guesses per second.

The downside for the scheme is complexity and limited upside; complexity gets a lot more attention when it comes to security considerations.

Best practice especially needs to be simple; it's easy to mess this stuff up and hard to understand. A lot of the comments on this post betray a very poor understanding of password storage; they simply haven't come across the correct information.

Overall pepper is good as long as you include salt. There are times when the db gets leaked and the env variables don't.

There's nothing wrong with your scheme if it's implemented properly, but being able to change the site-wide key is a limited upside compared to using a pepper. There is an upside though.

And all of this doesn't matter much as long as you do the bare minimum of using a tuned pbkdf+salt and keep your stuff patched.

Often you cannot do better in explaining it without doing a mini course. And people would have to sit down, concentrate and work through the new concepts and that's tiring, looks like school, "I was never good at math", and you lost everyone. You can't make the average person understand hashing, mainly because the don't care and will glaze over. You can dress it up with engaging stories and metaphors, and they will remember the engaging story but not actually build the right mental model if you actually poke at their understanding.

Doesn't this answer your own question? (ideally email password reset should also require MFA)

As another, non-security point, occasionally it can take a good few minutes for emails to arrive in your inbox. Though to be fair, that's sometimes the case for SMS too.

Effective security is tailored to the situation: the app, the users, and the adversaries.

Login emails are slow and require multiple steps. The user must enter their email into the website, switch to their email client, wait for the email, open it, and click the link. If the user's email goes down, they cannot log in to the website. Some folks get distracted while waiting for the email. Sometimes a login email will get marked as spam. Sometimes a user permanently loses access to their email account. These things reduce user engagement and increase support costs, and the company makes less money.

There are many ways for attackers to obtain email: DNS, BGP, email server, email server backups, user device backups, malware, re-used passwords, and phishing.

There are only a handful of ways for an attacker to obtain passwords: malware, password re-use, and phishing. Notice that this is a subset of the attacks on email. And passwords have special mitigations. Some devices have password managers that resist malware. Security teams have various options for reducing password re-use.

Good authentication depends on something you know (password) and something you have. Password managers turn something you know (password) into something you have (device). Criminals rarely steal devices to gain access to online accounts. So in practice, something you have is just as good as something you know.

Wonder which one your teenage son likes better? Of course the answer can be skewed one way or the other knowing which one was written by his parent :-)

'Who you are' is your username. 'Are you allowed into this system' is your password.

The only thing that bothers me here (not sure why) is something about the fact that if the user changes their email you get a pass change as well and that might signal an account take over if your system is analyzing behavior stuff like that. Could be wrong on my gut feeling here.

Having a salt means that the universe of password:hash correlations is different for each password entry.

They are just trying to avoid a quick lookup in a pre-computed table. Adding a salt means they have to start from scratch.

Uniqueness is not really a factor, reversibility is. Given a hash will be fixed-length, and passwords can be an arbitrary length, you get a very large number of passwords mapping to each hash. But the key is to make them hard to find.

So for the server it's good to have a strong (which often means slow to compute) and non-broken scheme. Something like MD5 is just too fast to compute, if someone is targeting you in particular (and not the entire breach) you might have a bad time anyway. Some schemes have a work factor meaning the computer basically repeats calculations a lot to waste time, which a cracker would also have to do. This factor can be updated to keep up with computing power over time.

On the client the best you can do is not reuse passwords, make them long, and try not to overlap with any known wordlists (dictionaries, past breaches, etc).

Obligatory xkcd comic link: https://xkcd.com/936/

Either you stopped reading 1 sentence too early, or you are posting in bad faith to try and smear Troy.

If we use MD5(password) then brute force of a 14 character random password (say using a 64 symbol character set) isn't really viable because you need to try about 2^84 values. MD5 isn't an acceptable password hash, but using a strong random password was enough to save us.

But if we use LMhash(password) that same password can be brute forced in just 2^43 operations. This design is so bad that there's no way for the user to protect themselves.

This popularized Rainbow Tables. You may use a time-space tradeoff for any hashing scheme that doesn't have salt, or doesn't have enough salt compared to how much it's used, but for most schemes a strong random password overwhelms the power of the time-space tradeoff anyway. Rainbow Tables tilt this tradeoff so that it's more favourable in exchange for a modest reduction in effectiveness† and for LANMAN they're enough to turn it from "If you had a super computer and hundreds of gigabytes of disk space you could crack any Windows password hash near instantly" to "If you have a mid-range PC with 5GB of hard disk space and download this software you can crack 99.9% of Windows password hashes in a few minutes".

†For a lot of pre-computation effort you can get all the effectiveness back. But that's not important here.

There were other lessons too, but that was the main one.

scrypt is a popular KDF, i think you'll be fine with that.

If you use scrypt, you won't be able to get the file back out ever again.

If you use lzma, it's compressed, not encrypted, and anyone who gets the compressed data can trivially decompress it.

Consider using an nacl secretbox if you need to encrypt it.

Consider very carefully where you'll store the password.

Does the user input it each time they access the file (in which case use a key-derivation-function on their password)? Do you encrypt it with an application key? Per-user key stored in vault? Do you have a hardware encryption tool available (an HSM) or something like aws KMS?

Your encryption is only as secure as you keep the encryption keys.

See also [0] for some suggestions.

[0]: https://latacora.micro.blog/2018/04/03/cryptographic-right-a...

I don't know why you are base64 encoding things before sending them to the DB. Just use a binary blob.

scrypt is a hashing algorithm, not an encryption algorithm. So that doesn't seem like what you want.

LZ-String is a compression algorithm, that's trivially reversible.

The problem you'll run into is that the "right" encryption algorithm is constantly changing. Probably the best thing to do would be to not do it yourself, instead, rely on encryption capabilities of your DB if provided. If you opt to doing your own encryption, then be prepared to constantly maintain and update it. Pushing that responsibility onto the DB makes that burden a simple "make sure your DB is up to date" Which you should be doing anyways.

It's not just because the decade counter changed that everyone must rewrite their systems using the latest fad.

Because once you salt it (use a different salt for each hash, which solved your collision issue) and purposely slow it down (through multiple rounds,etc) it effectively ruins precomputing the hashes because of how many permutations there are.

Of course this depends on which hashing algorithm you use. Md5? You can do millions a second. Bcrypt? You can make one hash take 100ms, that’s 10a second. They also use a random salt for each hash - so precomputed hashes will only work for that hash.

The issues you highlighted are very real for md5, but there’s a reason md5 is not recommended for passwords.

Cryptographic hash functions are one-way in the sense that (unless they are shown to be broken) it is not believed that there is a computationally tractable way of recovering the unhashed input from the hash. You can always brute force it, but even "just" for passwords, the input space is way too big for that, especially if you use a salt - unless you use a very common password, of course (even if limited to 26 letters and 8 characters that's over 200 billion different passwords).

So, most of your comment is just wrong, except for the part about how Wattpad stores passwords, which is just very likely wrong, since I can't prove it.