Those (?=...) bits are positive lookahead assertions:

Lookaround assertions are zero-width patterns which match a specific pattern without including it in $&. Positive assertions match when their subpattern matches, negative assertions match when their subpattern fails. Lookbehind matches text up to the current match position, lookahead matches text following the current match position.

The one (?!...) is a negative lookahead assertion.

The $& var doesn’t really matter outside of Perl. It contains the text of the pattern you just matched, but even within Perl, capture groups are preferred. Once used at all, it will slow down your program every time a new regex is hit, which is especially bad in long running web server environments. Gets used sometimes in short scripts, though.

What really matters is that the lookaheads don’t consume any text. In other words, the pointer that shows where in the text we are doesn’t increment; once we’re outside of the lookahead, we’re still right back in the same place.

So let’s break this down using the /x modifier to make it somewhat sane.

/^
(?!.*\s) # no whitespace allowed
(?=.{8,256}$) # between 8 and 256 characters (the '$' here indicating the end of the string)
(?=.*[a-z]) # has to be a lowercase ASCII alphabet char somewhere
(?=.*[A-Z]) # has to be an uppercase ASCII alphabet char somewhere
( # need a number, or a list of special chars on a US keyboard
    (?=.*[0-9]) 
    | (?=.*[~!@#$%^&*()-=_+[\]{}|;:,./<>?])
)
.* # consumes the whole string
$/x

Notes:

• Doesn’t make any allowances for non-English characters, or even non-US characters (like the “£” character in the UK)
• There’s a whole slew of utf8 characters out there that should count towards “special characters”, but aren’t considered here
• There’s no reason to deny whitespace; let people use passphrases if they want (but then, you also don’t want to block those people for not using symbols)
• Putting a limit at 256 is questionable, but may not necessarily be wrong

That last one has some nuance. We often say you shouldn’t put any upper limit, but that’s generally not true in the real world. You don’t want someone flooding an indefinite amount of data into any field, password or not. A large limit like this is defensible.

Also, lots of devs are surprised to learn that bcrypt and scrypt have a length limit of 72 bytes. A way around this is to run your input through SHA256 before giving it to bcrypt or scrypt.

password must be valid regex

I use a password manager with a random password generator. It’s always disconcerting when I find a website that finds my passwords to be too complicated. Like “you can’t use more than eight characters and the only special characters you can use are @ and !”. What the shit?!?

Explanation:

That is a the regex string for that sites password field. Regex is a sequence of characters used to see if an input matches a defined pattern to validate the input in code (theres also other uses but thats what being done here). Sites normally dont show the regex pattern since it is pain to parse even if you know how to write things in regex and to people who dont code this looks like a random output. Im assuming a bug exists that prints out the wrong error string so that this shows instead of the human readable one

When the developer just passes on the js error to the user 👍🏾

I know regex!

This means:

• Must not contain whitespace

• Must contain lowercase latin letter

• Must contain uppercase latin letter

• Must contain a number

• Must contain one of the symbols you’d normally be able to type on US keyboard !@#$%^&*()-=_+[\]{}|;:,./<>?

It is a cursed way to do validation, though.

Reminds me of The Password Game…

Warning: you have been warned!

Kind of related question: why are no whitespaces allowed in many passwords while special characters are? I’m a huge fan of elaborate nonsense sentence passphrases but get shot down.

(I ask cause that regex has that requirement it seems)

Jesus, what a terrible regex. I love regexes and use them frequently, but you could just, y’know, declare your requirements and then check they’re being met using string methods. Min length 8, max length 256, one set/dict/map for each character class, the minimum count for each character class, and then loop over the string and check that your declared requirements are being met. A regex might be faster (if the regex engine isn’t being asked to do crazy lookup shit), but why torture yourself? Just parsing the string is also nice because it’s readable and makes frontend documentation easier to generate.

Or skip all of this shit and just require longer passwords. My company has mandated 16 character passwords with no character class requirements for years and it’s great. Want to use a password manager? You’re set. You a big fan of passphrases? correct_horse_battery_staple your way through that shit. A long password + 2FA is all you need for security.

edit: also fuck you apparently if you want to have a ñ or ü or (⁠･⁠o⁠･⁠;⁠) in your password. I’m guessing the database column for this only supports ASCII? Smells like smelly MySQL/mariaDB to me.

edit: well, Unicode might be allowed. I get turned around with all of the groups and references. I guess it also depends on how the regex is being compiled. I know that in Python you can pass a bitwise flag to re.compile to force ASCII.

“Oh fuck it, it’s already 4 PM on Friday.”

copy-pastes the text provided

well clearly your password does not match that

Stand back, boys… cracks knuckles I’ve played Fallout 3 & 4!

Fuck this website.

I should add this as a default option in my “reverse”-regex text generator library. It’d be neat to have a cli tool for generating random passwords.

(Please respond with your favorite bash/python/powershell one liner for doing this.)