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.



  • @Heron said:

    TRWTF is storing passwords in plaintext.

    Where did you get that from?  I suppose it's quite possible, given how often it occurs and the fact that the developers in this case didn't seem to bright.  Still, there's nothing in the OP I can see that indicates the passwords are stored in plaintext.  I'd prefer to at least assume the developers are moderately incompetent until proven criminally so.



  • @Heron said:

     TRWTF is storing passwords in plaintext.

    Agreed, but what makes you think this is happening in this case? As was mentioned, they're more likely using a DES version of crypt, which truncates to 8 characters.



  • @morbiuswilters said:


    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. 

    I concur that limiting passwords to 8 characters is a larger security issue. Perhaps this issue should be dealt with instead of the wtf I focused on. I still disagree when you say the truncation method [b]no[/b] less secure, though. Wouldn't you agree that there is at least a negligible increased chance someone could gain access to an account with a 10-character password that simply starts with the correct 8-character password without first trying the 8-character password?



  • @RHuckster said:

    Wouldn't you agree that there is at least a negligible increased chance someone could gain access to an account with a 10-character password that simply starts with the correct 8-character password without first trying the 8-character password?

    Why would it be? As the number of characters increases, there's no change in the odds that any given password will be accepted. Let's assume they accept on a-zA-Z0-9. That's 62 characters, so there's a 1 in 62^8 chance of randomly selecting the right password. If you look at the 9-character long space, you get a 62 in 62^9 chance of hitting on the password, which is still 1 in 62^8. Keep going, you'll always find the same results. Now, obviously I'm ignoring some edge cases and assuming that the person breaking in is working randomly (which is highly unlikely), but none of them really damage the security.



  • @RHuckster said:

    Wouldn't you agree that there is at least a negligible increased chance someone could gain access to an account with a 10-character password that simply starts with the correct 8-character password without first trying the 8-character password?

    It's certainly possible for someone to try a 10-character password and get in.  If we're talking about brute-forcing, though, the chances of generating an 8-character password and a 10-character password with the same prefix are the same.  Of course, nobody would start brute-forcing at 10 characters, especially if they know the maximum allowed is 8.  And even if they did start brute-forcing at 10 characters for some odd reason, they are still really only guess 8-character passwords.  Everything else is discarded and all that matters is the first 8 characters.  It does not decrease the security from a brute-forcing perspective.  Still, I agree that overall the security of the system is pathetic, especially if they are using crypt() as has been suggested.  Don't think I'm saying "none of this is a WTF" and I'm not mugging you, I'm just letting you know where the real security problems are.



  • @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
     

    Well, what if the attacker manages to find something that ISN'T your password, but hashes to the same thing? Collisions in hash tables do happen, you know. It's relatively trivial to take two files and make then hash to the same MD5 these days.

    Face it, you're arguing a dumb point. Whether they get into your account with 'antidise' or 'antidesestablishmentarianism' all comes down to the same thing: They're IN YUR ACCOUNT, CASHING YUR STOCKZ. If their password generator/mangler was stupid and didn't test the same prefix in sequence, then all it did was take them a bit longer to find a particular password that has the same first 8 characters as the "real" password.

    If they tested "abc", then "def", then "ghi" before testing "abc1" and "abc2" and "abc3", then yeah, it might take them a bit longer to realize your password is "jkl". But a sane pw mangler will take a given root password and try a few prefixes and suffixes before moving on to the next root password. "abc" "1abc" and "abc1" then "def" and "1def" and "def2" etc...



  • @RHuckster said:

    Wouldn't you agree that there is at least a negligible increased chance someone could gain access to an account with a 10-character password that simply starts with the correct 8-character password without first trying the 8-character password?
     

    Do you think that if the website didn't mention the 8-character limit the security would be beter?

    Security doesn't work by assuming crackers are dumb.



  • I think technically, if you checked a ten digit possible password, where the last two digits were effectively \0\0 (ie blank) and the first eight your pass, a 'random ten digit attack' would only work if both the first eight digits were your 8 digit pass, and the last two digits were 'blank' whereas this system would log someone in if the first eight were correct, regardless of what the last two were.  (I could be wrong, but I am pretty sure that's correct)

    However, no brute force attack would try to crack a password this way:  They'd start with the shorted possible string, and add a character upon reaching the max combinations for the current string, leading to an eight character password getting cracked at the same rate regardless of whether or not they truncate the password before verifying it.  Maybe a dictionary attack would try longer words intermixed with shorter ones, and hit a ten character word that matched a 8 character pass that would not otherwise authenticate, but that would be pretty retarded of the attacker not to take into account the stated max characters for passwords right on their site. 

    I think the additional vulnerability impact is exceptionally low however.

    The next question of course, is if they do stuff as sloppy as this, if they even bother to take note of attempted brute force attacks - which I certainly hope they do*

     

    *and better than my bank, which shuts down ALL internet access to my account after a number of fails instead of just by IP (and we are not even talking about a range of IPs with failed attempts) making DOSing my internet banking really easy.  I have to call them up after 3 fails and give them my uh, name only, to get it back online, and of course, they use JS page forwarding on the login page, so simply hitting the Back Button to get back to re-enter my username/pass can cause re-offending fails in a hurry.  Oh, and its all in Coldfusion.  But then my ISP sends me my Credit Card info (after collecting via HTTPS) in an email as a reciept, plaintext, full number, exp date and number on the back... so I am pretty sure I just live in Wtfville.



  • @zzo38 said:

    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.

    I think it's time for little Bobby Tables to sign up at this site.



  • @bstorer said:

    @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.

    Actually gg0, gg and g would log in as the first student in the system. They don't store old users (or well they do but that's another story ;))



  • So here's another really stupid reason not to accept anything not exactly like what you make your password: writing it down



    I know most attempts to crack an account doesn't involve finding a note with the password scribbled on it BUT consider this:



    You have lots of accounts on different sites using different passwords on each of them and you have some trouble remembering all of them, you decide it's not that bad if you write them all down, as long as you write down the wrong things. After all, only the exact passwords would grant access. So instead of writing "TD Charles Morgan. - Fluffy33" you'd just write "TD Charles Morgan. - Fluffy33Yffulf". Someone reading the note would assume the password is Fluffy33Yffulf and get the password very wrong.



    But then comes along this one site where the rules of reality are bent to make perogramming a little easier, if you enter a password longer than the original, but starting with the original then you still get logged in. The person writing Fluffy33Yffulf will get logged in...



    Obvioulsy writing your password down is always a bad idea but some people can't keep them all in their head, it's like my dad who has too many creditcards and can't remember the PINs so he'd have to write them down (he doesn't because he's too paranoid someone would use his cards, he'd rather not use them himself)



    I'm still bummed the story wasn't about some site automatically shutting everyone out after 8 attempts of cracking it...



  • @tamm said:

    You have lots of accounts on different sites using different passwords on each of them and you have some trouble remembering all of them, you decide it's not that bad if you write them all down, as long as you write down the wrong things. After all, only the exact passwords would grant access. So instead of writing "TD Charles Morgan. - Fluffy33" you'd just write "TD Charles Morgan. - Fluffy33Yffulf". Someone reading the note would assume the password is Fluffy33Yffulf and get the password very wrong.
    This is worse than Swampy's "store important info at the end of a large text document" security system.



  • @bstorer said:

    @tamm said:
    You have lots of accounts on different sites using different passwords on each of them and you have some trouble remembering all of them, you decide it's not that bad if you write them all down, as long as you write down the wrong things. After all, only the exact passwords would grant access. So instead of writing "TD Charles Morgan. - Fluffy33" you'd just write "TD Charles Morgan. - Fluffy33Yffulf". Someone reading the note would assume the password is Fluffy33Yffulf and get the password very wrong.
    This is worse than Swampy's "store important info at the end of a large text document" security system.

    Seriously.  How many convoluted scenarios are people going to invent to try and prove me wrong?  If you are writing your passwords down you are a douchebag and deserve to have every penny stolen from your checking account, your stock portfolio invested entirely in Web 2.0 startups that have no revenue stream, your house auctioned on eBay and those personal videos of you and your wife published on Youtube.



  • @tamm said:

    You have lots of accounts on different sites using different passwords on each of them and you have some trouble remembering all of them, you decide it's not that bad if you write them all down, as long as you write down the wrong things.
     

    Why bother? There's plenty of great software out there to let you securely record your passwords. I use Passwordsafe a lot. Small, secure (originally written by Bruce Schneier) and able to run off a usb key with versions available for all major OSes. 

    About the only time writing a PW down is "safe" is when it's stored in the bottom of a
    locked filing cabinet stuck in a disused lavatory with a sign on the
    door saying "Beware of The Leopard".



  • @MarcB said:

    with a sign on the
    door saying "Beware of The Leopard".
     

    Unless Lingerance is around. He would be all over your leopard.



  • @MarcB said:

    About the only time writing a PW down is "safe" is when it's stored in the bottom of a
    locked filing cabinet stuck in a disused lavatory with a sign on the
    door saying "Beware of The Leopard".
    It's more secure if you actually have the leopard.



  • You know, if they'd claimed the password had to be at least 12 characters but only authenticated from the first 8 I could kind of understand the reasoning, though I'm not sure I would have done it that way myself.



  • @bstorer said:

    As was mentioned, they're more likely using a DES version of crypt, which truncates to 8 characters.
    Ugh. I distinctly remember once using some weird "homebrewed" version of crypt that truncates the "password" to 7 characters. TRWTF is that there are lots of people still using DES-based stuff for real-life encryption (no, I do not trust 3DES!)

    Lots of the old school unices use crypt(), and I distinctly remember having some trouble with RACF on OS/390 not supporting > 8-character passwords. Sure you could type in more than 8 chars in the ISPF "change password" screen, but you couldn't type more than 8-char passwords in the actual password "login screen" field. That makes me think there was something wrong in the "new password" field validation rules.

    Though I can give them credit, as I vaguely remember that RACF did reject invalid passwords over 8 chars long, so "12345678" would pass, but "123456789" wouldn't.

    @MarcB said:

    About the only time writing a PW down is "safe" is when it's stored in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard".

    Unless Bruce Schneier is the one after your password.



  •  As someone else said, the only WTF is that may give you a wrong sense of security. You'd assume a password like "password123!$%" is pretty secure, when in fact it's not if you trim it after 8 characters.



  • @danixdefcon5 said:

    Unless Bruce Schneier is the one after your password.
     

    Doesn't matter, Bruce Schneier already has my key.



  •  regardless of length, passwords that are written on a post-it note on a monitor are unsecure. the longer the length, the higher the chance that post-it note exists.



  • Such a limitation may not matter for bruto force attacks, but the problem are dictionary attacks.

    The probability that a word out of a word list matches the passwod is higher, when only the beginning matters,
    because people tend to add difficult characters at the end of word.

    So the a system silently truncating passwords is less secure than one than one with arbitrary long passwords or on warning about truncations.
    (perhaps it doesn't matter for the complex passwords of 1337 hackerz, but for the ones of normal people)



  • @bugmenot1 said:

    Such a limitation may not matter for bruto force attacks, but the problem are dictionary attacks.

    The probability that a word out of a word list matches the passwod is higher, when only the beginning matters,
    because people tend to add difficult characters at the end of word.

    So the a system silently truncating passwords is less secure than one than one with arbitrary long passwords or on warning about truncations.
    (perhaps it doesn't matter for the complex passwords of 1337 hackerz, but for the ones of normal people)

    You just didn't read this at all, did you?  It truncates the password when you attempt to login, not when you enter it the first time.  So what you are saying makes no sense at all.  The difficult characters could only be added by someone guessing the password, they wouldn't actually be part of someone's real password.  FFS, people, you're not going to win this one.  I am the victor and to me go the spoils.  Let it the fuck go. 



  • @morbiuswilters said:

    @bugmenot1 said:

    Such a limitation may not matter for bruto force attacks, but the problem are dictionary attacks.

    The probability that a word out of a word list matches the passwod is higher, when only the beginning matters,
    because people tend to add difficult characters at the end of word.

    So the a system silently truncating passwords is less secure than one than one with arbitrary long passwords or on warning about truncations.
    (perhaps it doesn't matter for the complex passwords of 1337 hackerz, but for the ones of normal people)

    You just didn't read this at all, did you?  It truncates the password when you attempt to login, not when you enter it the first time.  So what you are saying makes no sense at all.  The difficult characters could only be added by someone guessing the password, they wouldn't actually be part of someone's real password.  FFS, people, you're not going to win this one.  I am the victor and to me go the spoils.  Let it the fuck go. 

     

    Correct me if I am wrong, but isn't that the point?  When I set a password for a system, I have an expectation that the password I gave is the one being hashed.  It appears that the OP's system is silently truncating the given password to 8 characters, both at logins and when the user sets their password.  Because many users will put complex characters at the end of their password, they may be left with a weaker password than they expect, and never know.

    You can certainly have a decent 8-letter password that is better than a weak 10-character password, but I don't think that is what is being argued here.



  • Speaking to the 8 character thing - its a known Apache Basic Authentication, which uses (on UNIX) the crypt() function. This, if actually being used on a financial site is a huge WTF. The only way around is use the MD5 encryption options (which adds a salt string), or use a real db backend or some other 'proper' authentication source.

     Look under security considerations in the Apache htpasswd man page (here's one)



  • @WeatherGod said:

    It appears that the OP's system is silently truncating the given password to 8 characters, both at logins and when the user sets their password.

    Learn to read.  The OP never said that this was happening, he explicitly said passwords were required to be between 6 and 8 characters.  I'm not saying that the password isn't being truncated on setting it, but there is nothing in the OP to indicate that is the case.  Additionally, if the site tells you your password must be between 6 to 8 characters, then entering more than 8 characters and expecting them to be used is pretty stupid.  I've already said the whole system is a WTF, but truncating the passwords on login does not make the system less secure no matter how much everyone seems to believe that.



  • @morbiuswilters said:

    @WeatherGod said:

    It appears that the OP's system is silently truncating the given password to 8 characters, both at logins and when the user sets their password.

    Learn to read.  The OP never said that this was happening, he explicitly said passwords were required to be between 6 and 8 characters.  I'm not saying that the password isn't being truncated on setting it, but there is nothing in the OP to indicate that is the case.  Additionally, if the site tells you your password must be between 6 to 8 characters, then entering more than 8 characters and expecting them to be used is pretty stupid.  I've already said the whole system is a WTF, but truncating the passwords on login does not make the system less secure no matter how much everyone seems to believe that.

    Ok, consider a system that is not truncating passwords to 8 characters for hashing when setting, and a person sets a password longer than 8 characters, then how can the system validate any of his logins if at login they are truncating the password to 8 characters?  The hash for the first 8 characters should be entirely different from the hash generated from the original password.  Therefore, the system must be truncating the passwords when the user sets the password.

    As for entering a longer password when the system tells you that the limit is 8 characters, the WTF is that the system did not enforce that limitation explicitly.  It should have told him that the password was invalid and to try another.  I once, accidentially, tried to set a password that was too long for a particular website, and it told me to try another.  I certainly believe that a shorter password can be as secure as a longer password, but I wouldn't want my password to be shorter than I thought it would be.  Wasn't that the whole issue behind the Unix crypt() function? 



  • @WeatherGod said:

    Ok, consider a system that is not truncating passwords to 8 characters for hashing when setting, and a person sets a password longer than 8 characters, then how can the system validate any of his logins if at login they are truncating the password to 8 characters? 
    I had assumed that the system restricted the size (likely on the front-end) when creating an account, but didn't bother to do it when signing in.



  • @bstorer said:

    @WeatherGod said:
    Ok, consider a system that is not truncating passwords to 8 characters for hashing when setting, and a person sets a password longer than 8 characters, then how can the system validate any of his logins if at login they are truncating the password to 8 characters? 
    I had assumed that the system restricted the size (likely on the front-end) when creating an account, but didn't bother to do it when signing in.

    It's an assumption but probably correct given what we've been told by the OP.  Also, if it says the password is limited to 8 characters and you enter 9 and expect the last character to be used, you are an idiot. 



  • @bstorer said:

    @WeatherGod said:
    Ok, consider a system that is not truncating passwords to 8 characters for hashing when setting, and a person sets a password longer than 8 characters, then how can the system validate any of his logins if at login they are truncating the password to 8 characters? 
    I had assumed that the system restricted the size (likely on the front-end) when creating an account, but didn't bother to do it when signing in.

    I don't see how that would work, either.  The user said that when logging in, he could enter any password, so long as the first 8 characters were correct.  Therefore, at the login step, the system is only hashing the first 8 characters (either by explicitly truncating the string, or by use of something like the crypt() function).  That hash must match whatever hash was stored for the account creation.

    Now, the real WTF would be if the system wasn't even hashing at all and just stored the passwords plaintext and compared the first eight characters.  But no financial institution would do that... would they? 


Log in to reply
 

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