Is Password Complexity Too Complex to Implement?

Enforcing complexity is one aspect of a good password policy. But web applications often implement this poorly.

Yesterday I had to change a password on a web application provided by an information security vendor. You'd think they'd have this sorted. It began promisingly:

• the page was only available on a page transmitted over secure HTTP
• the page was only available to currently authenticated users
• there was an explanation of the minimum password complexity requirements
• the form asked for the current password
• the form asked for a new password and provided a visual indicator of the password complexity (length and mix of characters)
• the new password wasn't allowed to be blank(!)
• confirmation of the new password was sought
• password fields were initially all blank and masked as you typed
• the submission was sent by the post method over secure HTTP
• the session was ended (forced log out) and the account locked after multiple failures to change the password correctly

Also, the form had some helpful client-side JavaScript validation—but did not rely this and, correctly, was also undertaken once submitted to the web server.

The client-side validation even included an indicator of password complexity. But I was surprised when my "great" new password was rejected apparently because it did not contain solely ASCII characters:

Well, I can assure you I did use ASCII characters. In this case the client-side and server-side validation are not identical. This suggests that there may be contradictory requirements in the specification or the validation has been implemented incorrectly, and there was inadequate testing and verification undertaken.

This is a usability error, and a potential security vulnerability.

A small issue, but it demonstrates how easy it is to have faults in applications. This may not have an impact on the application's security, but it would be an area a malicious user would explore further to see if the weakness could be exploited.