They care (sometimes, sometimes they don't act like it, see https://www.ieee-security.org/TC/SPW2020/ConPro/papers/bhaga... ) that it was compromised.

An end user doesn't have any control or knowledge over the password storage mechanism for any sites, so the best thing is to use a strong random password generating password manager--because that is something the end user can control.

However, for the websites managing passwords, I'd suggest reviewing the NIST guidelines: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

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.

It's not a matter of principle, it's a matter of headaches. It's very unlikely that a customer like that would pay enough to make it worthwhile.

However if the alternative is bankruptcy I think there IS money to be spent on the solution.

You know how employers are skeptical to hire people who start the interview by saying how awful their last/current workplace was/is? Same here. I've definitely met hundreds of developers or sysadmins that I wouldn't trust, and whose services I wouldn't recommend. I've definitely been wrong and hired some of them myself. But I would never say something like that in public. At the end of the day, who's the smartass that hired these people in the first place? I get it's frustrating but such is life, you still have to be professional about it.

Plus, 200 USD/hour for a quick fix looks like a great deal, but even if the fix itself takes one hour, it's rarely a one-hour job with customers like these. You routinely end up invoicing for less time than you spend deflecting their attempts to negotiate the bill, explaining why it took one hour and itemizing it, and getting them to pay the stupid invoice.

Happened to me two times, changed password, locked out, had to reset. then while logging in, I noticed their requirement of 12 characters, at next reset used 12 characters, & did not get locked out.

Ah, now I understand why I got those downvotes. What I meant by "OK" was that it would "work". It wouldn't exhibit the behavior my parent comment was describing. Not that it would be secure or good practice.

The initial signup also checked & showed that toast. But the 90 day reset page did not.

But no one is going to get fired or held back for choosing those 'enterprise' tools. They've spent a lot of money, everyone has a checklist, and people move on, even if there's a breach. And some jr might have pointed out "hey, this open source toolset does this, but is kept up to date and has found 47 things our scanner didn't find" and this jr will likely be ignored.

It’s maddening.

Maybe there's a clever trick I'm missing here.

Of course any proposal to ever hold a programmer accountable for literally anything is always unpopular on HN, for obvious reasons.

Engineers should only be held accountable for decisions they made personally. The unfortunate reality is that, a terrifying amount of the time, terrible decisions are handed to engineering teams as required implementation details from managers, executives, product directors, etc. So should engineers be held criminally accountable for their product manager demanding MD5 hashes on passwords?

Do you think the guy signing off on a bridge or power station design gets pushed around by “product managers” demanding shitty or cheapskate design or construction?

You were arguing that the specs or decisions made above their pay grade forced the software engineers into a dangerously faulty design which they dutifully created and shipped.

Of course management should also be held accountable, but until engineers are forced to have some skin in the game they will continue to be as pliable as wet noodles.

Consider this: who better to blow the whistle on management than an engineer who knows they've been given an illegal order?

What you're asking is for an engineer to be stuck in a place of legal culpability if they do the work, and to be fired if they don't. Added bonus: you mention whistle blowing, but who the hell would they whistle blow to?

If there's a proper industry or governmental group to blow the whistle to, that will also see the engineer financially compensated until such a time as they find a new job, then fine, it's fair to make engineers culpable. Otherwise, you're just making engineers suffer for the bad decisions of those made above them, by making them either legally liable, or risking their jobs.

You're looking to now make it so that there's a punishment levied on the developer, who has no more power to say no than they currently do. You want them to say no, but all you're doing is making it more unpleasant for them to not do so; you've done nothing to make it easier to do so.

I guess we just fundamentally don't agree on how power dynamics effect these types of scenarios.

Right now, the conversation goes, management: "I want x". Engineer: "X is insecure, we should do y instead". M: "Y will cost us X more than x, and it's never going to matter for us, anyway."

This puts the engineer in a position where they need to argue and justify the cost. Compared to "Sorry, I can't do that; it's illegal and I'd go to jail if I did that and was found out." Now the engineer doesn't have to justify anything. The law isn't a burden on the engineer here, it's a shield.

Yes, there are still some scenarios in which management insists. In my limited experience, that's in gray scenarioa where it's arguable whether the law applies. But the point is, it's much easier for an engineer to argue whether the law applies, than whether it is worth the money.

I think you can see these effects in the lengths companies go to protect healthcare data (hipaa) vs any other random personal data.

The equasion should be, for management: "Y will cost us X more than x, but if X is hacked we will get taken to the cleaners"

For the actual engineer to be held responsible you would have to add a formalised approval process, so that its clear who signed what off. Inagine you signed off on something, and then changes were made without your knowledge - that much easier to do with software than a bridge.

The big difference is that companies need professional engineers. Professional approval on certain things is required by law. I'm not sure that would be a good idea for software, but that is what makes the system work for professional engineers.

Presumably there would be repercussions at the government level if a company repeatedly demanded engineers do things worthy of stripping their licenses though, no?

The individual engineer doing the work needs a license, but the company itself also needs a permit to practice. The permit must be held by an engineer, who is personally responsible for the engineering that occurs under their permit.

So, the permit holder needs to worry not just about their own ethical behaviour, but that of all engineers in the company. They are incentivized to ensure the company will hold the public safety paramount, or to walk away if they cannot (thereby leaving the company without a permit).

If the company has a pattern of misbehaviour, it may be difficult to obtain a permit.

So, yes, we agree, if there are repercussions for a company regularly breaking the law, then engineers can and should refuse work that has negative legal or moral repercussions. But in the world of tech, that's not the case.

I personally believe that you, the software developer typing in the code, should hold yourself personally accountable for what you are typing in. You might also be designing what you type in, or even setting the requirements, but it might be other people. Regardless, you are making the software come into being--you're the one coding it and pushing it to the repo, so you should set the standard of what is acceptable. This "well, boss told me to do it!" rationalization and blame-shifting is how we get dangerous and unethical software.

And, yes, I have quit software jobs where I was asked to write software I considered ethically questionable, and failed to change the boss's mind.

No, I am suggesting that there is significantly more grey area between your moral highground and reality.

> I personally believe that you, the software developer typing in the code, should hold yourself personally accountable for what you are typing in

Yep.

> This "well, boss told me to do it!" rationalization and blame-shifting is how we get dangerous and unethical software.

It really is a strange world that, when corporations are attempting to turn profit on illegal behavior, it's the meaningless bodies-in-seats that we're trying to hold accountable.

I am, and have been, repeatedly, suggesting that the lowest level cannot be held accountable without holding the rest of the levels accountable. Jailing engineers for doing things their companies demanded of them is ridiculous if you're not also jailing those doing the demanding. I'm kind of shocked this isn't painfully obvious.

> And, yes, I have quit software jobs where I was asked to write software I considered ethically questionable, and failed to change the boss's mind.

Congratulations, that's a level of privilege lots can't afford.

  Please login
  Username: __________
  Password: __________

(Not that I can read German to the standard required for understanding laws and looking it up for myself; I can just about manage tabloid newspapers…)

It should still be consistent with registration/login with things getting truncated, but I think this is also the default in PHP if you are using password_hash() today. Is that a security issue?

https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

I don’t think it’s “a default”, it’s a fundamental limitation of the algorithm.

Specific bcrypt libraries could implement length-reduction by default though.

Or better yet, pick one of the other algos with better limits and protection like Argon2 or Scrypt.

Iterated password hashing algorithms like bcrypt [2] use a parameter tuneable by the site operator that drastically varies the computational cost of calculating the hash, so a brute force attack on the hash could be required to use orders of magnitude more computational power to crack. The tradeoff is that it will make users wait longer to log in, and (might) incur additional operational cost to the site. This is why it's a tuneable parameter: Up increases security at the cost of user delay and operations.

In theory. In practice, the user delay and operational cost are also proportional to the user's password length, which you don't control. Observe, the leak. This can cause wildly varying response times for authentication attempts, and opens your authentication system up to a DoS attack. The only reasonable solution is to put a small cap on password length so that the longest passwords don't take more than 2-5 times as long to compute, as per each site's tolerance of variance.

So why does the runtime of the iterated hash function depend on the length of the password? In each iteration the user's password is joined to the previous iteration's hash, and hashed together to get this iteration's hash. The runtime of any hash function is proportional to the length of the data fed in, the data fed in includes the user's password, thus the runtime of an iteration is proportional to the length of the user's password. So the runtime of the whole iterated password hash is `O(Iterations * PasswordLength)`.

There are various schemes one could come up with to change the time to `O(Iterations + PasswordLength)` ~ `O(Iterations)`, such as concatenating the first hash of the user's password instead of the password itself on all successive iterations, so all iterations but the first are independent of the user-chosen password length. There could be some security/entropy-based arguments for avoiding this solution, though I don't know what that could be.

[1]: https://news.ycombinator.com/item?id=22749706

It's fine to truncate the password (though ideally you don't do it at a super short length).

The issue you are replying to is referring to when a site doesn't do it for both account creation and login. Which is a bug. A stupid, hard to detect, hard to explain, likely never to be fixed, bug. That only affects people trying to be secure.

Regretfully Enpass doesn’t store this field nor the rest of the complexity rule as part of the password entry. The next time when password has to be changed you have to figure out the underlying complexity rule again.

hypothetically it's "ok" but c'mon..

And in practice this effect can be exaggerated when people don't use random passwords but must actually choose a password they'll remember - because what they'll actually do is choose something easy and then shove a symbol in there to meet your requirement. You may well allow 30+ different symbols, or even more, but the users will invariably pick one of a dozen or so that were easiest to reach on their keyboard and they may learn to be shy of characters that sometimes "don't work" such as quote marks and any local currency symbol even if those are easy to type.

They might write it on a flipboard next to a window.

https://grahamcluley.com/plymouth-passport-offices-pitiful-p...

Hi Westpac.

[1] https://benhoyt.com/writings/dont-sanitize-do-escape/

But yes, at that point all you can do is either complain to the website purveyor or vote with your feet (if the latter is an option).

Obviously for a gigabyte long it's a bandwidth and hash-computing issue :p

Yes, that’s why you put in limits which are way beyond reasonable passwords but way below that. Say a few hundred or thousand bytes.

Also worth consideration: most of these work on bytes, probably utf8. A user wants to be cute and put emoji in there, that’s 4 bytes a pop. So depending how the system counts them, “hospital plane” might be considered 2, 4 or 8 characters.

But wait! Group emoji are concatenation combinations thereof, you can have a single multi-character emoji which is composed of half a dozen codepoints, and two dozen bytes once encoded.

https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

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

The specific clever trick in Rainbow Tables is the observation that rather than storing

  hash(password) : password
  5f4dcc : password
  c2fe67 : jimmy
  25d55a : 12345678

  hash(pass(hash(password))) : password
  153dfc : password
  92fe87 : jimmy
  213eea : 12345678

edit: spelling

Ideally a machine that generates and checks the hashes should be a box without a NIC, connected to the rest of the servers via a bunch of RS-232 ports. This would make extracting the salt much harder, down to effectively impossible. Few orgs can afford such a setup, though, due to the hassle of administering it.

This statement seems like it gravely underplays the numbers.

Traditional Unix crypt uses a 12-bit salt. So this means your precomputation (whether a Rainbow Table or not) is 4096 times more expensive. That's just about plausible though already uncomfortable ("Sorry boss, I know you said the budget was $10 but I actually spent forty thousand dollars").

But bcrypt uses a 128-bit salt. So now your precomputation is so much more expensive that if the equivalent ordinary brute force attack on a single password cost 1¢ and took one second on one machine, you'd spend a billion dollars per second, over a billion seconds, on each of a billion machines, and still not even have scratched the surface of the extra work you've incurred to do your precomputation.

Or to put it another way: Impossible in practice.

Rainbow Tables are a precomputation "time-space tradeoff" attack. You do a bunch of preparatory work which is amortized over multiple attacks and results in needing space to store all your pre-computed data. This is nice for two reasons:

1. You get to do all the hard work before your attack, leaving less time between the attack and your successful acquisition of the passwords compared to work that's necessarily done after stealing the credential database.

2. You can re-use this work in other attacks

But if you're waiting until you know the salt you don't get either of these advantages, so Rainbow Tables are irrelevant.

It's like if somebody mentions the F-14 fighter jet in a discussion about the fastest way to get from Times Square to Trump Tower. Yes the F-14 fighter jet is a fast aeroplane, but it can't go to either of those places so it isn't relevant whereas Usain Bolt is a very fast human so he really could run from one to the other.

But i do agree that centralised storage of everyone's passwords does not make sence.

I've decided to use KeePass and store the encrypted password file in cloud storage - that way it syncs between my phone and conouters, and i can always get at it if i really need to. But it does make logging into reddit on someone else's oc very difficult.

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?"

What a spot-on observation. Maybe this is why I am always so pedantic, even when I tell myself that it's not necessary in said context. Subconsciously, I'm implementing this connection, and I can't turn it off.

relevant MCU quotation, from Civil War,

[ROGERS/CAPT] Sometimes... I wish I could.

[STARK] No you don't.

[CAPT] Yeah, you're right - I don't.

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.

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?

On the other hand, the general water-level of knowledge is frustratingly low at times: I’ve received customer support which insisted that they couldn’t register proof of identity to activate a SIM card for an iPhone, only for Android; a salesperson saying iPhones couldn’t be used in those cheap strap-a-phone-to-your-face 3D headsets; and a previous boss had to tell off one of their own customer support team for saying their product didn’t support Firefox when the only browser installed on the customer support team’s computers was Firefox.

If you encrypt a password, it means that somewhere you have a key that you use to decrypt it to check if it's valid on the user login. It means that there is a way that you (or more importantly an attacker) can use to decrypt the passwords.

Instead if you use a good hashing algorithm is practically impossible to find the password given the hash. Yes if the password is really simple you can get it, but come on, if the password is really simple what's the point of protecting it?

By the way I think that we should phase out password anyway, I mean that I prefer to implement in the applications that I develop a password-less authentication: when you want to sign in a mail (or an SMS) is sent to you, you click on a link with a temporary token and you are authenticated.

No password to remember, not having to implement forgot password, change password, recover your password, not having to store the password, not having the user have to choose a password, and I hate choosing password (in fact I ended up using a password manager that generates random passwords for me, but it's not the ideal solution, because then password have to be synced on all my devices, not all websites/apps have forms made correctly to support password manager, and the password manager extension (Bitwarden) goes in conflict with the integrated Firefox password manager so I end up having password saved in the password manager and other in Firefox and it's a mess).

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.

Once we're in the realm of 'you only have to remember this one password' you might as well use a password manager that unlocks with that password and does the rest for you (be it with autofill or webauthn and the likes).

Yubikeys are fine too, even as a single factor in some cases.

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.

- Our app was _deleted_ without any notice and any means of appealing (didn’t appear in the appeals page, and of course there’s no human support). We even filed a ticket and were told that they couldn’t help us because the app was “gone” in their system. Luckily we require an email address or we would have completely lost the ability to authenticate a subset of our users. - A different internal app was banned from using “Facebook Login” because we were “providing a broken user experience” — the app was not even exposed for login in our system. We couldn’t appeal because the warning notice didn’t allow responding from our mailing list. Changing the primary contact didn’t work either, and we even disabled the login on the app just in case. Still revoked with no means of getting it back.

Google has been less awful to work with, but they make you jump through lots of hoops to get public login permissions. In summary, think very carefully about a third party Oauth solution.

2. If someone has access to your email, you're screwed anyway because they can lock you out and reset every password.

Your email password, effectively, becomes the password for that website. I.e. security-wise, I think they're equivalent.

Every single one of them. Email is a plain text protocol.

There are three components worth looking at. Each of them is popularly secured with TLS.

Firstly, submission, sending an email you just wrote from your client to a server. This is usually done over a specifically TLS-secured "SMTP submission port" 587 although it can also be done with STARTTLS.

Second, relay, getting email from your server to somebody else's server. A large proportion of today's servers default to STARTTLS over SMTP for MX. So this means when they connect to a peer server to exchange mail they'll enquire about using TLS and do so if possible. A passive adversary can't stop this happening.

Finally, delivery. Almost all modern IMAP clients default to using TLS with IMAP, so this step will be encrypted. Even in clients that don't require TLS a passive adversary can't stop them upgrading by default if possible.

This is misleading. Remember our context here is that we're getting a sign-in token for some web site, let's say it's the EXA Metal Pole Limited (Europe) site, example.com

The plain text is stored briefly on EXA's outbound mail server mail-blast.example.com, and then it's transmitted to my inbound MX mx1.tlrmx.org, stored very briefly there, and passed to the IMAP server imap.tlrmx.org.

So that's three servers, but, one of them is controlled by the same people as the site we're logging into. If they want a backdoor they can just make one, they don't need to steal their own sign-in tokens, that would be really stupid.

OK, so two servers left. But those are both operated by me, the recipient of the tokens. Why am I stealing my own tokens? To what end? "Oh no I broke into my own account and have impersonated myself" ?

Now, many people use say GMail instead of their own mail servers. But can we reasonably say these people's mail was "intercepted" by GMail, the outfit they've explicitly chosen to receive and store email on their behalf?

And even if we insist upon using the word "intercepted" this way ("The Buccaneers pass was intercepted by Mike Evans" [Evans is a Buccaneers Wide Receiver, the pass was presumably meant for Mike and so we would not ordinarily call this an interception, but if you insist...]) it's unclear what unexpected gain is achieved. GMail could just build their own backdoor and sign in as you to get the tokens instead of "intercepting" them if for some crazy reason that was what they wanted.

Still we’re in a perverse situation here. Running your own server is getting harder to do since everything operates on white lists, and I wouldn’t trust the big name providers for something like this.

https://transparencyreport.google.com/safer-email/overview?h...

Password reset emails are already extremely common and a way of implementing the "second factor only" method in the OP.

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.

edit: but infosec isn't completely equal to cryptography, so some deterrence like that will prevent some attacks. But it's like adding a real beefy padlock on your door (the hashing), and then putting a piece of tape to keep your door shut. Or putting a piece of tape over the keyhole of your padlock.

And no, pepper is not encryption. Encryption is reversible, you can decrypt the ciphertext with the key.

Hashing isn't encryption / Confidentiality isn't integrity / RAID isn't backup / Income isn't profit

Not knowing the difference doesn't mean there isn't a difference.

I love workshopping copy!

How about:

To mitigate events like this, we only store a scrambled version of your password. Though your actual password can’t be simply unscrambled from the leaked data, it is possible it could be deduced by a guess and check process - especially if you are using a weak or common password.

"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.

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

The only caveat is that your database isn't coupled tightly with your application code, so your pepper remains secret even if your DB is breached (which is usually the case).

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.

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.

If it's just the db that is exposed though, it could be a small added layer of protection.

And yes, I would not ever do it instead of a salt.

Let me explain. for example, I might have my NextJS frontend in Vercel using it's secret management /env tools.

The backend as a vanilla node-apollo-server-express could probably be on a cheap VPS, being monitored/restarted/load-balanced by PM2.

The database would be cloud, either PostgreSQL as a Service, or Fauna or something.

Would this scenario be better than just cramming everything into a VPS and trying to get that as secure/closed down as possible and be done with it (do monthly updates and whatnot)...

I've faced recently this conundrum at job. Small new app will not have more than a few hundred concurrent users optimistically...

One other good thing about keeping things separate is updates in theory should be easier, as besides OS stuff, you only have a handful of applications on each machine. But again, for small apps, it's generally not worth the extra complexity. 3 platforms is likely as far as I go (client-side server, API, DB) in the majority of cases with small apps, and most of the time I'd probably just go with 2 assuming Node can serve both the client and API.

PostgreSQL as a service (or whatever DB you prefer) is worth it, that means somebody else can get backups, security relevant settings, patches, version upgrades etc right. Everything else is probably fine on one server, but it doesn't sound like that would be much besides the backend in your case anyways.

(Ignore md5)

No, I strongly recommend not to do so. The reason you put an salt in is to prevent multiple hashs to be the same (because people use the same password) with a pepper you still protect against cross reverencing the hash with other databases, but any two users in your database will still have the same hash and people tend to reuse passwords (or similar passwords) so this is a very real attack vector to get passwords without really braking any hash fully (E.G.: user with known password on different platform => try out similar passwords => broke hash for anyone with similar password).

So a unique per hash specific salt is the most important thing to do.

Pepper/shared secret can make it additionally harder to crack any hashes as while you know all salts (they are stored alongside the hash) you don't know the pepper.

Lastly there is additional data (AD) (named sometimes differently). Which can prevent some form of hash reuse attacks where you e.g. find some form of attack which allows you to override hashes+salt in the db (but not more). Then you could rewrite all hashes to known ones and get access. Tbh for many systems if an attacker can do something like this they don't need to do that anymore. But for other (often large and complex) systems it's helpful.

The idea behind AD is that you (somehow depending on algorithm) include some additional data which needs to match. The most common example is to use the user id (if immutable) as AD so this hash+salt(+pepper) is only usable for given user and never for any other user.

If you ever write a auth sub-system for a big enterprise system I would recommend you to use salt+pepper+AD(uid), for everything else I would think salt+pepper is enough. But never should you use a hash without unique salt under any circumstance. It's always the wrong path to take.(For password hashing.)

Or at least that's my opinion.

The SHA-family cryptographic hash functions are purposefully designed for throughput, if you combine them thousands of times like in PBKDF2 they can be fine. One round of SHA256 is trivial to brute-force especially with the plethora of ASICs available.

HMAC is also completely unnecessary here, and see the article title for your variable naming: it's not encrypted_pw it's hashed_pw.

Further, there’s so little reason not to salt, so you ought to do it. It’s built in to the hash strings in most modern pw hashes. Peppers are also a great idea. Defence in depth!

Not commenting on the overall idea, just pointing out that the criticism of md5 happens not to be valid in this case. I was surprised too.

However for password hash functions to be useful they also need to have a high work factor to make brute forcing even more difficult.

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

But what about having separate auth sub-service with separate database.

Who says a SQL injection allows yourself to update your account to be admin. (SQL has their own permission system even through its not used that much).

Who says making yourself application admin allows yourself to do more then banning users.

Sure for many especially smaller systems pepper won't help much and AD (additional data) is even less likely to help.

But for many (especially bigger/enterprise) systems this might very well not be the case.

Furthermore pepper usage tend to not really hurt.

I think it's a fallacy to assume just because many less well build systems allow SQL injection to escalate that all do so and pepper is useless. Especially given that most systems need to have some config secret management system anyway and as such adding a pepper tend to be somewhat cheap to to (dev effort) and doesn't really cost much at runtime either (normally).

Sure, my point was mainly about classic monolithic apps. If you split your app up into lots of separate micro-services, my point may no longer hold.

> Who says a SQL injection allows yourself to update your account to be admin.

I wasn't talking about a database superuser account, I was talking about an application-level admin. Usually there is some database table which stores user permissions, and an attacker can do an UPDATE/INSERT on that table to grant an ordinary user account full admin permissions, or even create a brand new user with those permissions. All this can happen within the single ordinary DB account used by the application (given most applications only use one DB account)

If the auth is a service accessing only via some remote access protocol that only allows a minimum number of operations that do not map directly into database commands they cannot exploit RCE in the app to get auth database.

Such service can also enforce reasonable rate limits and quotas, something that a regular direct database access can't enforce.

You are going to have a much harder time getting data from a service that only speaks HTTPs with 6 endpoints that can only be fed 1 type of JSON with only specific fields present per end point rate limited to rates per second that make sense for those individual end points with a database backing it being internal to that service which gets 15 deploys per year than from a Gigantic Database Supporting Application That Does Everything For Users and Business and Marketing and Analytics that keeps changing based on weekly sprints.

But then just giving the default user admin rights can make many (not so good but widely used) deployment tools and methodologies and similar much easier to use so you see it quite often.

I have seen it a few times. Default db user being a db admin because the ad-hoc written deployment script during initial development was never updated and security didn't matter back during per-release bootstrapping. ;=(

You have to distinguish application admin rights from DB admin rights. Most apps run with an ordinary DB user account, and even with a SQL injection bug in the app, you'd need to find an additional database vulnerability to upgrade the ordinary DB user account to a DB admin account.

However, for most apps, what is really valuable is the data, not the database, and for the data you don't need the DB admin account. The app's own users are often stored in a database table, with some flag (or something more complex like a separate group membership table) used to give an app user admin rights in the application. The point is, those admin rights can potentially unlock maintenance-focused features which could be used to extract the password pepper from the configuration. (Of course, as other commenters have pointed out, this is much harder in a microservices architecture with a user authentication service than in a classic monolithic app.) Giving a user admin access via SQL injection can also have other benefits – while data theft can be done via a SQL injection vulnerability, it can be cumbersome; using REST APIs, file export screens, etc, can potentially make data theft quicker and easier. The cost is increased risk of discovery, since auditing of admin rights may discover some unexpected new user granted admin rights, or some existing user having them unexpectedly – by contrast, data theft via a pure SQL injection with no data changes made would not be detected by an access audit.

Most encryption algorithms are deterministic, and most password authentication schemes depend on that fact.

Nevertheless, most encryption algorithms are deterministic. :)

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).

Never stored, hopefully, but the website has a chance of seeing it everytime one signs in. A malevolent site or developer or admin could store the password somewhere or try to reuse it on a number of other well known sites. Hence, one different password per site to protect also against the sites themselves.

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.

I think other schemes that did a lot less had plenty of time to displace passwords if they were going to. And they didn't.

So, implement WebAuthn and have done with it.

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.

https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

This approach is sometimes called a "Deterministic password manager" and that might be the phrase you wanted.

There are several problems with this approach, especially with regard to the need to sometimes change passwords.

But the point your parent was making is that in the modern era (certainly this century) none of this was necessary, there are asymmetric PAKEs which render it unnecessary for a site to know your password at all in order to confirm that you still know what it is.

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

[1] Napkin math: Single Titan RTX does some 65GH/s of MD5, so if you have 80bit password it would take in the order of 2^80/65e9 seconds = 500e3 gpu-years to crack

grind up a cow. store the ground beef somewhere

when a user wants to login, grind up the new cow in an identical manner.

compare the new ground beef with the stored ground beef.

if match (the new cow is a clone of the old cow), authenticate

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.

Unlike a pepper it is possible to change the encryption key if it is leaked. I don't think changing a pepper for existing hashes is possible, but if they are encrypted you can just reencrypt them with the new key.

So is there an obvious downside I'm not seeing to hash with a salt and then encrypt?

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.

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.

Maybe the real question is why use a pepper over encryption?

They have the same downside (as you mentioned) but at least you can change the encryption key without having all the users change passwords. I don't see any advantage in using a pepper over encryption, except maybe implementation complexity.

Like any disaster preparedness situation, make sure your strategy doesn't count on an asset you've already listed as unavailable.

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.

If your email is compromised, the attacker can request a password reset, then log in that way.

Why isn’t it common to use “login emails” with a one time token login buttons in the email?

The only downside I see is that it is harder to log in on a machine where you do not want to access your emails; for example like this:

On the machine with no email access the site would have to show a qr code, and a phone where you are already logged in would have to scan it, to approve the login.

Is this any less secure, or is it just not feasible for average users to understand?

What am I missing?

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.

What I dont get is how having smaller attack surface for losing a password, and using a secure password manager mitigates the attack vector of getting access to my account with a password reset through my compromised email.

If I understand correctly you say that email is more vulnerable, so this only strenghtens my point I guess?

1. Extra security checks. For example, if you buy a new laptop and use a coffee shop's wifi try to reset your bank password, they will lock your account. You will have to call and talk to a person and give extra personal information to get it unlocked.

2. Notify the user about the password reset. Use email, text, phone call, and postal mail.

3. Automatically lock the account if suspicious activity occurs in a time period after password reset. Examples:

  - Orders over $100 shipped to new addresses.

  - Risky transactions: buying gift cards, buying plane tickets in foreign countries, changing the delivery address of a shipment.

  - Using a known device (with cookies/fingerprint) and the old password.

5. Preserve user data so it can be restored to the state before the password reset.

These mitigations work well enough for protecting accounts from fraudulent password resets.

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.

If you can log in with a password, you have 1 way to get hacked (lose the pw).

If you can also log in through a pass reset, then you have 2 ways to get hacked.

MFA helps, but if I remember correctly Troy shared disappointing statistics about it’s usage by the general public.

The distinction between encryption and hashing can never get too much education, both for the end users and the more technical developers/sysadmins.

This is correct, but I am going out on a limb and guessing that legal counsel had something to do with the wording here (which is perplexing because I tend to expect legal definitions of terms to be more specific).

I was at an organization that also had a data breach, and legal counsel advised us to write a similar email when disclosing publicly that the breach occurred. I was personally on multiple phone calls with legal counsel about this, and it was quite frustrating to try and explain the difference between encryption and hashing, or stay on point with the fact that our passwords were not encrypted, trying to get people to stop using that word on phone calls. Early on, they'd ask questions like, "But aren't your passwords encrypted?!" And you'd have to explain, no, they're not, they're hashed, which is most likely better than encrypted (although I'm open to being proven wrong on that).

They were, also, mostly useless on explaining what their perspective of encryption was. I never got an explanation from counsel, and at best, I was linked to a blog post that suggested some security best practices (not a legal definition of anything we were liable for).

The sad thing is, with a data breach like that, you probably do (and should) feel terrible for your customers, anyone who trusted you with their emails, passwords, etc. But the laws surrounding it are confusing enough to make it easy for some people to push this out of their mind and just focus on, "What is the best thing we can do to legally cover our asses?" Even if that means saying factually incorrect or misleading things like, "Your passwords were encrypted."

A password hash is a representation of your password that can't be reversed, but the original password may still be determined if someone hashes it again and gets the same result.

Compare to:

A hash is like a fingerprint of your password. Your fingerprint tells me very little about you. You might be a man or a woman, tall or short, young or old. But if you show up, I can tell that you still have the same fingerprint. Likewise a hash doesn't tell me your password, but if my computer keeps guessing them, it can know when it is right. And my computer guesses really, really fast.

For the record I just asked my teenage son who doesn't know what a hash is whether he understood either explanation. He understood mine, but not Troy's. And he's a smart kid. If he doesn't understand an explanation, I'm pretty sure most adults won't either.

> > but if my computer keeps guessing them, it can know when it is right. And my computer guesses really, really fast.