Storing weakness level of passwords

Question

I am implementing a system where I need to store passwords in a database (hashed and all). My issue is that the business side requires me to not enforce any constraint on them except length (8 characters minimum), but highly advise to use special characters, uppercase characters or not use your first name. Not following these advises would have liability implications on our side. For example, we would allow a client to use 12345678 as a password, but would not be liable if it gets brute forced. This would require me to have an integer in my database that remembers this for the original password (pre-hashing). Any big no-no in doing this ?

EDIT: Just to clarify, the integer would most-likely be a flag that represent the type of weakness, ie: too simple, commonly known weak password, uses personal information, etc..

EDIT 2: Current solution based on the multiple answers and comments below would be to store an integer with flags that have been bit shifted. This integer would be stored in a separate database and encrypted using public-key cryptography, most likely using ECC.

EDIT 3: This is only viable assuming basic security at lower levels (OS and network) as well as spam prevention. The system would block further attempts for sometimes after multiple failed attempts, password are securely hashed using both a (at least) 128 bits salt and time/memory consuming algorithm (Argon2id in this case).

Final Edit: I have set @steffen-ullrich response as accepted. Lots of very good answers and I appreciate all the reason why I shouldn't do this but I wanted answers on what could go wrong and how one would go about doing it this way (many responses helped form the last edit). The legal aspect was provided to focus on the technical standpoint in light of a requirement I have no control over. My second edit basically describe what implementation would be a 0 compromise way of doing this. Disclaimer: this is pure curiosity and I have no plans to actually deploy this in production for the time being, I would recommend reading comments and chat threads before attempting this as they describe much of the problems and limitations of an approach like this.

Answer 1

Password hashing (with salting and slowness) is designed to make it indistinguishable from just having the hash if a password is weak or strong. Adding an additional indicator about the quality of the password allows an attacker to focus on the weak passwords and therefore significantly decreases the costs for an attacker.

Answer 2

I am implementing a system where I need to store passwords in a database (hashed and all). My issue is that the business side requires me to not enforce any constraint on them except length (8 characters minimum)

Translation: how to solve a problem that should not exist.

Not following these advises would have liability implications on our side. For example, we would allow a client to use 12345678 as a password, but would not be liable if it gets brute forced.

Well, even if your problem is purely a compliance issue, there are still some unresolved issues here. In a modern system, you are not supposed to store passwords in clear, but hash them. So you cannot really prove that the customer provided a weak password, since the original password is not known to you. What you are proposing is to store an "indicator of weakness" but it is somewhat subjective. It does not really tell how bad the password is. And what's the point really?

Even on a system that is enforcing strong passwords, you should still thwart brute force attempts. Example: ban the offending IP address for 15 minutes after 5 failed tries, something like that.

In case of a breach, and even if you can demonstrate it was caused by a weak password, shifting the blame onto the customer is not going to be well received.

If things go wrong, and litigation ensues as a result of a breach, you may have to demonstrate you undertook every reasonable effort to keep your systems secure and also protect the customers against themselves. Your password policy fails the test. It is below acceptable standards in 2022. There should be enough online resources you can use to convince the business analysts this is a terrible idea.

If I were in your shoes, I would downright refuse to program that thing or demand a liability waiver.

Remember: if when things go wrong, they will have to blame someone, and the someone could very well be you ("the programmer didn't advise us against the flawed requirements"). It's potentially your job and reputation on the line.

Answer 3

So I'm going to tell you how to actually do this with no security compromise.

• Generate a public-private key pair for encryption. Use of RSA is advised.
• Only give the application the public keypair
• When given a new password, generate 112 bits of noise, prepend that onto your 32 bits of password weakness flags.
• Encrypt that with AES-128 using a one-time key generated directly; you only have one block and the key is used once so don't bother with IV.
• Encrypt the 128 bit key using the public key.
• Store the resulting encrypted key and data block in the database.

Store the private key offline somewhere; if you need to check if a password is weak, copy those two values and only those two values to your offline computer with the private key and read back the bits and determine the weaknesses.

Answer 4

TL;DR

One of the possible ways to manage risk is to transfer it to a third party. This whole scheme is intended to transfer risk to system users instead of system owners, but introducing a non-standard system with increased inherent risk is likely to have the exact opposite effect. Instead, it is more likely that it will increase both inherent and residual risk without legally or effectively transferring any of that increased risk to a third party.

Why No Reputable Framework Recommends This Approach

There are a lot of anti-patterns to doing this. They include, but are not limited to:

1. The naive approach to this would require parsing and hashing/encrypting the password server-side, which has its own set of problems when compared to client-side processing.
2. Being unable to hash and/or salt the password on the client side, unless you deconstruct the password client-side and pass additional information about the password's composition or format as metadata.
3. As a result of the items above, you can't have a zero-knowledge password system since some elements of the password must be known and stored/computed server-side even if the password is hashed or encrypted client-side.
4. This whole system creates opportunities for side-channel attacks, creates trails of metadata, and identifies low-complexity passwords for brute-forcing opportunities.
5. It fundamentally solves the wrong problem by trying to shift risk to the system user rather than the owner of the system. This shift is unlikely to be auditable (and therefore largely unenforceable) unless you essentially break the security of the system even further than what you've already described.
6. Unless your legal department, auditors, cyber-insurance carrier, and infosec department have all agreed that this makes any sort of business sense, I'd personally put it on par with creating risk in the same way that people who roll their own encryption because they think they can do better than the entire field of peer-reviewed cryptography.
7. You can't point to a single peer-reviewed standard or widely-accepted security framework that would support this type of password policy.

This list is by no means exhaustive. It's just illustrative of various ways that this approach should be a non-starter.

Accurately Measure Your Business Risk

In other words, you're doing the wrong thing because someone has presumably decided it mitigates some aspect of business risk. Rather than doing that without doing the proper research, and then asking strangers on the Internet for reasons to do it or not, your organization needs to conduct a formal risk analysis to determine if it will measurably reduce your business risk in the first place. The company needs to think about the OKRs and controls involved and how they might apply to the business case.

Assuming that this approach would somehow measurably reduce risk, which is a dubious assumption at best, how do you plan to measure whether the residual risk of this control will be below your organization's risk appetite? How will you ensure that those residual risks (including less tangible risks like reputational harm to the organization) can legally or effectively be transferred to a third party?

The first part of this is really a leadership question, not a technical one. The second part is really a legal question, and can't be answered without the advice of legal counsel or input from the board of directors and/or senior leadership.

The triple-net is this whole thing sounds like you're way out on a limb and sawing vigorously, but your mileage may vary.

See Also

• Security and Privacy Controls for Information Systems and Organizations. NIST SP 800-53 Rev. 5, IA-5(1), pp. 139.
• "Changes in Password Best Practices". Schneier, Bruce. October 10, 2017
• Digital Identity Guidelines Authentication and Lifecycle Management. NIST Special Publication 800-63B, Appendix A, pp. 67-69.
  • NB: Offline attacks and database breaches likely relevant to your use case are discussed in A.2 on pp. 67-68.
  • A.5 contains only a single four-sentence paragraph that address your implied threat model a lot better than a custom scheme. It could be used as a starting point to inform a risk-appropriate password policy when combined with widely-accepted controls.

Answer 5

If you really wanted to do this, you could have extra columns in your database.

Password_Hash: CHAR(40)
Uses_Uppercase: Bool
Uses_Lowercase: Bool
Uses_Numbers: Bool
Uses_Symbols: Bool
Uses_More_Than_8_Chars: Bool

But, as others have pointed out - this does create some risk. If an attacker gets access to your database table, they can select all the passwords where Uses_More_Than_8_Chars is False and spend their effort brute forcing them.

Or they can perform dictionary attacks only on lowercase passwords with no numbers and symbols.

A better way might be to alert the user that their password is weak, and ask if they accept liability. If so, store a column on the User table Accepts_Weak_Password_Liability: Bool.

But, again, that's a signal for an attacker.

And, in any case, it doesn't help if the user has a complex password which they use everywhere. Or if they have it on a post-it. Or if they accidentally paste it somewhere.

Answer 6

Slight frame challenge. Consider using something like the haveibeenpwned api to check the passwords when they are set or changed. Present a message to the user indicating that they are using a known compromised password, and allow an override if you must (something like typing the sentence "I agree to have my account compromised."). Store hashed passwords for the user for at least one password change (this is your proof after an attacker changes the password that the user was using a weak password).

Do NOT store a weak password indicator, but instead use the previously hashed password to indicate weakness if needed with a simple brute-force attack against the password if needed, with a timed attack using standard word-lists or attack methods. Or, if you must (and I would STRONGLY advise against it for all the reasons provided above and in the comments), store a simple flag indicating the user has bypassed the "pwned password" warning in a separate database/machine, etc. If you MUST go that route, don't label the flag clearly as "idiot user" or "weak password" or anything like that - maybe just a label like "flag1". That flag should NEVER be cleared, if it is ever set, as it indicates the user has AT SOME TIME bypassed the warning, not that their current password is the weak one.

Answer 7

NO. You should not allow weak passwords, nor should you keep a record of a strength arbitrarily allocated to the ultimate password. This becomes problematic for stakeholders that insist on informational level audit trails.

The problem is twofold. Firstly you are conceding that there is a foreseeable risk. Secondly, you are identifying customers with weaker passwords.

You especially should not keep a dictionary with hashes of disallowed passwords, you may have users grandfathered-in. Joining these keys would be trivial. It matters not that you lock their accounts on your system. It may be in use elsewhere. It is however a valid intrusion attempt detection method to test for known "scripted" passwords, just do not hash them, or use some other way.

Answer 8

Not a good idea. In a similar fashion, the police could attach written notes to all the house doors in a given neighbourhood, and have that notes state how breach-resistant the door is. The authorities will have a policy that people are allowed to have thin plywood doors, but the authorities are not responsible if burglars break into such houses.

In short, you are trying to use programmatic solution to solve a problem that is actually caused by human factor (certain fraction of users tend to use weak passwords). Potential rubber-hose analysis is also a thing to have in mind. Forcing password requirements to ensure sufficient strength is not a clean solution, and it is frustrating for users, but it does a good enough job at protecting you from liability; let's use it until we invent something better.

Answer 9

While you mustn't store complexity notes (since they can be used to target weaker passwords for cracking), you can certainly tell the user that their password is weak when they create it. Scare them with your policy and how you're doing your due diligence in telling them that it's weak and how a breach given this notice places the blame on them.

I think we've reached the point at which passwords should always be generated and managed by a password manager. This means there is never any reason to use a password shorter than 20 fully random printable characters (~92²⁰ possibilities), at least for anything that can properly interface with a password manager (e.g. a website as opposed to your computer's login screen).

Answer 10

Actually, since your users don't need to know their "weakness" flags in order to login, there is absolutely no reason to store them in the same database as password hashes. You could store them in a separate data structure, probably even on a different server, and unlike hashes these flags can themselves be encrypted. In that case, they will not be "leaked" if your hash database is compromised.

I'm still not convinced you will ever use those flags in a legal dispute with a client, as they have no additional value. If a customer's account is compromised you can simply ask them what their password was, and if it was "1234567", you can attempt to shift the blame to them in court by claiming their "negligence" or something, with or without your "weakness" flag.

Answer 11

It is impossible to reliable know that a password is not weak. Your algorithms can detect some weak passwords but you can't detect every weak password. Some examples, all of this passwords are weak, would your software detect them as weak?

n]j{No(i,mA$XI.dQNZY
Passw0rd!Passw0rd!Passw0rd!Passw0rd!
MyPasswordThatIAlsoUseInOtherServices12!
bl3iavN74RlOlbXxnW+d9+CGKOSWaeimquy26/DHLPQ
588+9PF8OZmpTyxvYS6KiI5bECaHjk4ZOYsjvTjsIho
1qQ2wQ3eE4rR5tT6zZ7uU8iI9oO0pP
0+Q"W*EçR%T&Z/U(I)O=P
a!00!a00!!aaaa!!00!a!0a0

Just because they are long, have special characters, digits and lower and uppercase letters does not mean they aren't weak.

Since you can't know if a password is strong, there is no point of storing the weakness level.

Answer 12

Why don't you get them to input their email and have it do an authentication process so the system knows it's actually them. Then you don't need any password. Ex. Input your email. -Emails a code- -User enters in code- Allows access