Web Developers, Come On. You're Dropping the Authentication Ball!

In recent years, I've caught more and more severe authentication bugs on the web

Published on May 19, 2016 by nick

Tags: ux, password, ui, forms, usabillity, authentication

OK, I'm pissed. I mean, really, really pissed. Why? Let me share two bugs I discovered recently when trying to change some passwords for some clients. This happened on two sites that should have better security.

First one has to do with silently truncating passwords. I logged in to a web host (who shall remain nameless, for now...), and went to the accounts section, looking for the change password form. I found what I was after, and took a closer look.

I type in my desired password, and then type it in again, very carefully, making sure I get it right (the new, "show password" options are used more and more, and are pretty nice). This is a host that uses older technology, so it didn't have a script validating on every keystroke, making sure the strings match. But that's OK. As long as the server compares them, I'm good with that. While entering the password in the first field, I get this feeling that it's not accepting my characters. I notice that the password "dots" stack up around 16 characters, and it's impossible to tell whether the field is actually allowing them in. Of course, the form doesn't indicate any restrictions, so entering my 22 character password seems perfectly reasonable to me. In this particular case, the web page had an additional bug that caused a redirect to fail, and the page to lock up... That's bad, especially when the user is trying to change a password.. After forcing the site back to the log in page, I tried to log in... FAIL. OK, mistyped the password, right? FAIL... again.

This got me thinking. I remembered feeling shaky about the form in the first place, so I tried something. I counted the characters in my password (22), and then thought "what would be a reasonable (yet misguided) number of characters to restrict a password to?" I tried it and I was in... This confirmed my suspicion. The password had been truncated, without my knowledge, and I had to deduce what it was. I was very surprised that a web hosting company, responsible for hundreds of client's data, had such a fundamental flaw in their system.

I filed this bug report with the company via their ticketing system two days ago as a high priority ticket. Haven't heard back from them.

Bug 2. This one involves a particular email fax company. This bug relates to form validation. Password requirements aside (an entirely different argument for an entirely different day), at the very least, a web form should enforce the requirements it sets forth. For example, if the form states that the password should be between 4-20 characters, fine. Validate it this way and enforce your requirements. Don't allow the field to accept 22 characters, only to again silently truncate the password!

If you want to enforce strange password requirements, like a capital, a number, a special character, etc, fine... I'm getting used to these unnecessary requirements. But, if you do, you better validate the data coming in. You cannot trust the user. Let me reiterate: you can't trust the user! We learn this early on in our web development careers. Don't trust user input. If for no other reason, they might mistype their own password! Which, by the way, can result in increased technical support, and wasted time helping users reset their password...

I proceed to enter the data, I click the submit button, and I got an error message saying something about my two passwords not matching. OK, good, some validation is occurring... I try again, and it works. At this point, as a user, I'm thinking I've succeeded. Since the form didn't yell at me, I assumed my password change was accepted. I log out, and then go to the login page again.

I log in successfully, review the password requirements, and count my password. Ahhh... I sigh, and slam my palm against my forehead. Since my password is 22 characters, and the length requirement was 20 characters, I deduce that this awesome site did me a favor and silently truncated my password. I try the password minus the last characters, and it works. I'm in! Not only did the site truncate my password, it used a restriction behind the scenes and didn't enforce it. How hard is it to test the length of a string?

if password > 20:
    error = "password must be less than 21 characters!"

I think it goes without saying how really important it is to adopt better user authentication practices when it comes to web site login/registration forms. Some will argue that using only user names and passwords to access an application is less than good all together. I won't disagree. But the fact is, currently, this is the de facto method web developers use to authenticate users. I think having the discussion about improved methods, stronger security, and better usability is warranted. But in the meantime, we should try harder to get it right. It's not that hard to implement a reasonably secure and easy-to-use login system for your web site. Just do the research, and spend some time thinking about what you would or wouldn't want to see in this process. Imagine you are the user, what kind of form do you like? What issues have you seen when signing up or logging into your favorite web sites? Have you noticed any security holes in the process?

As the discussion continues about better methods for authentication, we should all keep an eye out for sites using bad practices. Report them to the web masters, write blog posts, complain on social media. This is our privacy, our data, our secrets... we are putting trust in these web sites to keep our data secure, and when they don't, they need to hear about it, and fix it -- now!