Password WTF



  • This has been bugging me for a while so I thought I should post it and just accept the "Not a real WTF" comments I am sure to receive.

    So we use a certain project tracking tool where I work and during a recent audit it was suggested that more strict password reqirements be put in place.

    "I don't need to worry", I thought, "I have a good password: 10 characters long, lower and upper case letters, special symbols, and numbers..."

    My old password turned out in fact to be TOO good. The new "strict" requirements mandated that the password could be no more than 8 characters long. As a result the "improvement in security" I had to come up with a less secure password to access this application and since there is no "remember me" feature I am reminded of this story every time I log in.



  • Maybe the system only stores the 8 leftmost characters of the password anyway, so longer password create a false impression of security, while it might be actually easier to guess since many people add the hard-to-guess characters at the end of the password. (e.g. "ThatWasEasy53%")



  • It could be worse. You could work for a bank.

     

    You don't work for a bank, right?



  • @Siloria said:

    This has been bugging me for a while so I thought I should post it and just accept the "Not a real WTF" comments I am sure to receive.

    So we use a certain project tracking tool where I work and during a recent audit it was suggested that more strict password reqirements be put in place.

    "I don't need to worry", I thought, "I have a good password: 10 characters long, lower and upper case letters, special symbols, and numbers..."

    My old password turned out in fact to be TOO good. The new "strict" requirements mandated that the password could be no more than 8 characters long. As a result the "improvement in security" I had to come up with a less secure password to access this application and since there is no "remember me" feature I am reminded of this story every time I log in.

    Actually sounds like a pretty decent WTF...

    +2 for using my </RandomRant> tag too. Glad to see it get some mileage.



  • Yes, I've always disliked maximum password lengths. Or other silly password restrictions. LIke I've had some say "Nothing except letters." No that's it. Just letters. Well gee thanks so much for litting me pick a secure password. Oh well, good thing it wasn't for something important.

    I think I can see why they do this though: I once had a stupidly long password, and it was just so completely pointlessly long it wasn't funny, in that it was not so much a password as a passphrase... So extremes can be annoying to some people (particularly once I was asked why the heck I needed such a longass password) so people think "maximum password length == people don't type shakespeare in the password box and take up my bandwidth" ( .... and if they don't use a hash (like they should be), "database space" might be there too. Bandwidth problem gets worse if the password is cookied.)



  • @MasterPlanSoftware said:

    Actually sounds like a pretty decent WTF...

    I'll second that but I'll augment it and say this is a REAL WTF. An incredibly stupid one. There is absolutely valid reason to put such a short limit on the length of the password. For text data like this, memory and bandwidth are essentially free, and the user should be able to choose to have as complex a password as possible.

    Any limit short of 16 characters is unreasonable. 



  • @Brendan Kidwell said:

    There is absolutely valid reason to put such a short limit on the length of the password.

    There is absolutely no valid reason to put such a short limit on the length of the password.

    Sigh... Sorry. 



  • Or on the characters to use. If I want to use control characters for my password, I should be able to, damn it!

    A while ago my main password used to be "; DROP DATABASE;-- in lots of places, until it actually crashed a website on registration. Oops!



  • Yeah, because that is only slightly evil.



  • @Sunstorm said:

    Or on the characters to use. If I want to use control characters for my password, I should be able to, damn it!

    A while ago my main password used to be "; DROP DATABASE;-- in lots of places, until it actually crashed a website on registration. Oops!

    Which website was that? Hopefully not a bank... :)



  • Talk of banks has reminded me...will post a new topic for it.



  • I had one case where a site (I believe it was my cell provider) would allow you to set a longer password, but when you would try to log in later, it would cut you off at 8.  Even so, if you set a >8 character password, it would check that against the 8 it allowed you to type at the start and... lock you out.

     



  • Arbitrary password limits make me want to avoid a system not because the passwords are less secure, but because such a brain-dead WTF is a clear indicator that the designers of the system have not a single clue what they are doing.  No good/sane developer can put such a limit in place.  It's pretty much safe to assume that, when such a thing exists, your password is stored in plain text in an Excel file on a shared folder with full permissions to everybody on a machine directly connected to the internet.



  • @djork said:

    Arbitrary password limits make me want to avoid a system not because the passwords are less secure, but because such a brain-dead WTF is a clear indicator that the designers of the system have not a single clue what they are doing.  No good/sane developer can put such a limit in place.  It's pretty much safe to assume that, when such a thing exists, your password is stored in plain text in an Excel file on a shared folder with full permissions to everybody on a machine directly connected to the internet.

    Ancient UNIX systems stored passwords with a one-way hashing algorithm that only operated on eight characters.



  • @Random832 said:

    @djork said:
    Arbitrary password limits make me want to avoid a system not because the passwords are less secure, but because such a brain-dead WTF is a clear indicator that the designers of the system have not a single clue what they are doing.  No good/sane developer can put such a limit in place.  It's pretty much safe to assume that, when such a thing exists, your password is stored in plain text in an Excel file on a shared folder with full permissions to everybody on a machine directly connected to the internet.

    Ancient UNIX systems stored passwords with a one-way hashing algorithm that only operated on eight characters.

    Yes.  But now a run-of-the-mill desktop computer is 1000 times more powerful than a desktop from 2 decades ago.  There's no excuse anymore.



  • @Random832 said:

    @djork said:
    Arbitrary password limits make me want to avoid a system not because the passwords are less secure, but because such a brain-dead WTF is a clear indicator that the designers of the system have not a single clue what they are doing.  No good/sane developer can put such a limit in place.  It's pretty much safe to assume that, when such a thing exists, your password is stored in plain text in an Excel file on a shared folder with full permissions to everybody on a machine directly connected to the internet.

    Ancient UNIX systems stored passwords with a one-way hashing algorithm that only operated on eight characters.

    Because they pre-date the invention of secure hash algorithms, so had to abuse DES for the purpose - an algorithm with a 56-bit key can accept exactly 8 7-bit values into the key, which is then used to encrypt a known value (all zeros). Practical cryptographic hashes date from about 1989-1990, with the creation of MD2 and MD4, while unix dates from 1969. The crude DES method was abandoned shortly after MD5 became available.



  • @Siloria said:

    The new "strict" requirements mandated that the password could be no more than 8 characters long.

     

    Looks like a simple DES password algorithm is used for hashing, like on some configurations of HP-UX (which can be cracked as such a lightning speed :D) 



  • No, I don't work at a bank, although my previous job was for a company that wrote a lot of the awful software Banks use.

    Another utility here allows valid passwords to only consist of consonants.

    No evil vowels, numbers, or symbols are allowed for that one.

     



  • @Critter said:

    I had one case where a site (I believe it was my cell provider) would allow you to set a longer password, but when you would try to log in later, it would cut you off at 8.  Even so, if you set a >8 character password, it would check that against the 8 it allowed you to type at the start and... lock you out.

    If you're thinking of Cingular, circa 6 years ago, it was FOUR characters. I distinctly remember storing a password, failing to log in, and then after a tech support call, retrieved it from the agent over the phone (WTF? retrievable passwords) as a four-character value.

    FOUR! And it was truncated during storage, but not during checking, as you said. I was speechless.



  • @asuffield said:

    Because they pre-date the invention of secure hash algorithms, so had to abuse DES for the purpose - an algorithm with a 56-bit key can accept exactly 8 7-bit values into the key, which is then used to encrypt a known value (all zeros). Practical cryptographic hashes date from about 1989-1990, with the creation of MD2 and MD4, while unix dates from 1969. The crude DES method was abandoned shortly after MD5 became available.

    And as we all know, MD5 has been cracked.  I can't think of a way that it would affect a well-designed webapp, though.  An attacker would have to acquire the hash he needed to crack in order to create a collision.  Once he got that hash, though, he could create a collision in less time than it takes to blink. 



  • @belgariontheking said:

    @asuffield said:

    Because they pre-date the invention of secure hash algorithms, so had to abuse DES for the purpose - an algorithm with a 56-bit key can accept exactly 8 7-bit values into the key, which is then used to encrypt a known value (all zeros). Practical cryptographic hashes date from about 1989-1990, with the creation of MD2 and MD4, while unix dates from 1969. The crude DES method was abandoned shortly after MD5 became available.

    And as we all know, MD5 has been cracked.  I can't think of a way that it would affect a well-designed webapp, though.  An attacker would have to acquire the hash he needed to crack in order to create a collision.  Once he got that hash, though, he could create a collision in less time than it takes to blink. 

    The brokenness of MD5 is exaggerated by security nuts.

    Any hash that has n possible values encounters nothing but collisions after n runs of unique values.  It's simple pigeonholing.  Where MD5 is broken, there are more collisions than there should be... but it's still totally appropriate to store passwords with uniquely salted MD5 hashes, and numerous other uses.  Practical attacks using MD5 collisions are extremely unlikely.



  • @djork said:

    @belgariontheking said:
    @asuffield said:

    Because they pre-date the invention of secure hash algorithms, so had to abuse DES for the purpose - an algorithm with a 56-bit key can accept exactly 8 7-bit values into the key, which is then used to encrypt a known value (all zeros). Practical cryptographic hashes date from about 1989-1990, with the creation of MD2 and MD4, while unix dates from 1969. The crude DES method was abandoned shortly after MD5 became available.

    And as we all know, MD5 has been cracked.  I can't think of a way that it would affect a well-designed webapp, though.  An attacker would have to acquire the hash he needed to crack in order to create a collision.  Once he got that hash, though, he could create a collision in less time than it takes to blink. 

    The brokenness of MD5 is exaggerated by security nuts.

    Any hash that has n possible values encounters nothing but collisions after n runs of unique values.

    I got the impression, from reading about this, that the specific problem with MD5 is that for any three strings A, B, and C - if A and B have the same hash, AC and BC (concatenated) also have the same hash, which NOT an inherent property of hashing algorithms. Which (if it's true - was i mistaken?) means you just have to e.g. make a payload that collides with the empty string, and you can put the file you want to collide with on the end that payload. Obviously, more of a file verification problem than a password authentication problem.



  • @Random832 said:

    you just have to e.g. make a payload that collides with the empty string

    Sounds easy.  Let me know when you're done!  ;) 



  • @Siloria said:

    This has been bugging me for a while so I thought I should post it and just accept the "Not a real WTF" comments I am sure to receive.

    So we use a certain project tracking tool where I work and during a recent audit it was suggested that more strict password reqirements be put in place.

    "I don't need to worry", I thought, "I have a good password: 10 characters long, lower and upper case letters, special symbols, and numbers..."

    My old password turned out in fact to be TOO good. The new "strict" requirements mandated that the password could be no more than 8 characters long. As a result the "improvement in security" I had to come up with a less secure password to access this application and since there is no "remember me" feature I am reminded of this story every time I log in.

    Sorry.  I couldn't help it.  Here's hoping userfriendly doesn't do referrer filtering.



  • I'm reminded of the method Lunarpages uses to expire passwords. You're forced to change your password every 3 months, but only if you actually log in to your client control panel. I feel my password is secure enough, so I've avoided logging in for 9 months now. I'm going to keep avoiding it like the plague until I'm forced to in order to make a payment.



  • I bet money that some dude put a < instead of > when defining the password rule :P



  • @belgariontheking said:

    @asuffield said:

    Because they pre-date the invention of secure hash algorithms, so had to abuse DES for the purpose - an algorithm with a 56-bit key can accept exactly 8 7-bit values into the key, which is then used to encrypt a known value (all zeros). Practical cryptographic hashes date from about 1989-1990, with the creation of MD2 and MD4, while unix dates from 1969. The crude DES method was abandoned shortly after MD5 became available.

    And as we all know, MD5 has been cracked.  I can't think of a way that it would affect a well-designed webapp, though.  An attacker would have to acquire the hash he needed to crack in order to create a collision.  Once he got that hash, though, he could create a collision in less time than it takes to blink. 

    What you're describing is a preimage attack, and nobody's yet found one of those for MD5. The attacks on MD5 are collision attacks, where you can quickly generate pairs of inputs that produce the same MD5 hash. Collision attacks can be used to subvert digital signatures, but they're useless for attacking checksums or hashed passwords.



  • @Carnildo said:

    @belgariontheking said:
    @asuffield said:

    Because they pre-date the invention of secure hash algorithms, so had to abuse DES for the purpose - an algorithm with a 56-bit key can accept exactly 8 7-bit values into the key, which is then used to encrypt a known value (all zeros). Practical cryptographic hashes date from about 1989-1990, with the creation of MD2 and MD4, while unix dates from 1969. The crude DES method was abandoned shortly after MD5 became available.

    And as we all know, MD5 has been cracked.  I can't think of a way that it would affect a well-designed webapp, though.  An attacker would have to acquire the hash he needed to crack in order to create a collision.  Once he got that hash, though, he could create a collision in less time than it takes to blink. 

    What you're describing is a preimage attack, and nobody's yet found one of those for MD5. The attacks on MD5 are collision attacks, where you can quickly generate pairs of inputs that produce the same MD5 hash. Collision attacks can be used to subvert digital signatures, but they're useless for attacking checksums or hashed passwords.

    And the collision is not even against the variant of MD5 used in unix password digests (which is actually not the same as the one used to hash messages). The MD5 password digest is far harder to crack than the normal MD5 algorithm (it involves many repeated iterations of the basic MD5 transformation). It is not practical to use an attack of that form against it. The rainbow table method does work, but is of little value with a properly salted password; it's only really effective for the crude unsalted variation used by Windows (and php idiots who think that the md5 function is for passwords - use crypt(), not md5(), you fucktards).

    (We don't use the harder variant of MD5 for normal message hashing because it would be far too slow; it works for passwords because they're only a few bytes long)



  • I'm more of a Perl idiot but the two functions look pretty similar and I've always heard to avoid crypt(), and looking at [url=http://www.php.net/manual/en/function.crypt.php]PHP's version[/url] I see that it limits the salt and only uses the first part of the string.



  • @Cap'n Steve said:

    I'm more of a Perl idiot but the two functions look pretty similar and I've always heard to avoid crypt(), and looking at [url=http://www.php.net/manual/en/function.crypt.php]PHP's version[/url] I see that it limits the salt and only uses the first part of the string.

    Only if you use the DES mode. Don't do that. Use the MD5 or blowfish modes. Do not avoid crypt().
     


Log in to reply