account generation fails at password

[JollyOrc]

a friend has tried to set up an account and failed as the site claimed the password would not adhere to the restrictions and that the two passwords would not match, even though they copy-pasted it directly from the password manager and it certainly did adhere.

Additionally to solving this particular bug, we should amend the password screen a bit:

1. remove all restrictions aside of minimum length (NIST and BSI recommendation)
2. allow making the password visible to check what is typed in.

[promocare]

I have updated the account generation page with better validation errors and a visibility toggle for password fields.

[fhd]

Having a similar issue, I get the message:

The password must contain at least 1 uppercase and 1 lowecase character.

One of the passwords I tried when I got this message was: D!rb5c3etp. If I replace the ! with something else, I get:

The password must contain at least 1 special character (!,?,@,#,$,&,*).

Replacing the ! with a $ gave the previous error message about upper/lower case characters again.

I figured it might be the leading upper case character that's not recognised, so I flipped it around to: d!Rb5c3etp. This appears to do something, though currently it looks like it's just hanging after I press Continue.

Edit:

Had a look at the code, and I think the problem is this regular expression: /\w*[A-Z]\w*[a-z]\w*/ -> It will only match upper case characters when immediately followed by \w*[a-z] - i.e. no special special characters followed by at least one lower case character. This expression should fail to match various passwords that do comply with the specified rules.

A regex like this: /([A-Z].*[a-z])|([a-z].*[A-Z])/ should fix those issues, but there's probably a more elegant way to write this, and it still wouldn't take into account non-ASCII characters (although if that's fine, it's fine). I'd probably just do something like this for simplicity's sake though:

if (!/[a-z]/.test(this.password) || !/[A-Z]/.test(this.password)) {

I also smell a bit of a security issue here, seeing that the password rules are validated on the client side - unless the exact same code exists on the backend, of course, but I didn't investigate that one further.

The second password I tried earlier, did indeed work out, but it seems like the communication with the backend was hanging or taking quite long.

[promocare]

Hi @fhd thanks for telling us, I'll have a look at the regex