High Alert should not be validating username

[grayedfox]

Hi there.

So aside from the annoyingly alarming "high alert" that made me choose a password that is technically, literally, and mathematically less secure than the previous password I was using (see: https://xkcd.com/936/) – it took me some time realise it was also validating the user ID, which makes barely any sense at all.



So for the fun of it I replaced my secure 20 character long randomly generated hex key I generated using a trusted, secure framework (ruby -rsecurerandom -e 'puts SecureRandom.hex(20)'.upcase) with something entirely guessable and obvious: CompanyName_3CX.

Please stop validating the ID field against the ill informed validator you are using (it's bad enough that the password need only be 10 characters long).

 

[YiannisH_3CX]

Hello @grayedfox

There are minimum requirements set in the PBX as guidelines to what a secure Auth ID and password should look like. If you add an obvious and guessable password then this is up to you. The PBX has a mechanism to generate a secure random alphanumeric password which you can use.
Also if you hover over the exclamation mark the management console will let you know which field you need to look at. For further clarifications regarding security matters you can always contact us at [email protected]

 

[grayedfox]

Hello @YiannisH_3CX - thanks for the reply.

Perhaps you missed the part in my post where I pointed out that the 3CX validator is flawed?

The original Auth ID was way more secure - it was a random and securely generated 20 character long hex key.

The validator complained because it didn't like that there were no special characters in the hex key, and then I got past the validator by setting a rather obvious Auth ID (just to test), hence why I made this post.

Given that the length of a string has a direct relation to the bits of entropy of said string, I think the validator should either be removed entirely (for the username) or have an added condition, which I will demonstrate now using psuedo code:

IF (authId.length >= 20 OR authId.passesOldValidationRules) THEN password is secure.

It's not a good outcome that a user can dismiss a "high alert" by setting a less secure password.