Thursday, March 10, 2011

Signs of Broken Authentication (Part 1)

First a warning...this topic is one of my hot buttons issues, so my tone may be a bit more over-the-top and sarcastic than usual. (But for those of you at home with small children, I promise to refrain from cussing.)

OK, quick quiz... have you ever visited a web site where they want you to register with a user name and password, and when you finally get to the password field to choose your password you find that they really make you dumb down your password choices by restricting what characters you are able to use and/or how long you are allowed to make your password?

Or maybe you have seen web sites that have don't use https for their login pages???

Unless you've just crawled out from under a rock and have just discovered web browsers, you've all been there.

However, unless you suffer from security-paranoia like me (it's all the fault of those NSA folks and their blasted little black helicopters; now where'd I put my tinfoil hat), these things probably don't bother you. Over the period of the next few days in a multi-part blog post (thanks Matt! ;-) I'm going to tell you why these things should concern you and how to spot "broken" authentication. (But until then, just remember, us security professionals are paranoid so that the rest of you don't have to be.)

Why This Is Important

Broken authentication on a web site is akin to a bank whose vault door has rusty hinges. Your money may be secure there, but you might want to think about taking your cash to the bank down the street. Likewise, if the authentication on a web site has poor security, it is likely that the security for rest of the site is even worse. That's because authentication is probably the major area that most developers try to pay very close attention to with respect to the security details. It is generally one of the few spots for which they may even have specific security requirements.

Red Flag #1: Maximum Password Length

Let's start with a restricted password length. Why do developers do that? The most obvious reason is that they are storing your password in some database somewhere in some fixed-size VARCHAR column. So they choose some minimum size size to make their SOX-compliance people happy (typically 6 or 8 characters) and choose a maximum length based on the maximum size that their database can accommodate. Not uncommonly, that size might be something like a power of two, so maximum lengths like 16 or 32 characters are common.

“Isn't 16 or 32 characters long enough for a secure password?”, you ask. Of course it is, but that's not the point. The point is, if they are imposing a maximum length, I can almost certainly guarantee that they are not running your password through a secure, one-way hash such as SHA1 or SHA-256 before they are storing it. Most likely, the are just storing your password as plaintext, although if you are lucky, they may be encrypting it and storing the ciphertext for your password. (Probably not, but one can always hope.) Not hashing passwords is bad for a lot of reasons, but the biggest reason that you as an individual should be concerned about is someone stealing your password. Minimally, an attacker who captures your cleartext password can use it to access this particular site whenever he or she wants. And how many of you reuse your same passwords on multiple web sites? Uh huh. I thought so.

Well, when your passwords are stored as cleartext, if their web site is susceptible to SQL Injection (SQLi)–a fairly common vulnerability, some hacker just might make off with their entire User table along with all of its cleartext passwords which some of you (you know who you are!) might just be using for your bank or 401(k) or your Facebook page, etc. (I can hear all of you now saying “Not me; I would never do such a thing.” Liar!) And of course, even if their site is safe against SQLi because their developers were smart enough to have read the OWASP SQL Injection Prevention Cheat Sheet, your passwords are still lying there in wait for a rogue DBA to grab them. (It happens; trust me. Google it if you don't believe me. I'll wait...)

On the other hand, if one hashes passwords, preferably with a suitably sized salt (we won't be covering the reasons for that here, but Google for "salt" and "rainbow tables" if you are interested), then the hash (or hash plus salt) will always be some maximum fixed size regardless of the length of the original password. In such cases, there is no reason to impose a maximum length on the user's password because the hash that's stored is of fixed length.

So imposing a maximal length on a user's password is generally a good indication that that web site is not hashing your password and generally, that is a bad thing.

(to be continued...)


  1. Just a tidbit of info to add.

    For apps using Active Directory as an account store and if they have to support some legacy authentication protocols (I think its NTLM but can't be sure), a 16 char max length must be used.

  2. Kevin,

    I know a banking website which restricts users to enter password between 6 to 10 letters. So, Can we say that they might be also storing passwords in cleartext?

    Please mail me your advice at

    Security Analyst,

  3. @Greg: Thanks, Greg. That's good to know. I figured that everyone who had switched to AD was using Kerberos by now, but there probably are still some using NTLM.

    @Nilesh: Well, it might the case that these banks are storing passwords as plaintext, but there most likely are other explanations. They are probably (hopefully) encrypting (rather than hashing) customer passwords. Or perhaps it's a situation something similar to like Greg pointed out. I'd be VERY surprised if banks--even the small ones--were storing their customer passwords in cleartext. This was common maybe 8-10 years ago, but now there are regulatory issues that almost certainly mandate at least some semblance of security.

    For example, NACHA (National Automated Clearing House Association) compliance is required by most (all?) US banks and credit unions. NACHA started out patterning their security rules after PCI Data Security Standards. I am not sure how much, if at all, they have diverged, but the intent of NACHA's Operating Rules & Guidelines and PCI's Data Security Standards is still very much consistent even though they may vary in some important details.

    And while I don't know the exact chapter and verse where the NACHA security rules mandate that passwords be stored in a cryptographically secure manner, PCI DSS 2.0 does mandate in section 8.4 that "Render all passwords unreadable during transmission and storage on all system components using strong cryptography". (Emphasis mine.) So to me at least, I think that implies that banks would not be in compliance with NACHA Operating Rules & Guidelines if they are storing customer passwords in plaintext. Unfortunately, the NACHA Operating Rules & Guidelines are not freely available (see, so if anyone has a copy and can confirm that customer passwords kept by banks must be encrypted or hashed when stored, I would appreciate you posting a comment to here to inform us all. (The cost for this NACHA document is $39 for members and $78 for non-members, so I do not intend adding a copy to my library anytime soon.)

    Lastly, note that I still believe that it is better to hash passwords (preferrably using salts as well) than it is to encrypt them. For one thing, hashing is a whole lot simpler to get correct. (Witness the ESAPI screwup as discussed in "ESAPI and the Padding Oracle Attack".)

    Anyhow, hope this satisfactorily answers your question.

  4. Thanks for this Kevin, I was looking for something like this for long time, one to be confident in my thoughts and second so that I can share this with some people who didn't believe me :-)