A standard for describing a site’s password rules

There’s not a universal standard for what a valid password on a website must look like. Some sites allow you to use any four letters. Others require at least twenty characters, including at least one numeric digit and one “special character” (aka punctuation). Even when using a password manager, the process of creating a good one looks a lot like:

  • Turn the password manager’s strength settings all the way up and generate a password.
  • The website replies “passwords can’t be more than 20 characters long”.
  • Adjust the length down to twenty. Generate a new one and send it to the website.
  • The website replies “passwords may only contain the special characters ‘$_!#’.
  • Adjust the number of symbols down to zero. Generate. Try again.
  • The website replies “passwords must contain at least two special characters”.
  • Turn the number of symbols back up to two. Click “generate” until you a password that contains punctuation from “$”, “_”, “!”, and “#”, but nothing else. Generate. Try again.
  • …and repeat until you’ve appeased the website’s rules.

I propose instead that websites should document their password rules in a standardized, machine-readable manner. For instance, suppose that each site hosted a file in a pre-defined location, like /.well-known/password-rules.yaml, in a format such as:

max_length: 64
min_length: 8
allowed_symbols: "$#@!"
min_symbols: 1
min_upper: 1
min_lower: 1
min_digits: 1
matches: "^[a-z]+(.*)+$"

Then tools like 1Password could look for that file and tune their settings to suit. The new process for creating a password would look like:

  • Tell 1Password to generate a password for the site you’re currently looking at.
  • It fetches the rules file, interprets it, creates a password that satisfies all the requirements, and pastes it in the password field on the site.

Further suppose that the standard defined the calling conventions of a REST endpoint for changing passwords, and the rules file included that URL like:

change_url: /ajax/change_my_password

Wouldn’t it be just lovely if 1Password could automatically update every such website on a monthly basis, or whenever a site announces a security breach?

On Generated Versus Random Passwords

I was reading a story about a hacked password database and saw this comment where the poster wanted to make a little program to generate non-random passwords for every site he visits:

I was thinking of something simpler such as “echo MyPassword69! slashdot.org|md5sum” and then
“aaa53a64cbb02f01d79e6aa05f0027ba” using that as my password since many sites will take 32-character long passwords or they
will truncate for you. More generalized than PasswordMaker and easier to access but no alpha-num+symbol translation and only
(32) 0-9af characters but that should be random enough, or you can do sha1sum instead for a little longer hash string.

I posted a reply but I wanted to repeat it here for the sake of my friends who don’t read Slashdot. If you’ve ever cooked up your own scheme for coming up with passwords or if you’ve used the PasswordMaker system (or ones like it), you need to read this:

DO NOT DO THIS. I don’t mean this disrespectfully, but you don’t know what you’re doing. That’s OK! People not named “Bruce” generally suck at secure algorithms. Crypto is hard and has unexpected implications until you’re much more knowledgeable on the subject than you (or I) currently are. For example, suppose that hypothetical site helpfully truncates your password to 8 chars. By storing only 8 hex digits, you’ve reduced your password’s keyspace to just 32 bits. If you used an algorithm with base64 encoding instead, you’d get the same complexity in only 5.3 chars.

Despite what you claim, you’re really much better off using a secure storage app that creates truly random passwords for you and stores them in a securely encrypted file. In another post here I mention that I use 1Password, but really any reputable app will get you the same protections. Your algorithm is a “security by obscurity” system; if someone knows your algorithm, gaining your master password gives them full access to every account you have. Contrast with a password locker where you can change your master password before the attacker gets access to the secret store (which they may never be able to do if you’ve kept it secure!), and in the worst case scenario provides you with a list of accounts you need to change.

I haven’t used PasswordMaker but I’d apply the same criticisms to them. If an attacker knows that you use PasswordMaker, they can narrow down the search space based on the very few things you can vary:

  • URL (the attacker will have this)
  • character set (dropdown gives you 6 choices)
  • which of nine hash algorithms was used (actually 13 – the FAQ is outdated)
  • modifier (algorithmically, part of your password)
  • username (attacker will have this or can likely guess it easily)
  • password length (let’s say, likely to be between 8 and 20 chars, so 13 options)
  • password prefix (stupid idea that reduces your password’s complexity)
  • password suffix (stupid idea that reduces your password’s complexity)
  • which of nine l33t-speak levels was used
  • when l33t-speak was applied (total of 28 options: 9 levels each at three different “Use l33t” times, plus “not at all”)

My comments about the modifier being part of your password? Basically you’re concatenating those strings together to create a longer password in some manner. There’s not really a difference, and that’s assuming you actually use the modifier.

So, back to our attack scenario where a hacker has your master password, username, and a URL they want to visit: disregarding the prefix and suffix options, they have 6 * 13 * 13 * 28 = 28,392 possible output passwords to test. That should keep them busy for at least a minute or two. And once they’ve guessed your combination, they can probably use the same settings on every other website you visit. Oh, and when you’ve found out that your password is compromised? Hope you remember every website you’ve ever used PasswordMaker on!

Finally, if you’ve ever used the online version of PasswordMaker, even once, then you have to assume that your password is compromised. If their site has ever been compromised – and it’s hosted on a content delivery network with a lot of other websites – the attacker could easily have placed a script on the page to submit everything you type into the password generation form to a server in a distant country. Security demands that you have to assume this has happened.

Seriously, please don’t do this stuff. I’d much rather see you using pwgen to create truly random passwords and then using something like GnuPG to store them all in a strongly-encrypted file.

The summary version is this: use a password manager like 1Password to use a different hard-to-guess password on every website you visit. Don’t use some invented system to come up with passwords on your own because there’s a very poor chance that we mere mortals will get it right.