Web sites with "hidden" password strength limits

semblance

Yesterday, I found my self battling against another web site which exhibits "hidden" password strength limits and contacting the web site owners to report the issue.

This is about the fifth or sixth time I've done this, so I now have an email template which I use - I thought I'd share it here in case anyone finds it useful.

Hi, I just registered with [WEB SITE], and following best practice, I used my password manager app to generate a 22-character long random password containing letters, numbers and special characters - for example Qx~1jQX6jV,o]>0V3v#U((.

The web site allowed me to set this as my new password, but then didn't allow me to log in with it - so I had to use the "forgot password" function and set progressively weaker passwords until I found one that would work. Eventually I ended up with a [LENGTH]-character password containing numbers and letters only.

If you are going to have a password policy which (for example) blocks passwords containing certain characters or over a certain length, then you really should enforce this at the point when a user sets their password. You should not accept the password when the user sets it, and then reject it when they try to log in with it.

Better still, the password policy should allow strong passwords in the first place i.e. allow longer passwords and special characters to work.

In summary - this is a bug in the web site which needs to be fixed.

Thanks

khad

I think I'll be saving that myself. Thanks, @semblance‌! Keep fighting the good fight. :)

hawkmoth

Rant on.

Let me chime in to add only that I don't think those web sites are, in fact, accepting the strong passwords. What I think they are actually doing is truncating them to the maximum allowable length without testing the length the user inputs. Then they accept and save the truncated password and fail to report back to the user that they did that. Internally, those sites have only recorded the shorter version, but then when you use 1Password to submit your credentials, the site fails to truncate in a similar manner, and your submission fails to match the site's internal record, because it never saved the correct password. You get fooled on both ends.

None of that probably matters in the letter you composed, but this whipsaw makes it doubly difficult to figure out what is actually happening.

Rant off.

semblance

Yes in some cases it could be that — but it can also be inconsistent input field validation. I've found several web sites that have prevented me from logging in with a particular password where I was able to fix the issue by removing some or all special characters and keeping it the same length.

Don't forget that these days, developers have it drummed in to them to "validate" all untrusted input — which typically means filtering out certain characters from any user-supplied strings, such as single and double quotes and backslashes (possibly used in SQL injection attacks) and angle brackets and ampersands (possibly used in cross-site scripting attacks), and rejecting input over certain lengths, as well as truncating. Any of this could be applied with different criteria on the log in form compared to the password set form.

To complicate things further, input field validation is often done repeatedly at different layers in the program (client-side, web tier) which are often written in different languages by different teams, and of course there are often multiple client types (web site, mobile app, desktop app), again all written in different languages by different teams. When you think about it, it's no wonder they fail to make their validation routines perfectly consistent!

Of course, it's perfectly possible to develop a secure application that fully accepts and works with passwords containing any printable ASCII characters. But when it comes to security, developers often err on the side of caution and decide it's better to block a few weird characters just in case — after all, it works for the 99% of users :-)

Where it gets even more interesting is that a lot of web sites (more than you might think) actually allow non-ASCII characters in their passwords. This isn't necessarily an issue, but they do of course need to block unprintable characters and use consistent character encoding in the different password forms and application tiers. I once worked on an application where the client allowed passwords containing non-ASCII Unicode characters encoded in UTF-8, but the server side thought they were encoded in ISO 8859-1 (Western European)... endless fun and confusion!!!

But Unicode passwords are another topic entirely :-D

Anyway as you say, for the purposes of raising an issue with the web site, none of this matters. The fact is they shouldn't let you set a password you can't log in with.

And ideally they shouldn't limit the password strength unduly — which encompasses both length and character range.

hawkmoth

While you're at it, we need relief from sites that refuse to accept pasted passwords. My long, strong passwords pasted in are much better that anything I'm willing to use if I have to type it in manually because a site won't let me paste it in. A few even won't honor the 1Password submission, even though it doesn't involve copy and paste.

khad

If it helps, you should be able to change passwords even without pasting.

1. Hold down the Option key while selecting your existing Login item from 1Password mini.

   Holding down the Option key will force 1Password to not automatically submit the form after it fills.

2. If applicable, delete anything filled in the "New password" and "Confirm password" fields.

3. Generate and fill a new password.

:)

RichardPayne

What's the equivalent to Option for Windows?

khad

Alt in general, but I don't think the same functionality is present on Windows at this time. I'll double-check to make sure, though, and put in a feature request if not.

However, for now you can definitely toggle Settings > Auto-Submit Logins in the 1Password extension menu on Windows.