Security through lying


I had forgotten the userid I had used to generate one of my online accounts. I thought I had used an underscore, but I couldn't get the site to accept it. It did yell at me, though. "Userids must begin with a letter and may consist only of letters, digits, and hyphens."

Okay, I tried it with a hyphen. No luck.

Fine, use the userid recovery system.

The recovery email arrived. It say "Your userid is raymond_chen."

Apparently, when they said that underscores were not legal characters, they were lying.

Another site asked me to create a password, and it said that the password must contain a special character "for example ! @ # $ % ^ & *".

I tried all sorts of passwords and it kept telling me that the password needs a special character, even though I tried [, ~, \, =, :, you name it.

Turns out that the only special characters the site recognizes as special characters are ! @ # $ % ^ & and *. In other words, the "for example" was not a list of examples. It was a comprehensive list of acceptable values.

Comments (67)
  1. Falcon says:

    Had they changed the rules since you created the account?

  2. Aaron says:

    I registered at one website that allowed a % in the password *when you register*, but would not accept that same password *when you logged in*. You could successfully register with a password that you could never use. Angry.

    1. anon967404 says:

      I have encountered a certain website, with many thousands of members, that would let you sign up with a “\” in your password but login would fail, with no clue what was wrong. That smells suspiciously like poor escaping and no hashing, presumably in PHP given the site’s amateur origins. Given the private/embarrassing nature of some of the information on there and the hatred the membership get from some other quarters of the internet, it’s a bit worrying.

    2. Mason Wheeler says:

      Back in high school, a friend of mine called me over because his sister couldn’t get into her Hotmail account. (This was in the late 90s, when Hotmail’s acquisition by Microsoft was still a recent thing.) She said that she had recently had to reset her password because some reason or another, and she told me what her username was and the new password that Hotmail had assigned. I tried logging in, and… nothing. The server errored out somehow.

      So I went in to try to reset the password, and noticed something odd: it gave a list of acceptable characters for a password, and the temporary password it had assigned to her was unacceptable per the system’s own rules! Somehow I got it to reset to a working password, and she was able to log in again, but I’ve always wondered how exactly the Hotmail system got her into that mess in the first place.

      1. Kemp says:

        My favourite Hotmail one was that it would truncate all passwords to a specific length behind the scenes. Everything was fine (other than the obviously weakened password strength)… until you tried logging in with a third-party piece of software that *didn’t* truncate. Login failed with (from the user’s point of view) the correct password. That was an annoying one to figure out.

    3. Lev says:

      I had a similar situation with a site that allowed me to enter a password with ‘ but stripped the quote without warning me. Luckily I guessed it. Yay Bobby Tables!

  3. 12BitSlab says:

    I always use CorrectHorseBatteryStaple as my password. Much more secure that way. /s

    In all seriousness, it is concerning that many sites still have issues handling passwords — not just in assisting users, but extremely poor password handling issues; e.g., don’t use salt — just take a single SHA1 hash and store that in a DB table.

    1. Darran Rowe says:

      Recently, I was changing my password with one well known online email provider, and was chuckling when it classed a 20 character password without any special symbols as having fair strength, while a password with 10 characters that had numbers was strong. I obviously was wrong when thinking that entropy mattered more than special symbols.

      1. bickerdyke says:

        Entropy isn’t all that counts. Any random set of 8 digits would have the same entropy (assuming each digit as a seperate value) – but still 00000000 is a much worse password than 79516892

        Assessing the actual “strongness” of a password would include checking against the dictionaries of known dictionary attacks. I’d guess it is a valid assumption that a random digit makes finding a password in a dictionary less likely than finding a long, but common word.

        tldr; I think it’s a good rule of thumb.

        1. Darran Rowe says:

          *sigh* This always happens when I don’t bother completely saying everything. Just once, I thought that the assumption that people would be using a good spread of characters would be obvious.
          But I guess the people factor always comes into it.

          1. zboot says:

            Clearly, you still misunderstand. How do you determine a password is good? You say entropy is a good measure. Fine, how given a 20 character password or 10 character password, which has more entropy w/o examining the password? Complaining that a hammer is the wrong tool to use to open pistachios does not impress, regardless of how much info you though you didn’t need to provide about the hammer.

          2. Henri Hein says:

            zboot: I don’t understand. For one thing, I am not getting how the hammer metaphor applies here.

            Assuming Darran uses a good distribution of characters, how do you conclude we can achieve more entropy if we eliminate those passwords that contain special characters? It was never clear to me how reducing the address space makes it harder for an attacker to achieve a hit.

          3. smf says:

            What else do we have to assume?

          4. Darran Rowe says:

            @smf:
            Just regular sense with passwords really. But it seems that I was under the major influence of insanity assuming these things.
            @zboot:
            Well, the simple fact is, a 20 character password has more entropy than a 10 character password. Since you probably aren’t even going to read anything I write anyway, let’s explain this with xkcd. https://www.xkcd.com/936/

          5. cheong00 says:

            Note that when the site allows alphanumeric + special symbol characters as password, there’s no technical difference on entropy for each of the characters added to the password, regardless of category of the character.

            So the only factor that can affect the password strength other than the password length is likeliness to be attacked by dictionary attack, the choice of letter doesn’t really matter.

            That said, I’ll say any password consist of just 8 numeric characters is vulunerable to dictionary attack, unless the method to compute the password hash has salt added to it. If “salt” of alphanumeric + special symbol characters and floating variable like “time” is added to create the hash, given the salt is safe (not leaked to attackers) I’d say it’s secure enough.

          6. Evan says:

            @cheong00: given the salt is safe (not leaked to attackers)

            This is a very bizarre threat model.

            If you’re assuming an online attack, then the fact there’s a salt is irrelevant.

            If you’re assuming an offline attack, then the attackers got a hold of the password hashes. But the password salts, by necessity, are just as accessible through legitimate means as the password hashes (in terms of access control, permissions, etc.); in a significant majority of cases then, attackers would also have been able to obtain the salts alongside the pw database.

          7. cheong00 says:

            @Evan: I’m thinking about certain stock trading WinForm application when typing that.

            Since I used to keep Fiddler on, occasionally I’ll see what are the traffic content when I got bored. I found such application connects to certain web service in order to function, and when it calls GetUserInfo method, the XML the returns user data contains password field too. (Thankfully at least I see something like hash there instead of plain password)

            I can see that because I’m decrypting HTTPS traffics. However let’s don’t forget that some companies already use proxy servers that decrypts HTTPS traffics to enforce IT policy.

        2. Antonio Rodríguez says:

          Tried to set my PayPal password to a 20 characters mixed case passphrase. PayPal rejected it as “insecure” because it didn’t have digits or symbols. Had to add a number at the end to keep PayPal happy.

          I guess PayPal engineers think it’s safer a random alphanumeric sequence you have to store or write down somewhere because it’s impossible to memorize.

        3. Voo says:

          8 digits assuming upper case, lower case, digits and the ten or so most popular special characters has a search space of (26+26+10+10)^8=7.2E14.

          Using five words assuming a two thousand word dictionary gives you a search space of 2000^5=3.2E16.

          So no this is a horrible rule – it sounds reasonable but the math doesn’t back it up (sure one more character makes everything more secure, but why focus on the stronger one).

          Nitpicker’s corner: This all assumes you pick random words/charactersif you don’t, both methods will be unreliable.

        4. Entropy is all that counts; however, you need to use an appropriate measure of entropy.

          Specifically, the correct measure for a human-memorable password is *not* “the odds of this password being chosen by random chance” (in which “password” and “vgtozvup” have the same entropy), it’s “the odds of this password being chosen by a human” (in which “password” has far lower entropy than “vgtozvup”).

    2. Max says:

      Or don’t hash passwords at all. One fairly large and economically important company (not a tech company) I worked for didn’t do this at all. In any new projects I made absolutely sure to do it, but I had pushback—the sysadmin wanted to be able to see user’s passwords in plaintext so he could log in as them to debug problems. And since there was no mechanism for actually *changing* passwords, he was editing the database directly and didn’t want to go to the trouble of hashing and salting. Needless to say, I didn’t work at that company for long. I have no doubt that their practices haven’t changed one bit.

      1. Joshua says:

        Indeed, and not allowing arbitrary special characters in passwords screams “I store passwords plaintext!” to engineers.

        1. Chris B says:

          Even worse – it screams “I’m vulnerable to SQL injection attacks!”

          1. Simon says:

            Very much so, yes. There are few good reasons to restrict the set of characters that can be entered, and there’s one very bad one – you don’t trust your system to cope with them correctly. So as a developer, when I see a system that does that, I immediately assume that the latter is the reason for it. And I’ve no doubt the black-hats think the same way…

      2. French Guy says:

        Another thing that screams “we store passwords in plaintext” is a requirement that a new password must not be too similar the N previous ones. There is no way to know that from hashed passwords.

        1. Danish guy says:

          Of course you can. Just compare the hash against last N hashes

        2. bdcrazy says:

          You can store the hashed password of the previous N attempts to prevent the use of the last N passwords… At least I’d hope they’d do that.

        3. Capi says:

          Of course you can, you just need to store the last N hashes…

          1. Capi says:

            Ups, sorry, “too similar”, you are right, I somehow read “same”.

        4. Alex Cohn says:

          Why? The new hash is equal to none of the stored N latest caches.

          1. Micha Elyi says:

            Why? Because “too similar” is not the same as “identical”.

          2. Drak says:

            Err, because the hashes of password and pasword can be completely different, and how would you then know that the password is *similar* to the old one? The same password, you can do with hashes, similar is rather more tricky (unless you store the previous passwords as soundex strings or something :P )

          3. French Guy says:

            Exactly what Drak said. One of the requirements for a cryptographic hash function is that a tiny change in input produces a huge change in output. Thus, you cannot determine whether 2 passwords are similar (but not identical) using only their hashes. The requirement you describe is “the password must be different from the N previous ones”, not “the password must not be similar to the N previous one”. The former can be checked with hashes (though 2 completely different password can have the same hash), the latter cannot.

          4. You could in theory store hashes of a number of variations of a password, such as all possible passwords you could get by adding, removing, or changing 1 or 2 characters. Then you could test for a small amount of password similarity without storing the passwords in a reversible form.

            But that would be a *terrible* idea, though, since now you’ve just made brute force cracking attempts orders of magnitude easier — if a hacker gets your database dump with hashed passwords + variations, they only have to search a fraction of the dictionary key space to find a match against any one of those variations.

          5. Sean Barnes says:

            For similar passwords you don’t need to store all variants. Instead take the new password and compute hashes of all similar passwords to see if they match previous passwords. And there are probably a relatively small number of transformations people regularly use (probably minor changes to the end of the password).

        5. Jonathan_S says:

          @French Guy
          That probably true in general, but technically it only shows that your previous passwords are stored in plaintext (or hopefully stored using reversible encryption). The current one might still be saved only as a one-way hash.

          When you do the password change you (usually) have to provide your old password one last time. Normally the system just hashes that and compares the hash to the stored password hash; but it could also then save the plaintext (that you just gave it) of the old password off to the non-hashed history. The new password would only be stored as a hash. (until the next time you change passwords)

          Exposing your past history of passwords is only a risk if there’s a pattern to them, or if you’ve reused them elsewhere. (Of course most people probably do at least one of those; so there’s still a real world risk).

          1. French Guy says:

            I hadn’t thought about that. But password reuse is very likely given the number of applications requiring a password a single person can use, and patterns in password usage are very likely to result from requirements of changing passwords regularly. In other words, measures designed to increase security fail because they decrease usability, so users work around them insecurely.

          2. Bob says:

            I know nothing about this topic.

            1) Since password changes are relatively rare compared with authentications, the list of old passwords doesn’t have to be nearly so easily accessible as the userid/salt/hash combination is. Maybe password changes are directed to only a subset of servers which can be more carefully watched.

            2) Don’t index the old password list by userid. When you’re changing a password, you have access to the plaintext old password, so index with HASH(userid,password,another-salt). And, keep picking random salt values until there is no hash collision.

          3. Bob says:

            No, Bob. You don’t do that because you can’t retrieve the list of old passwords when you reset the current password…so you lose the history on a reset & the database collects cruft.

        6. Pilchard123 says:

          According to an answer on StackExchange, the way it could be done (and apparently the way Facebook does/did it) is to generate the passwords considered similar to the old password, then compare against those. I don’t know if I can post links here, but if I can, there’s more information in a link below.

          http://security.stackexchange.com/questions/53481/does-facebook-store-plain-text-passwords

  4. Ray Koopa says:

    And then there’s this big, well-known internet company telling you how much they love security, and don’t allow § in their password – a character you can easily type (on a German keyboard at least) with uppercasing the number 3.

    1. Simon Clarkstone says:

      Disallowing things not in ASCII is more understandable. It prevents problems from encoding mistakes occurring in the route from keyboard to hashing function.

      1. The_Assimilator says:

        Hardly. Unicode has been around, and standardised, long enough that any company not supporting it for something as fundamental as passwords screams massive incompetence.

        1. Ray Koopa says:

          Especially for that company building on a market where encoding errors would ruin it pretty it quickly

  5. Websites lie about their password requirements all the time. Their descriptions of the requirements, their JavaScript client-side validation, and their server-side validation frequently disagree. Sometimes you can disable the JavaScript validation and remove the input field maximum length to work around the false requirements, and the backend will accept longer passwords with all special characters just fine, but that’s not too common.

    I’ve even seen a few sites which weaken their requirements, say be decreasing the maximum password length or by adding additional prohibited characters. Yet, even if your old password doesn’t meet the new requirements, you can continue to log in with the old password, but if you ever decide to change or reset it, you must conform to the new requirements.

    The number of sites that do this is depressing. Using salted and hashed passwords become the industry standard *how many* years ago?

    1. roeland says:

      Using salted and hashed passwords become the industry standard *how many* years ago?
      → from my experience, a *lot* of years in the future. Web sites which allow any character in passwords are still the exception today.

      Maybe they are storing the passwords as clear text. Maybe you can wipe their database by choosing “myPass’;DROP TABLE users; –” as your password. Or (an equally suicidally wrong option) maybe they’re using their own custom-build password hashing function.

    2. Wombat says:

      Why would the backend know whether the password contained special characters? Surely the password should be salted and hashed before it left the browser? (and again at the backend)

      1. Pilchard123 says:

        Doesn’t doing that just make the client-hashed password into the real password?

  6. jgh says:

    One of the greatest annoyances with documentation is when it outright lies to you. “No drivers needed for this web camera, just plug it in”. No it doesn’t, that went straight into the bin. “Select ‘export type: name+address'”. No such export type. STOP LYING TO ME!!!!

  7. Wyatt says:

    My personal favorite is websites that have a maximum password length, but then truncate the password if it is too long. For instance, you might enter CorrectHorseBatteryStaple as you password when you create the account, but if you try and login again later, you find that your password is in fact CorrectHorseBatt. Annoying to say the least

  8. Oakreef says:

    I once forgot my password for a website and used their password reset function. Now at this point I’d moved on to using a password manager that automatically generates and stores long, complicated passwords for me. So naturally I generated a super secure password for the site when the password reset form prompted me for a new one, about forty characters long I think.

    When I then went to log in with my new password I discovered it wouldn’t allow me as “passwords must be between 8 and 16 characters”. I tried a truncated version of the password I had set but that didn’t work either. To get in I needed to reset my password *again* and set a shorter one. It would seem there was no validation on the password reset form so it allowed me to set a password that was then rejected when I actually tried to log in with it for being too long.

  9. BZ says:

    To be fair, how would you know what a “special” character is without a comprehensive list? if I saw the above message, I would use one of the characters provided. As for username/password boxes “yelling” at you, I wish more of them did that because I have a scheme for generating passwords which depends on what is required to be included. Of course if what it’s “yelling” is incorrect, no thanks.

    1. Tim! says:

      I assume “special” means “anything other than a letter or number” and I think that is a reasonable assumption. There is no good reason for an authentication system to limit the set of valid characters in a password, and many bad reasons.

      1. dave says:

        But then you have to know what they mean by “letter” or “number”. Generally, “letter” means the 26 letters that Americans use. and “number” means the 10 decimal digits that Americans use.

  10. pmbAustin says:

    Sites should stop this stupid validation and password requirements. They’re stupid, annoying, and counter productive. Accept what I give you. Having 10 different sites with 10 different sets of rules just means I’ll end up writing down passwords, or constantly forgetting them and having to reset. Either the entire world needs to decide on what the ‘valid password character requirements’ are, or they need to just shut up and let people use whatever the hell they want.

    1. Henri Hein says:

      I completely agree. It’s particularly infuriating that the requirements are not only different, but sometimes incompatible. For instance, some require special characters, some don’t allow them. I don’t get it either. If they are doing it right, they should be just hashing it anyway. They should be able to accept any string, even a binary one.

    2. It’s particularly annoying when the documentation and the code don’t match – I carefully tell my password manager to generate a random password that meets your requirements only to find that:

      1. Your list of special characters is wrong, and my password manager’s password doesn’t comply, despite meeting the written requirements.
      2. Your code handles some characters in a funny way, and my 16 character password is seen by your site as 18 characters (thus too long).
      3. You’ve tried to reject “easily confused” characters, and your algorithm differs from that in my password manager.

      I’m sure there’s more, but those are the three I’ve encountered.

  11. Tim! says:

    A certain online banking provider used by small local credit unions accepts a vertical pipe (‘|’) during password creation, and authenticates past the login form, but the main site hangs during load during some secondary authentication. It is bizarre and frightening.

  12. I’ve always found annoying and scary that my Windows password can no longer contains spaces if I want it linked to my Microsoft profile but al least you’re correctly warned about it.

  13. smf says:

    I forgot my password once and when I went to enter my email address is wouldn’t let me as it was too long, even though I had signed up and it worked fine. I had to grab the html and remove the limit, host it locally and have it post to the real web site. I doubt I could do that anymore.

    1. Simon Clarkstone says:

      Nowadays wouldn’t you use your browser’s built-in DOM inspector to edit the DOM to remove the restriction?

  14. Ivan K says:

    For some applications I’ve given the benefit of the doubt and assumed the crazy character restrictions were due to having to satisfy the lowest common denominator in keyboards for different login situations. Sure my laptop has a rich US keyboard layout, but my 5 year old Smart TV’s onscreen keyboard sure doesn’t… and the manufacturer isn’t interested in updating it. So if I create a password on my laptop and then try to use their TV app… ba-bow.

  15. AlexShalimov says:

    Once I tried to register on a site that uses your phone number as login. In our country cell phone numbers can begin with either 8 or +7 — they’re equivalent. I’ve entered my phone number as +7xxxx, and registered successfully, but couldn’t login after that. When I’ve entered +7xxxx, the form says that the phone number is too long (expecting 8xxx, probably), and when I’ve entered 8xxxx it said that login is incorrect. Catch22 at its best.

  16. dave says:

    “Turns out that the only special characters the site recognizes as special characters are ! @ # $ % ^ & and *”

    Where the definition of “special” is “those non-alphanumeric characters we permit you to use”. That’s why they’re “special”.

    This is a pet peeve: the meaningless term “special character”. I don’t see why, for example, an asterisk is more “special” than the letter A. I don’t know whether A-with-ring is “special” to someone. Etc. Mostly, it seems to mean, any characters that were not considered to be alphanumeric in the long-obsolete character set known as ASCII, though we’re not always sure about whether underscore is special. Perhaps special means not legal for identifiers in ANSI C source programs.

  17. Azarien says:

    “Your userid is raymond_chen.” – no wonder you couldn’t remember it, with a dot at the end…

    1. Micha Elyi says:

      Documentation is hard. Accurate documentation is the power set of hard.

  18. Tony Lezard says:

    Just the other day, I was refused a password change on a financial system we use at work because the password began with a digit. What on earth were they thinking there?

Comments are closed.

Skip to main content