[ibly31]

Wouldn't this just make password crackers easier? If there's a Regex of what passwords are okay, it lowers the search space.

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.

[Johnny555]

Wouldn't this just make password crackers easier? If there's a Regex of what passwords are okay, it lowers the search space.

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

[Quekid5]

You're probably right theoretically, but people tend to choose really weak password if they can choose anything.

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.

[ethbro]

> Passwords should be a thing that's integrated in your browser/computer experience... this is something that can and should be handled by computers.

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

[HorstG]

Certificate auth for http with TLS and Kerberos auth for http is specified, supported by all (major desktop) browsers.

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.

[ethbro]

This is the reply I was honestly hoping to get.

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.

[Quekid5]

I mean... it's probably beyond the imagination of man since it clearly hasn't been invented at this point.

[squiggleblaz]

I guess that's the argument for diversity in tech.

[ethbro]

... Dinosaur eats man. Woman inherits cryptography.

[lmm]

> You're probably right theoretically, but people tend to choose really weak password if they can choose anything.

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.

[Quekid5]

This is a really old-timey snipe, but...

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

[hwbehrens]

I would say in general, no. For a long time, American Express had something along the lines of `^[A-z0-9]{6,8}$`. Given a candidate string, evaluating even this extremely basic regex will take more time than comparing it against a hash table. I suppose you could flip it around and use it as a generator for an arbitrary dictionary, but then you'll run into memory limitations first.

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$`...

[Beldin]

If you have the regex, you'd use it to generate candidate strings. Then, of course you don't have to check any more.

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.

[thaumasiotes]

> Wouldn't this just make password crackers easier? If there's a Regex of what passwords are okay, it lowers the search space.

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.

[sowbug]

This isn't such a bad thing. If this standard were ubiquitous, Troy Hunt could maintain a top-1000 list of easiest-to-brute-force websites according to their password-requirement declarations. One might present one's own top ranking to one's CTO to help start a conversation about eliminating voodoo security practices.

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

[leetcrew]

for most public websites, you can reverse engineer the rules pretty easily by trying to create accounts. this can be automated pretty easily.

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.

[Dylan16807]

Any half competent brute force is going to do the simpler patterns first anyway. Knowing the exact set of special characters allowed won't make it significantly faster.

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.

[boatswain]

I don't really think that would save crackers must time compared with a signing up manually to find the password requirements.