Security protects only up to 8 "crackers"



  •  Hi, all, I'm a long time reader, first time writer. I decided to sign up just to tell you this WTF.

     I recently signed up with a brokerage firm I will call "TD Charles Morgan." Upon registering online, it asked me to enter a password I would use to access my account... between 6 and 8 characters. I didn't like this restriction, as I felt it gave potential 'brute force' attackers a more narrow window if they knew about this limitation. I decide I enter a substring of my other bank account, replacing a letter with a number. So, assuming my other bank account's password is "mygorgeous", I entered "myg0rgeo"

     Several weeks later I went to login. Out of force of habit, I accidentally entered the full password, "myg0rgeous". Just as I hit enter I realized my mistake and waited for the system to retort back with "invalid password" but instead I was suprised to find I had full access to my account! Puzzled, I wondered if I was mistaken.

    I logged out and tried another password, "myg0rgeo123", and another, "myg0rgeofdsa", and yet another "myg0rgeoextracharacters". Each of those passwords were valid according to the system. Really concerned I wondered if it worked the other way around. Thankfully, it rejected my password of "myg0rge" and "my". However, I was still a bit concerned by this bug in the system, so I promptly called customer support.

    I was glad I was able to speak with someone within 20 seconds of hold time, since I had an appointment shortly.

    Woman: "TD Charles Morgan, this is Molly speaking. How may I help you?"

    Me: "Hi, I have a security bug to report with your online system. I have an 8 character password but it allows any characters additional to my correct password. So if I have a password of 'abcdefgh' for example, it would allow 'abcdefgh1' or 'abcdefgh123' or 'abcdefghijkl' and so on."

    Woman: "Yes, that's expected behavior. Our system only allows up to 8 crackers (sic) and any additional crackers (sic) will be ignored when we authenticate."

    Me: "Um, yes, but I don't think it should only accept my one and only password. Otherwise it opens you up to possible attacks."

    Woman: "We have a security guarantee that says if your account is ever compromised we will reimburse you or otherwise compensate for the issue."

    Me: "Er, okay, but--"

    Woman: "And because we only accept 8 crackers we cannot check for additional crackers in the authentication."

    Me: "Yes, but--"

    Woman: "But we do appreciate your concern. Have we rectified your problem?"

    [At this point I'm already late for my prior engagement and don't feel like arguing on a Saturday]

    Me: "Alright, yes. Have a good weekend." [muttering: I hope your 8 'crackers' don't find my account]

    Woman: "You, too. Thank you for trading with TD Charles Morgan" 

    I am shocked that this kind of security bug is a design decision. Yes, theoretically if a brute-force attack had started with 6 characters, it would find my 8 character password before any of the others, but let's suppose they are unaware of the 6-8 character restriction and decide to brute-force with 10 characters. There are about 700 ways to crack my 8 character password with 10 characters instead of zero! Theoretically there are an infinite number of ways to enter a "correct" password for my account, instead of one. How hard is it to simply refuse any passwords greater than 8 characters on the login page, and simply say 'invalid password' any time I enter a different password?

     It should be taught in Security 101 that anything requiring authentication should accept one, and only one password for a specific user. Anything different, including differences of case, and especially number of characters, should be thrown out. Period.  Isn't that common sense?



  • I agree that the 6-8 character limit is a big WTF from a security standpoint.  Additionally, the failure of the software to actually check against the entered password is also pretty silly.  However, this absolutely does not decrease the security of the system in any way.  Take your example of the cracker trying to brute-force a 10-character password.  This ignores that brute-forcing through a web app is stupid and that any competent cracker would know about the 6-8 character limit and would use a dictionary attack instead.  Still, if a cracker is guessing 10-character passwords the guesses are essentially being truncated at 8 characters.  So in essence, the cracker is not guessing 10-character passwords at all, he is just guessing the same 8-character password over and over again.  So essentially, it's actually harder in that situation for him to guess the password at all.  Your concern about "infinite numbers of passwords" isn't valid because all superfluous characters are removed and the chances of guessing a 100-character string that has your particular 8-character password at the beginning are far smaller than guessing the 8-character password to begin with.  Does that make sense?



  • If your password is 7 crackers long can you still log in with a password of 8 crackers or more?



  • Other than the people saying "crackers" instead of "characters", there is a article in 2600 about the passwords. They do mention short password limits, and they give three options:

    1. Find a similar site with better password policy. Many sites provide similar services.
    2. Crack the web site. Show the administrator how weak it is. Of course this may be illegal, but sometimes nothing else works.
    3. Type as much as possible (what was done in the above message). Whatever doesn't fit, it doesn't fit, and it still works OK.


  • Uh, sorry to tell you, but systems have worked like this for ages. Unix systems have used a DES based crypt() system call as a one-way hash.

    The traditional implementation uses a modified form of the DES
    algorithm. The user's password is truncated to eight characters, and
    those are coerced down to only 7-bits each; this forms the 56-bit DES
    key.

    Yes, it's unfortunate, and most systems have switched to more secure one way hashes. You can still find the plain old crypt() in lots of places. Hardly uncommon. Not a WTF either, just a bad design choice in this day and age. 



  • @morbiuswilters said:

    This ignores that brute-forcing through a web app is stupid and that
    any competent cracker would know about the 6-8 character limit and
    would use a dictionary attack instead.

    A cracker, competent or not, might have hundreds of applications hacking hundreds of websites though a generic brute force dictionary attack. The cracker might not know about the 6-8 character limit, but guess what? He/she doesn't care or isn't aware because there are people with passwords like "subtract" and "subtracted", "subtracting", and "subtraction" worked. Personally, I don't know how crackers really do their job... do they go for the simple "start with 5 letters and proceed from there" or do they have special algorithms that say, "the average password is 10-11 characters long, so we'll assume that's where the gold is clustered; let's start with the average passwords first"

    @morbiuswilters said:

    So in essence, the cracker is not guessing 10-character passwords at
    all, he is just guessing the same 8-character password over and over
    again.  So essentially, it's actually harder in that situation for him
    to guess the password at all. Your concern about "infinite numbers of passwords" isn't valid because all superfluous characters are removed and the chances of guessing a 100-character string that has your particular 8-character password at the beginning are far smaller than guessing the 8-character password to begin with.  Does that make sense?

    I would argue that it merely takes the cracker longer to guess the correct password. I understand the point that guessing a 10-character password that starts with the correct 8-character password is difficult and would take longer than guessing the 8-character password. But I still find it ludicrous that it is even possible to correctly guess a 10-character password when my actual password is 8 characters. Unless I've missed something, it's easy to remove this hole: Before even comparing the password with the hash, check its length!



  • @RHuckster said:

    Personally, I don't know how crackers really do their job... do they go for the simple "start with 5 letters and proceed from there" or do they have special algorithms that say, "the average password is 10-11 characters long, so we'll assume that's where the gold is clustered; let's start with the average passwords first"
     

    Brute force guessing of passwords is the last choice, only useful when all else fails. Usually you start with well known, common passwords, which are going to be used a few times for every thousand users in a system. Then start with a dictionary attack. The /usr/share/dict/words file here has about 250k entries in the english language. Processing this takes almost no time at all.

    For comparison,  after 250,000 iterations are less than 26^4, so you could advance a alphabetic password from aaaa to ZZZZ in the same time. That doesn't cover much key space at all. Even if the dictionary attack wasn't succesful, it's better to stick with the dictionary and work with permutations. Substitute characters for numbers, add special characters at certain positions, form composite words using two dictionary words. You can do this ad infinitum, but it's much much more productive than a dumb brute-force attack.

     Check out the documentation to John the Ripper for more information on these permutations.



  • The real WTF ist that they don't use maxlength in their forms.



  • @RHuckster said:

    do they go for the simple "start with 5 letters and proceed from there" or do they have special algorithms that say, "the average password is 10-11 characters long, so we'll assume that's where the gold is clustered; let's start with the average passwords first"

     

    If you do pure brute force, you certainly start with length 1 and work up from there, it really doesn't matter what the average password length is.

    Suppose you only use digits and the average length is 10 digits:

    Checking all passwords from length 1 to 9 sums up to 10 + 100 + 1000 + 10^4 + ... + 10^9 = 1,111,111,110, which is negligible to the 10^10 passwords with length 10. Not checking them first would be counterproductive.



  • AOL uses(used?) a similar system for the account password.

    Everything after "maxlength" (imho 8, too) was truncated and only numbers and simple characters were allowed.

    I tried to use a "safer" password and took something like "aBäö25!!" (notice the dots on ä and ö). The software
    accepted it gratefully.

    But, on day I made a type mistake, and wrote "aBäö25°°". No problem, login successfully.
    Then I tried other combinations, "aBäö25", "abäö25???????", "?a?b?ä?ö?25?, all of them are accepted.
    Even "ab25", "ab25??äüöäü", "AB25???", "AäB?25" worked.

    So AOL  removed everything except [0-9a-zA-Z] and then compared it case-insensitive.

    So if you tried to use a safer password you get in fact a weaker one 



  • Amazon does this too, although they don't bother to tell you about the length limit.

    I discovered this a while back when I by pure chance made a typo at the ninth character of my password and realized I'd done it just as I reflexively hit Enter . . . and was shocked when I was successfully logged in.

    Further testing showed that they were discarding everything after the eighth character.

    You have to wonder how many people have what they think are strong passwords like "johnsmith2G78_hbn239" when they really have passwords like "johnsmit".



  • @jstone said:

    Amazon does this too, although they don't bother to tell you about the length limit.

    I discovered this a while back when I by pure chance made a typo at the ninth character of my password and realized I'd done it just as I reflexively hit Enter . . . and was shocked when I was successfully logged in.

    This never would have been a problem if you had used "hunter2" as your password, like a real man.



  • @bstorer said:

    "hunter2"

    That's the combination to my luggage! 



  • @RHuckster said:

    I would argue that it merely takes the cracker longer to guess the correct password.
     

    You're assuming that if you use a password of a length less than the limit (let's say you're using the letter 'a') will also pass through if someone tries 'aa', 'ab', 'ac', etc... That would be a truly moronic system. But if TD's just truncating over-length passwords down to max 8 chars, then it doesn't matter if someone wants to waste their time checking all possible 9+ character passwords, the extra characters are just ignored anyways. They'll get a lot of "false" positives, but still have to try to brute force all possible passwords of length 1-8

    Let's say the valid character space is limited to a-z0-9 (36 chars). That gives you around 3.2x10^32 passwords of length 8. Someone's going to have a lot of work doing a sequential password space brute force attack. If you limit it to dictionary words, then it's a bit smaller. I ain't going to count, but let's say there's 1 million 8 char words. If the attacker doesn't know about the length limit, and sets up a rainbow attack of 8-char dictionary word + random char. They let it loose on your account, and eventually get your real password, plus the other 36 million 8+1 possibilities available.

    Does it really matter if they got into your account using 'antidisestablishmentarianism' when you're using 'antidise'? They're in no matter how you look at it. 



  • That's a pretty bad system, and i must disagree with this not being a WTF. A design error can be a WTF too.
    However I feel compelled to tell about the worst login system i've encountered.
    At my previous highschool they had these online schedule, absence and grade sites. One year the systemadmin decided to write an ASP script to put it all together on a single site, with a single login.
    Not a bad idea I must say. However, one day, when logging on in the end of a summer break, to see if the new schedules had been uploaded i accidentally left out the last letter of my username.
    And to my horror, was logged in.
    This gets worse though.
    I tried then to type the wrong password, and was logged in. Even with a blank password.

    Hmm I thought, this is bad. Further testing ensued.
    The usernames where built up like: gg<start year><class><student initials>, so e.g. mine was gg03imh. I thought, it accepted my username without the last letter what about just typing: gg03i
    sure enough, it just logged me in as the first person in the class. Hmm, what about just gg03. It logged in as the first student in the year... WTF!

    Appearantly they didn't actually check it, I still shiver at the thought of how on earth the sysadmin had done that check.

    (Of course I mailed them and told about the bug, it took them MONTHS before it was fixed, well into the next schoolyear.)



  • @morbiuswilters said:

    @bstorer said:

    "hunter2"

    That's the combination to my luggage! 

    I know. How do you think I stole all your ketchup? Also, I don't know what your sig is talking about: there's no image in my sig.



  • @MHolt said:

    Hmm, what about just gg03. It logged in as the first student in the year... WTF!
    Did gg0 log you in as the first student of the century? What about gg? Is that the first student ever? 10 Interweb Points to whoever figures out what happens when you login as g.



  • @MarcB said:

    Does it really matter if they got into your account using 'antidisestablishmentarianism' when you're using 'antidise'? They're in no matter how you look at it. 

     

     Sure it matters. I'd say if someone successfully enters my account using a password I didn't even specify, it's the fault of the system for letting that person in. If the system had actually made sure the password entered wasn't too long the user would have still been locked out.

     If the user had successfully guessed 'antidise' then I can at least rationalize that the user successfully guessed my password, in which case I'd wonder if the system had adequettely detected a brute force attack... but that is far less of a WTF than if a user gained access using a password I haven't even specified.

    I don't understand your logic in saying 'what does it matter, they're in anyway'... using that logic, if someone dies of a heart attack because an ambulance failed to respond in time because someone was too busy munching on a sandwich, "what does it matter, the guy died anyway" There are assumptions I make in how someone secures my account, and one of them is "There is one, and only one password with which one can access my account" 



  • @RHuckster said:

    Sure it matters. I'd say if someone successfully enters my account using a password I didn't even specify, it's the fault of the system for letting that person in. If the system had actually made sure the password entered wasn't too long the user would have still been locked out.

     If the user had successfully guessed 'antidise' then I can at least rationalize that the user successfully guessed my password, in which case I'd wonder if the system had adequettely detected a brute force attack... but that is far less of a WTF than if a user gained access using a password I haven't even specified.

    I don't understand your logic in saying 'what does it matter, they're in anyway'... using that logic, if someone dies of a heart attack because an ambulance failed to respond in time because someone was too busy munching on a sandwich, "what does it matter, the guy died anyway" There are assumptions I make in how someone secures my account, and one of them is "There is one, and only one password with which one can access my account"

    Your continued insistence that it is less secure to accept an arbitrary-length password with the same 8-character prefix as your password instead of your exact password makes me think you still aren't getting this.  Yes, it's stupid that it does that.  It's certainly a bug, because the entered password should never be truncated before being hashed.  And by the way, that is the problem here, they are truncating everything to 8 characters.  Your suggestion to compare the lengths first is not only a tad convoluted, it is less secure than what they are already doing.  That's because the only way to do that would be to store the plaintext password or to store its length.  The first is obviously stupid and the second makes it much easier to brute-force your password if someone obtains the password database.

     

    Once again, this is a bug and it is stupid on their part, but it is no less secure than only accepting your exact password.  The biggest security flaw that is evident is limiting users to 8-character passwords. 



  •  TRWTF is storing passwords in plaintext.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.