Having a site-wide definition seems like it would require a lot of mechanics to target specifc pages or properties that may have different rules (e.g. consumer Vs. corporate logins).

I still hope companies start following NIST guidelines and stop having password rules entirely.

Website wide obviously being over-ruled by local over-rides.

To save (potentially rate limited) requests, the ripper software could compare the regex against a candidate password and skip it altogether.

It's like expressing in machine-readable form how many/which characters they can skip.

If knowing the rules for acceptable passwords makes it significantly easier to brute force passwords, that sounds like more of an argument to not have those rules in the first place since it wouldn't take an attacker long to figure them out himself even if they aren't published. Hiding the password policy is a very weak form of security through obscurity.

I guess it would make it easier to programmatically determine which websites have insecure passoword policies (like an alphanumeric passsword no more than 8 characters long), but the problem here is the password policy, not publishing the rules.

Even the NIST recommends that sites stop requiring these arbitrary password rules as they don't actually improve password security: https://www.alvaka.net/new-password-guidelines-us-federal-go...

Maybe passwords should always just be auto-generated and people should be told to write them down in a... actually, nevermind that. Passwords should be a thing that's integrated in your browser/computer experience... this is something that can and should be handled by computers. You should only ever have to log into your computer and be secure from then on.

This whole insanity of point-to-point invention of secrets needs to die.

I had this crazy idea, whereby computers could themselves come up with very long, random sequences of bits.

They would then use these openers (couldn't think of a better word) to authenticate to each other, secured by mathematical operations, in place of passwords.

Sadly, I've never seen it used on websites, so it must not be a good idea. /s

However: The UX on the browser side is shitty as hell. Certificates display weird nagscreens, without being able to specify proper defaults like "use this cert for that site and don't bother me again". Certificate enrollment has been broken (not that the form element was ever great) by all major browsers, to be replaced by "do something in Javascript maybe, if we get around to implementing a new API some time". Oh, and no logout...

Kerberos needs a parameter at browser start or an about:config setting, is incompatible with using multiple TGTs let alone automatically selecting the right one or gasp getting a new TGT for the user from the proper KDC. The only thing that kinda works mostly is using the standard company login TGT. Oh, and logging out doesn't work...

Oh, and of course most mobile systems are broken or just unsupported.

The sorry state of browser auth is 100% on browser vendors dragging their feet on those problems that have been known for around 20 years or so. And no, webauth won't save us, it'll just be another shitshow most likely.

I always felt like one of the UX blockers for key exchange was the assumption that people couldn't be expected to learn the basics, because it's too complicated.

And every attempt to ignore or hide it has just made the entire thing more complicated or confusing.

You can shoot yourself in the foot with a gun or crash your car into a wall, and yet most people manage not to do so on a daily basis.

Sometimes simplicity is a false virtue.

Not in my experience. If I can choose anything I'll write a decent-length phrase. If I'm forced to use numbers and symbols I'll make the shortest thing I can.

Certainly there's no reason to reject a 20+ letter all-lowercase password. Apply your capital/number/symbol rules to passwords shorter than 16 characters if you must.

You are not a typical computer user. The typical computer user is Karen from accounting, and Bob from HR.

Plus, there's always the fact that an adversary can just, you know, go find the password requirements on the website and generate a matching regex themselves.

Of course, if the regex is something like `^password$`...

For a more complex regex, you could resort to a simplified version (eg, with larger search space). But the space of all random strings is way too huge to just generate random bitstrings and hope they match the regex.

In practice, this shouldn't make things easier for password crackers, because trying to crack a password by enumerating the password space is not a normal approach. (Except for rainbow tables.)

What you'd expect a password cracker to do is construct passwords according to a model of what kinds of passwords humans actually create (regardless of the formal password requirements), and guess those. You're not trying to make sure you've covered everything -- you're just trying to make high-probability guesses before you start making low-probability guesses.

Hopefully the Top-1000 page would include an intro why the list should be empty.

in any case, the only reasonable rules for passwords are probably a length requirement and possibly requiring numbers and/or symbols. knowing that a password must be at least 8 chars and include at least one number and a symbol does not reduce the search space by much.

It's a lot like telling someone the exact length of your password. Okay, by knowing that it's 11 characters they can skip testing 1-10... but that only lets them skip 2% of the calculations.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Web browsers are already running random expressions from the internet, but their regex implementations have proven the rule by being fodder from exploit writers. In any event, requiring a password manager to pull the engine from Firefox or Chrome wouldn't be cool. They're more likely to use libpcre or re2, but see above.

The NAPTR DNS record type uses regular expressions for domain rewriting: https://en.wikipedia.org/wiki/NAPTR_record Not many DNS libraries support that record type as it adds alot of problematic bloat.

Evaluation is linear, but you're just evaluating your own password. In this scenario, it may make sense to just use a simple backtracking implementation, though as you alluded to early there aren't many simple ones around.

I totally agree with your concerns about scope creep increasing the attack surface.

I disagree. Password "complexity" requirements need to die and instead every site's password regex should be `.{12,64}` and then verify it's not in the dictionary or a list of leaked passwords.