How can I tell if my password is encrypted?

For most websites, we don’t have the source code available. As a user, we more or less trust the site is doing “the right thing”, or well, we just use a throw away password that we accept to be compromised.

Sometimes, it is obvious. For example the site is sending you your password in the clear. Other times, it is less obvious. Usually, if a site is imposing limits to your password, like the length or it doesn’t allow certain characters, you can guess that your password will be stored in the clear.

The reason is simple: If the password is hashed, then it doesn’t matter how long it is, or what characters it uses. It will always end up as a fixed length hex string. SHA1 creates 20 bytes (40 hex characters), MD5 creates 16 bytes (32 hex characters). The one exception may be if the code uses a database function to do the hash. For example some pseudo code:

update users set passwordhash='$hash'

In this case, it doesn’t matter if the password includes a single quote or whatever. However, it could matter in the following snippet:

update users set passwordhash=sha1($password)

(Needless to say, I wouldn’t use dynamic SQL like this, but this is the topic of another blog post).

The length of the password is typically limited, if stored unencrypted, because the database table was defined with a certainl length for this field. Maybe even worse: If you are not told about it, your password maybe truncated “silently”.


7 thoughts on “How can I tell if my password is encrypted?”

  1. One thing to note:

    The same programmers who wouldn’t think twice about storing passwords unhashed, when restricted by coding standards, will often just change the storage and retrieval code. The validation code stays the same, and you’ll still see length, special char, and other rules enforced.

    It’s still a sign that they don’t understand how to handle passwords, but it doesn’t necessarily mean that your password is being stored in the clear. I’m just pointing it out because I see this on a regular basis, from developers whose code keeps me depressed.

  2. “…if a site is imposing limits to your password, like the length or it doesn’t allow certain characters, you can guess that your password will be stored in the clear”

    Well, you could guess that, but I think it’s far from a reliable indicator.

    On z/OS mainframes with RACF, passwords were restricted to no more than 8 characters, [A-Z0-9@#$], but certainly were not stored unencrypted… Actually, they weren’t stored at all! Instead, it was the username that was encrypted, using the password as the key. Clever, huh?

    And the implication — that a site that _doesn’t_ impose limits on your password _won’t_ store it in the clear — is bogus too.

  3. I disagree that putting restrictions on password lengths and characters etc is a sign the password is being stored in plain text. I actually think its a good sign the developer cares about your privacy more than those who dont put restrictions on password lengths etc.
    Its good practice to have complex passwords, so those who dont force their users to have a minimum length, at least one number etc etc on their password are encouraging loose passwords that are easier to guess/hack.

  4. Robert:

    this is not about requiring MINIMUM requirements, but limiting the MAXIMUM. For example, if a site limits you to NO MORE then 8 characters for your password, or does NOT allow special characters like a single quote.

  5. Apropos of the comment by Ant, one interesting test for any web site is to enter a password longer than 8 characters and then try to log into the site using only the first 8 characters of your chosen password. If you get logged in, it means they’re probably hashing your password with the classic DES56 hashing algorithm, which is terribly easy to brute-force if an attacker can dump the site’s password database somehow.

  6. Sorry, Johannes, but -like the other readers- I have to disagree with you on this one. As Ant said, imposing strong password rules are generally a good practice. But even the maximum limit can be useful too, in contrast with what you said to Robert. I have developed many web applications with hashed passwords, yet I impose a maximum limit all the time. Without a maximum limit, hackers or those who just want to bring your website down can simply paste a 1000-page article into the password field. Try it for yourself and you’ll see many websites go down with a very simple attack like this. In fact, a limit on almost all fields is important. Anyway, I agree with you 100% on not trusting websites because from my experience most programmers don’t know or don’t care about security. You tell them this or that is wrong and they go like “yeah, yeah, yeah, whatever”.

Leave a Reply

Your email address will not be published. Required fields are marked *