TFW looking at the regex for the password validation is easier than trying to decipher wtf they want

Who uses a regular expression for password validation?

How?!

Why?!!

@Oktokolo coz... Why not?

@Oktokolo What's the problem? The password must have at least so many characters, thereof so many letters with upper / lower case, numbers, special characters.

@Oktokolo I don't wanna name anyone specifically, but it begins with "ko" and ends with "nami"

For client side validation to reduce the requests to the serverside is not an bad idea.

Also you can give live feedback until it matches although than you would likely split it up a bit.

@stop an easy length test should suffice.

Sure, it would be possible to use a regex, but there are easier ways that are easier to maintain and a password is so short and if client side the regex will must cases be used once per session.

Actually compiling the regex probably takes more time than a more readable code.

@Fast-Nop

That exactly is the problem.

Require a minimum entropy (which basically boils down to a minimum length depending on count of different contained characters) if you really have to (but i doubt, that the common games account - Konami in this case - actually needs any password quality enforcement at all).

People have password generation schemes of their own which they like to use for everything so they can easily remember the passwords that actually do matter and are needed while the password manager isn't accessible (database password, main logins at home and work, banking, nuclear missle launch codes and silo access...).

Having to adjust the password generator for that stupid site enforcing a password policy from the nineties is annoying.

Stop it. It doesn't actually make anything more secure and people who don't use a password manager will still enter crap like "sdf1!asdsa" or "Stup1dPa$sword".

@Oktokolo Necessary vs. sufficient. Obviously, it's also good to have a dictionary pretty much like attackers are using, but using a regex to rule out what already fails at the necessary steps is a good idea because it's quick to do.

And no, "just a gaming site" is no argument. If the data are so unimportant, the correct solution would be to drop the requirement for a registered account in the first place.

@Fast-Nop

The requirement for registration mostly is to have data for advertisers, email campaigns or to be able to show stakeholders a big number.

And i am not suggesting doing more sophisticated tests - but less. Just check for non-emptyness and allow some ridiculous maximum like 300 (makes the aluminium hat people happy).

The user's password is not to be stored or judged. It is the responsibility of the user to choose.

If you have idiots as users, just have the site offer to generate a password for them.

@Oktokolo That's wrong. Captured accounts lead to GDPR accountabilities, which costs time and money, and users reclaiming their accounts also costs time and money.

There is no, absolutely no reason for a weak password.

@Oktokolo Yes. No. Maybe.

The thing is: Not all characters are good TM.

As one example, allowing the full Unicode range of characters could bring a whole lot of funny insanity on the table.

Hence it makes sense to restrict to ASCII only - as Unicode bugs / difference in standards / interpretation etc. might lead to a multidimensional clusterfuck.

Now the nice thing is you can express that in RegEx explicitly.

You can even set a minimum of characters, allowing unlimited characters.

Though I'd disrecommend this - funnily enough - for security reasons.

Several web frameworks had severe security holes as an unlimited or too complex password hashing led to an denial of service.

The simple attack vector was to just use an extremely long string as password for the login and basically taking the system down as the system was too busy generating the hashes for pw validation.

So we need an upper limit - as you said, though I would stay under 64 signs.

In a RegEx - easily doable.

What most add to the RegEx using the power of lookaheads is ensuring the password consists of a mixture of chars / numbers / special chars, though that's debatable imho.

Yet the power is there. I wouldn't allow a password to consist of 64 times the same char - so makes sense, although I wouldn't do what most people do and try to enforce a certain number of characters, just checking that no uniqueness of a single character exists.

The thing is: You can do all this one RegEx.

Or you fiddle with char buffers / taking a string apart character by character which is the worst in my opinion. But no password validation at all?

Ouch. That will be a security hole. (On the server side especially, I don't give a rats ass about the customer)

Well, there where plenty of hash database leaks in the past - all of them had shittons of pretty weak passwords no matter the password creation rules.

If your users are stupid, offer to generate passwords for them - their browser will act as a password manager and when they switch browsers, they will click on "forgot password" and get a new one.

But if you really fear the GDPR so much, add an entropy test. Simplest formula: count of different characters in password ^ length of password

You get better scores for bigger alphabet sizes and/or longer passwords.

If you test the entropy, you can always plausibly argue that you did way more than most of the industry to avoid any harm to your users. So it ticks the compliance checkbox while not annoying password manager users.

@IntrusionCM

I am strongly against using non-regular grammar (look-aheads) in what basically is a user-faced regex.

But yes, failing for non-text code points is definitely the right thing to do for any user input, not just passwords. Same goes for applying a normal form (preferably C) and checking grapheme clusters to not exceed a reasonable length (30 should be way more than any real language actually needs).

But if some want to have a series of different cat emojies or Hieroglyphes as password, i would argue that to probably be a way more secure password than almost anything i ever saw in the wild... So just let them!

@Oktokolo not entirely sure what you mean by non regular grammar

The problem with Unicode / emojis is the support - Unicode bugs are common and they can occur in the weirdest ways.

Eg. Difference in UCS versions between language / interpreter and database could alone be an nightmare

@IntrusionCM

Non-regular means, that the regex doesn't implement a regular grammar (sorry, for being a bad teacher, but teaching in general and language theory in particular is not something i am good at):

https://en.wikipedia.org/wiki/...

TLDR: Regular expression syntaxes of today are full of non-regular extensions with which you can shoot yourself in the foot when malicious input is a possibility. Better keep your regexps regular and in addition avoid excessive backtracking potential.

Actual Unicode bugs btw are pretty rare beasts. The standard is absurdly stable. Canonicalization and Grapheme cluster separation are almost trivial algorithms and implemented in well-tested libraries. It is rendering libraries, where all the esotheric edge cases are - and that also is, where all the so-called "Unicode bugs" proliferate.

You aren't rendering passwords. You just do most basic checks and Unicode Canonicalization on them - to then treat them as blobs for hashing.