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 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. OK, not exactly the style of change password form I'd prefer, but I can see how it will do what I need it to.

As an aside, my favorite change password forms are those that are very accessible, easy to find, and are very clear. For example, the style that has you enter your current password, and then the new one, repeated below, is my favorite. I'm also good with a simple form asking you to enter your new password, and then repeat it below. Since you are already logged in, this is sufficient for most purposes. Sure, the former example is more secure, as browser settings can result in someone other than you accidentally stumbling into your account while it's logged in. So I get that. However, if you adjust your session times or use an application like Django Session Security, this problem is mitigated.

So 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 frankly, I like them). This is a host that uses older technology, so it didn't have a fancy script validating on every keystroke, making sure the strings match. But that's OK, right? 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 script had an additional bug that caused a redirect to fail, and the page to lock up... Real bad... real, real bad. 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 philosophically stupid) number of characters to restrict a password to?" I tried it. Boom, I was in... This confirmed my suspicion. The password had been truncated, without my knowledge, and I had to guess what it was. I was completely shocked, dumbfounded, and very surprised that a web hosting company, responsible for dozens or more client's data had such a fundamental (yet potentially disastrous) bug.

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 that runs ads on SiriusXM radio and other media outlets. Not too hard figuring out which one it is... 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 as such. Don't allow the field to accept 22 characters, only to again silently truncate the password!

If you want to enforce stupid password requirements, like a capital, a number, a special character, etc, fine... I'm getting used to these asinine 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, ever! I won't go into the reasons why; read up on it, if you want. 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...

So here I was, getting ready to change my password. I find the form. It was the kind I like: enter existing password, and then your new password, followed by repeating it below. OK, check; so far, so good. And, even better, this form had requirements: "password length between 4-20 characters, use at least one number, one unicorn, one monkey, blah, blah, blah..." OK, check.

So I proceed to enter the data (to be fair, I was a bad user. I hadn't yet counted my password characters, so I didn't realize it was 22 characters long). 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'm golden. 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 enter my newly changed password, and it fails. Tried again -- FAIL! Since I'm on a roll discovering bad authentication forms lately, I start investigating. I went back to the page and refreshed it. The password actually filled in this time when I entered my user name. I use Firefox to set a master password for all my other passwords. And I remember that when the password change was complete, Firefox politely asked me if I wanted to update remembering this password for this particular user name. I said yes.

So I log in successfully, review the password requirements, and count my password. Ahhh... I sigh, and slam my palm against my forehead and get on chat. I couldn't believe all this shit, so I have to complain to someone. I chat up my buddy who shares an interest in this kind of thing. We exchange some web developer bashing and profanities, and I get back to it.

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 two most important characters (just kidding), and it works. I'm in! The fact that it did truncate my password isn't the worst part of this story. It's the fact that they set forth a restriction 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 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 with this. 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 the right thing to do. 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!


Comments powered by Disqus

 Blog Search

  Popular Tags

django, ubuntu, python, apache, mod_wsgi, virtualenv, ssl, raid, nginx, forms, bash, linux, dell, uwsgi, customer-service, tls, netflix, git, ux, centurylink, software-companies, rais, form, centos, password, certificates, tinymce, mdadm, dual-boot, file-server, virtualhost, gluster, IT, blog, get, networking, piplight, distributed-file-system, big companies, bitnami, cygwin, windows, authentication, samba, scripting, pygments, post, programming-language, ui, lampstack, outsourcing, isp, security, usabillity, provision, php, shared-hosting, flatpages, syntax-highlighting, virtualbox, hg, redirect, usability, prg, acls, change-password, complex, view tags...


Drop me a line... [email protected]
Follow me on Twitter... @nicorellius
Share on Facebook...