Buggy password validation check

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Buggy password validation check

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Buggy password validation check
Buggy password validation check
2024-07-22 23:27:42 - last edited 2024-07-23 01:11:42
Model: Archer VX1800v  
Hardware Version: V1
Firmware Version: 0.11.0, 0.12.0

I have just bought a new router, a VX1800v. While setting it up I encountered buggy behaviour with password validation when it insisted on setting a new password during initial setup. The admin change password form also seems to have the same problem.

 

I store my passwords in a password manager, and I let the password manager generate a new random password for logging into the router. The new password it generated contained a healthy mix of letters (both upper and lower case), numbers, and other common ASCII digits.

 

When I pasted this password into the TP-Link form, the password validation check for 'two types of characters' failed for no good reason. I experimented and found that it wasn't happy with the first character in the password, which happened to be non-alphanumeric. Further experiments showed that certain non-alphanumeric ASCII characters, when used as the first character, cause this 'two types of characters' check to unexpectedly fail.

 

If you enter any of the following, then the 'two types of characters' check passes as expected:

 

  • $a
  • %a
  • ^a
  • &a
  • *a
  • _a
  • @a
  • #a
  • ~a
  • ?a

 

However if you enter any of the following, then the 'two types of characters' check unexpectedly fails:

  • "a
  • £a
  • (a
  • )a
  • -a
  • =a
  • +a
  • {a
  • }a
  • [a
  • ]a
  • :a
  • ;a
  • 'a
  • ,a
  • .a
  • <a
  • >a
  • /a
  • \a
  • |a
  • `a
  • ¬a

 

Wierdly £a and ¬a also cause the validation checks to complain that it contains spaces.

 

I also conducted a few experiments using a couple of different characters from above in different positions:

  • =a@ fails
  • =@a fails
  • @a passes
  • @=a passes
  • a=@ passes
  • a@= passes

 

Those results prove that the validation check is happy for all of those characters to be in the password, but it's mishandling them somehow when certain ones are used for the first character of the password.

 

Most of this testing was done with the 'change password' for presented during initial setup.

 

The original firmware out of the box was: 0.11.0 2.0.0 v6092.0 Build 230830 Rel.39623n

I've updated to the latest firmware, which behaves the same: 0.12.0 2.0.0 v6092.0 Build 240329 Rel.14160n

  1      
  1      
#1
Options