Another password field



  • 8-13 characters.
    Must start with a letter.

    I still don't understand why so many sites put such terrible limits on passwords, like a maximum length or what kind of character it should start with.

     

     

    Edit: apparently the "maxlength" of the input box is 21, while the maximum password length is 13. Only god knows why.

    It also checks whether the password you enter is "strong" but it labels seemingly random sequences as medium and anything "too long" (>13) or with "invalid characters" (<, !, $, #, etc) is "weak".


  • Discourse touched me in a no-no place

    Does it accept apostrophes? And semicolons?



  • @PJH said:

    Does it accept apostrophes? And semicolons?
     

    Just what are you implying?



  • @pbean said:

    I still don't understand why so many sites put such terrible limits on passwords, like a maximum length or what kind of character it should start with.

     

    I can tell you exactly why: because they store the password plaintext and the database password field is set to N characters long, so thus the limit. If they were using a hash of some sort, they could just set the password field length to the hash length and any password will fit. I typically try extremely hard to avoid places that use that method.

    The last place I worked had some user benefits page that had this requirement, and I complained to them about it. They were astonished I had "hacked" into their page to find out this information, and then informed me that they use the latest security practices. I kept informing them that they weren't, but they wouldn't have any of it. Eventually I got out of them that they store the passwords plaintext so that when idiot users forget their password, they can just tell them, instead of having to do something like "we've e-mailed you a new random password" so I set my password to "cuntcuntcunt" (12 characters max, no punctuation) and then 'forgot' my password and had someone read that to me on the phone. It was great, I think I as laughing so hard and I managed to squeak out "hahaha, can you say that again? hahahahaha".


  • Discourse touched me in a no-no place

    @EJ_ said:

    Eventually I got out of them that they store the passwords plaintext so that when idiot users forget their password, they can just tell them, instead of having to do something like "we've e-mailed you a new random password" so I set my password to "cuntcuntcunt" (12 characters max, no punctuation)
    Mentioned on here before, and while not strictly speaking a 'password' in this sense: http://news.bbc.co.uk/1/hi/england/shropshire/7585098.stm:

    A man who chose "Lloyds [a UK bank] is pants" as his telephone banking password said he found it had been changed by a member of staff to "no it's not".
    [...]
    "The rules seemed to change, and they told me it had to be one word, so I tried 'censorship', but they didn't like that, and then said it had to be no more than six letters long."


  • @PJH said:

    "The rules seemed to change, and they told me it had to be one word, so I tried 'censorship', but they didn't like that, and then said it had to be no more than six letters long."

    I wonder if he then tried 'twats?' That's what I would have done next. :)



  • @EJ_ said:

    I can tell you exactly why: because they store the password plaintext and the database password field is set to N characters long, so thus the limit. If they were using a hash of some sort, they could just set the password field length to the hash length and any password will fit. I typically try extremely hard to avoid places that use that method.

    Oh God, not this again.  Message digest hash functions are only slightly more secure than plaintext (unless your password hashing library (you are using a library aren't you, instead of just rolling your own?) utilizes key stretching).  The best password hashing methods use cryptographic functions with an expensive key schedule (e.g. bcrypt) and they do have a maximum length because there's a maximum length of the key (although it's a lot longer than 13 characters and the maximum length is extremely secure).

     

    Of course, I'm not implying that's what they're doing here.  What interests me more is the "must start with a letter" condition.  Perhaps they're using a language with type coercion and had problems with passwords being converted to ints unless there was a letter at the beginning?



  • @morbiuswilters said:

    What interests me more is the "must start with a letter" condition.  Perhaps they're using a language with type coercion and had problems with passwords being converted to ints unless there was a letter at the beginning?
     

    I am unwilling to invest time in coming up with a code situation where such a thing would occur.



  • @dhromed said:

    @morbiuswilters said:
    What interests me more is the "must start with a letter" condition.  Perhaps they're using a language with type coercion and had problems with passwords being converted to ints unless there was a letter at the beginning?
     

    I am unwilling to invest time in coming up with a code situation where such a thing would occur.

    It's not too far fetched a scenario.  I was working with an integrated scripting language just the other week.  Whenever you'd print out a value composed only of digits, it would coerce it into a real number before passing it up to the compiled language.  This would then print the value as a float, and as such the default format would add a ".0" to the end.  So "123" was printed as "123.0", but "a123" would stay "a123".



  • @morbiuswilters said:

    @EJ_ said:

    I can tell you exactly why: because they store the password plaintext and the database password field is set to N characters long, so thus the limit. If they were using a hash of some sort, they could just set the password field length to the hash length and any password will fit. I typically try extremely hard to avoid places that use that method.

    Oh God, not this again.  Message digest hash functions are only slightly more secure than plaintext (unless your password hashing library (you are using a library aren't you, instead of just rolling your own?) utilizes key stretching).  The best password hashing methods use cryptographic functions with an expensive key schedule (e.g. bcrypt) and they do have a maximum length because there's a maximum length of the key (although it's a lot longer than 13 characters and the maximum length is extremely secure)

     

    Slightly more secure than plaintext? You mean that when you see a salted hash of a password you can almost immediately tell what the password is? :P



  • @pbean said:

    Slightly more secure than plaintext? You mean that when you see a salted hash of a password you can almost immediately tell what the password is? :P

     

    It's like the Matrix...

     "You get used to it. I don't even see the hash. All I see now is 'secret123', 'fido', 'qwerty'..."



  • @pbean said:

    @morbiuswilters said:

    @EJ_ said:

    I can tell you exactly why: because they store the password plaintext and the database password field is set to N characters long, so thus the limit. If they were using a hash of some sort, they could just set the password field length to the hash length and any password will fit. I typically try extremely hard to avoid places that use that method.

    Oh God, not this again.  Message digest hash functions are only slightly more secure than plaintext (unless your password hashing library (you are using a library aren't you, instead of just rolling your own?) utilizes key stretching).  The best password hashing methods use cryptographic functions with an expensive key schedule (e.g. bcrypt) and they do have a maximum length because there's a maximum length of the key (although it's a lot longer than 13 characters and the maximum length is extremely secure)

     

    Slightly more secure than plaintext? You mean that when you see a salted hash of a password you can almost immediately tell what the password is? :P

    You must have missed the part where I mentioned key stretching.  Obviously, salting helps, but using vanilla hash functions (even with salting) still isn't particularly secure.  Besides, a lot of people don't even bother with the salt, they just use hash functions directly.  Obviously, you can't tell just by looking which is why I said "slightly more secure", because it would actually running some dictionary attacks to crack.



  • @morbiuswilters said:

    Oh God, not this again.  Message digest hash functions are only slightly more secure than plaintext

     

    I wasn't talking about security (aside from a quick mention in my second paragraph) I was talking about how the maximum password length indicates that they aren't using even a hash function for security, and how if they had hashed the password they could have a whatever-length password. Slightly more security than none is still security. Your house or car are only slightly more secure having keys than ones without (any crook can be in your house or car within seconds without your key) but you don't see people leaving their doors open saying "fuck it, the lock is only slightly more secure than nothing"

     Also here's an md5: d66d58a3e31e83864ee083054e5d87c3, here's the salt: bua81a. If this is only slightly more security than me giving it to you in plaintext, have at :) (yes I realize that people write things down on sticky notes, intercept the password, etc, but I'm showing you that slight security is still plenty in most cases).



  • @EJ_ said:

    @morbiuswilters said:

    Oh God, not this again.  Message digest hash functions are only slightly more secure than plaintext

     

    I wasn't talking about security (aside from a quick mention in my second paragraph) I was talking about how the maximum password length indicates that they aren't using even a hash function for security, and how if they had hashed the password they could have a whatever-length password. Slightly more security than none is still security. Your house or car are only slightly more secure having keys than ones without (any crook can be in your house or car within seconds without your key) but you don't see people leaving their doors open saying "fuck it, the lock is only slightly more secure than nothing"

     Also here's an md5: d66d58a3e31e83864ee083054e5d87c3, here's the salt: bua81a. If this is only slightly more security than me giving it to you in plaintext, have at :) (yes I realize that people write things down on sticky notes, intercept the password, etc, but I'm showing you that slight security is still plenty in most cases).

    So how are you salting? md5(pwd+salt), md5(md5(pwd)+salt), ...



  • @morbiuswilters said:

    You must have missed the part where I mentioned key stretching.  Obviously, salting helps, but using vanilla hash functions (even with salting) still isn't particularly secure.  Besides, a lot of people don't even bother with the salt, they just use hash functions directly.  Obviously, you can't tell just by looking which is why I said "slightly more secure", because it would actually running some dictionary attacks to crack.
     

    Here's the reality:

    Proper use of hash and salt prevents password discovery for pretty much anybody but the NSA and perhaps a handful of top security researchers in the world (hat color unspecified).  Thus morbiuswilters' comments above could be misleading to many readers.  We shall presume [s]he misspoke.

    [S]he is correct that IMproper use of hash+salt doesn't provide very good protection in case of a hacker with read access to the database (such access is a guiding assumption in design of this kind of security).

    I sure hope nobody reads morbiuswilters' misleading comments above and decides as a result to store plaintext passwords in a database.

    For example, the statement that "it would [take] actually running some dictionary attacks to crack" a hash+salt scheme is simply wrong.  That statement was typed either in ignorance of software security, or perhaps without having had his/her morning coffee.



  • @Tyler said:

     "You get used to it. I don't even see the hash. All I see now is 'secret123', 'fido', 'qwerty'..."
     

    ..."hunter2"



  • @morbiuswilters said:

    @pbean said:

    @morbiuswilters said:

    @EJ_ said:

    I can tell you exactly why: because they store the password plaintext and the database password field is set to N characters long, so thus the limit. If they were using a hash of some sort, they could just set the password field length to the hash length and any password will fit. I typically try extremely hard to avoid places that use that method.

    Oh God, not this again.  Message digest hash functions are only slightly more secure than plaintext (unless your password hashing library (you are using a library aren't you, instead of just rolling your own?) utilizes key stretching).  The best password hashing methods use cryptographic functions with an expensive key schedule (e.g. bcrypt) and they do have a maximum length because there's a maximum length of the key (although it's a lot longer than 13 characters and the maximum length is extremely secure)

     

    Slightly more secure than plaintext? You mean that when you see a salted hash of a password you can almost immediately tell what the password is? :P

    You must have missed the part where I mentioned key stretching.  Obviously, salting helps, but using vanilla hash functions (even with salting) still isn't particularly secure.  Besides, a lot of people don't even bother with the salt, they just use hash functions directly.  Obviously, you can't tell just by looking which is why I said "slightly more secure", because it would actually running some dictionary attacks to crack.

     To be really honest I am really ignorant when it comes to security. I try to use best practices and read up on what is secure and what is not, but the truth is that often I just don't understand it all. The same with "key stretching" which you mentioned. :)

    Anyhow if any form of encryption has a maximum key length, would it be not secure enough to hash the user's password with (for example) SHA1 and then use said hash as the key to that encryption? That way you use the better encryption and don't need to enforce a maximum password length. (Although I'm quite certain that what I suggest is a terrible idea XD)




  • @sidecomment said:

    morbius is wrong
     

    FOOL!

    YOU'VE KILLED US ALL!



  • @pbean said:

    Anyhow if any form of encryption has a maximum key length, would it be not secure enough to hash the user's password with (for example) SHA1 and then use said hash as the key to that encryption? That way you use the better encryption and don't need to enforce a maximum password length. (Although I'm quite certain that what I suggest is a terrible idea XD)
     

    That's a clever idea, but actually, there's no reason to use any two-way encryption algorithm.  You want a one-way hash.  The approach you described isn't salted, and is thus susceptible to a form of dictionary attacks.  For example, if I know that a certain user always uses a password of "123" (which I learned by hacking another less secure website, let's say), and I see what the corresponding hash value is in our database, then suddenly I can identify everybody in the database who has the password "123" no matter how strong the encryption algorithm is.  The use of "salt" prevents that by adding strong uniqueness to each database record.

    The proper way to apply salt (as somebody hinted above) is as follows:

    - Create a unique, (pref. strongly) random salt value for each user record.

    - Store the salt value with the user record.  Shucks, you can post it publicly on the website if you want to.  Privacy is not a huge concern. (Don't take that last part literally, I'm just making the important point that the salt value is not a private key.)

    - Store in your password field the result of: hash(password + salt) -- where "+" is a concatenation operator.  You could also do hash(hash(password) + salt) -- but why do the hash math twice?

    - When a user enters a username and password, use the username to look up the salt value, then repeat the hash(test password + salt), and see if it matches the hash result stored in the user record.

    If you follow the above, you should be in good shape.  However, where people make mistakes is in things like:

    - Concatenating the salt after hashing.  This is bad, because somebody with access to the database can basically pretend the salt isn't there by figuring out he just has to ignore part of the password hash field.

    - Using the same salt for all records.  This is bad, because an somebody can still see who has the same passwords, not to mention construct a dictionary attack specific to a database.

    One of the nice things about the hash+salt scheme when properly implemented is that the output of a particular hash function will have fixed width.  So you could store the hash output as binary data in a database, or base 64 encode it and put it in XML, etc.  The width of a password entered has no relationship to the storage requirement for the hash.  The latter is known and set deterministically.

    And (once again) the hash+salt scheme when properly implemented (i.e. just to be clear, "hash(pw+salt)") is that it is _not_ susceptible to dictionary attacks, which is where morbiuswilters' post was misleading (are we dead yet?).



  • I store my passwords in plaintext just to avoid the obligatory 3-week long rant-fest whenever hashing passwords is discussed on a programming forum.



  • What I love is this...

    Websites asks for your desired password, twice (for verification, since the password is displayed as asterixs)
    It then asks you for a capcha to ensure your not a robot
    You click submit
    It then tells you your username is already in use and if you wish to login you should use the signin form instead of the signup form
    The website then displays all the information you typed in, apart from your password (as that would be insecure, right?)
    After doing the above 5 - 6 times you eventually find a username that isn't taken
    The website emails you your username and password in a plaintext email with the message "Please keep these safe"

    Arggghhh!!! I think I'm going to kill someone! (NOTE: Not really, stay away from that phone.)



  • @sidecomment said:

    Proper use of hash and salt prevents password discovery for pretty much anybody but the NSA and perhaps a handful of top security researchers in the world (hat color unspecified).

    Wrong.

     

    @sidecomment said:

    I sure hope nobody reads morbiuswilters' misleading comments above and decides as a result to store plaintext passwords in a database.

    How in the fuck did you come to that conclusion?  I said plain hash + salt is weak.  The solution isn't to go weaker, it's to go stronger (e.g. key stretching or bcrypt).  This is all irrelevent, though, because nobody should be writing their own fucking password hashing scheme to begin with.

     

    Look, I'll go easy on you because this is your first day: we have this retarded argument every 2 months and it always ends up the same way, with a bunch of whiny, ignorant bitches saying "md5 + salt is good enough" and me slapping their bitch asses down.

     

    @sidecomment said:

    For example, the statement that "it would [take] actually running some dictionary attacks to crack" a hash+salt scheme is simply wrong.  That statement was typed either in ignorance of software security, or perhaps without having had his/her morning coffee.

    A modern GPU-backed brute forcer can try hundreds of millions of MD5 hashes per second.  SHA1 is better, but not by nearly enough.  MD5 and SHA (without key stretching) are too fast; good password hashing requires a very CPU-intensive method.  This is simple shit, man.  This has been the state-of-the-art in password hashing for a decade.  Get with the fucking times.



  • @blakeyrat said:

    I store my passwords in plaintext just to avoid the obligatory 3-week long rant-fest whenever hashing passwords is discussed on a programming forum.

    With the time saved not implementing your own half-baked MD5 or SHA password hashing scheme, you could drink half a beer.  And since that's about how long it would take to brute force those pieces of shit, it's a net win for society if you just drink the beer.



  • @sidecomment said:

    - Store in your password field the result of: hash(password + salt) -- where "+" is a concatenation operator.  You could also do hash(hash(password) + salt) -- but why do the hash math twice?

    Because it is twice as slow.  Or do it a million times.  That's the entire point of a password hash--it shouldn't be fast.

     

    @sidecomment said:

    One of the nice things about the hash+salt scheme when properly implemented is that the output of a particular hash function will have fixed width.  So you could store the hash output as binary data in a database, or base 64 encode it and put it in XML, etc.  The width of a password entered has no relationship to the storage requirement for the hash.  The latter is known and set deterministically.

    NO NO NO NO NO NO.  Goddammit, stop spreading your ignorance.  A fixed-length output is not a benefit.  Especially not compared with the deficiencies of using MD5/SHA or any other hashing algorithm.  Passwords should be hashed with cryptographic ciphers.  Period.  But this is all irrelevent because you should not be writing your own password hashing code.  At all.  Clearly, you are too ignorant.  Download bcrypt and use that.

     

    @sidecomment said:

    And (once again) the hash+salt scheme when properly implemented (i.e. just to be clear, "hash(pw+salt)") is that it is _not_ susceptible to dictionary attacks, which is where morbiuswilters' post was misleading (are we dead yet?).

    NO NO NO NO NO NO NO NO.  Lookup dictionary attack, please.  It is not (necessarily, at least) a pre-computed attack.  The "dictionary" is the list of likely candidate passwords to try.  It can just as easily be run with or without a salt.  Salts are important at defeating pre-computing attacks, but that is not the primary concern when your hashing algorithm can be brute forced at a rate of 500 million hashes a second.  Okay?  In fact, dictionary attacks would be the prime candidate for cracking a password database that used individual salts because rainbow tables would be useless.  "Dictionary attack" and "rainbow table" are not synonymous.



  •  I guess what I should have said then (instead of using the word 'hash') in my orignal comment is:

    I can tell you exactly why: because they store the password plaintext and the database password field is set to N characters long, so thus the limit. If they were using any security of some sort, for example even a weak security method such as a password hash, this wouldn't be an issue. I typically try extremely hard to avoid places that don't even meet those basic qualifications.

     betterer? I wasn't trying to say "hashes R g00d, d00d" I just meant that it's obvious that they're using the "nothing at all" security method and storing it in plaintext. 



  •  Deja vu. :P

    Maybe we should make a web page and put all of this (and possibly previous posts) on there, so the next time we can link to that. XD



  • @EJ_ said:

     betterer? I wasn't trying to say "hashes R g00d, d00d" I just meant that it's obvious that they're using the "nothing at all" security method and storing it in plaintext. 

    That's fine.  I'm not saying plaintext is better than MD5, or that salting isn't important (it is).  It's just that MD5/SHA is shit and to see people still doing md5(salt + password) in the year 2010 kills me inside.  This is supposed to be a site dedicated to doing things the right way.  Encouraging long-obsolete security practices (I know that's not what you were doing, but some people were) is not good.  Even hearing how many people on here have no idea how to hash passwords properly is a bit depressing.  Of course, cryptography is a complex, delicate subject so it's not something most programmers need to know, but so many apparently think they know enough to write their own password hashing schemes instead of using a well-designed, cross-platform library like bcrypt.



  • @morbiuswilters said:

    @blakeyrat said:

    I store my passwords in plaintext just to avoid the obligatory 3-week long rant-fest whenever hashing passwords is discussed on a programming forum.

    With the time saved not implementing your own half-baked MD5 or SHA password hashing scheme, you could drink half a beer.  And since that's about how long it would take to brute force those pieces of shit, it's a net win for society if you just drink the beer.

    Gee, I wonder if I was joking...



  • @blakeyrat said:

    @morbiuswilters said:

    @blakeyrat said:

    I store my passwords in plaintext just to avoid the obligatory 3-week long rant-fest whenever hashing passwords is discussed on a programming forum.

    With the time saved not implementing your own half-baked MD5 or SHA password hashing scheme, you could drink half a beer.  And since that's about how long it would take to brute force those pieces of shit, it's a net win for society if you just drink the beer.

    Gee, I wonder if I was joking...

    Gee, I wonder if I was, too...



  • @morbiuswilters said:

    @blakeyrat said:

    @morbiuswilters said:

    @blakeyrat said:

    I store my passwords in plaintext just to avoid the obligatory 3-week long rant-fest whenever hashing passwords is discussed on a programming forum.

    With the time saved not implementing your own half-baked MD5 or SHA password hashing scheme, you could drink half a beer.  And since that's about how long it would take to brute force those pieces of shit, it's a net win for society if you just drink the beer.

    Gee, I wonder if I was joking...

    Gee, I wonder if I was, too...

    I guess we'll never know!



  • @EJ_ said:

    @pbean said:

    I still don't understand why so many sites put such terrible limits on passwords, like a maximum length or what kind of character it should start with.

     

    I can tell you exactly why: because they store the password plaintext and the database password field is set to N characters long, so thus the limit. If they were using a hash of some sort, they could just set the password field length to the hash length and any password will fit. I typically try extremely hard to avoid places that use that method.

    The last place I worked had some user benefits page that had this requirement, and I complained to them about it. They were astonished I had "hacked" into their page to find out this information, and then informed me that they use the latest security practices. I kept informing them that they weren't, but they wouldn't have any of it. Eventually I got out of them that they store the passwords plaintext so that when idiot users forget their password, they can just tell them, instead of having to do something like "we've e-mailed you a new random password" so I set my password to "cuntcuntcunt" (12 characters max, no punctuation) and then 'forgot' my password and had someone read that to me on the phone. It was great, I think I as laughing so hard and I managed to squeak out "hahaha, can you say that again? hahahahaha".

    I've had the same experience from the other end - working in tech support for a company that used that password reminder procedure (for one of their clients) and had a woman call up for a reminder. Her password was 'bigboobs'. To compound the fun, that client has managed to mangle their database every now and then, such that random users' records have been merged together field by field with random priority. There's about a 1% chance that someone else actually chose the password in question.



  •  What's worse is when the login form accepts a longer password than the registration form, so that if you use a password safe (like KeePass) you have no fucking idea what the password is because the registration form truncated it somewhere, so your only option is to use the password reset because otherwise you'll lock yourself out trying to guess how long the actual password is.



  • @morbiuswilters said:

    @blakeyrat said:

    @morbiuswilters said:

    @blakeyrat said:

    I store my passwords in plaintext just to avoid the obligatory 3-week long rant-fest whenever hashing passwords is discussed on a programming forum.

    With the time saved not implementing your own half-baked MD5 or SHA password hashing scheme, you could drink half a beer.  And since that's about how long it would take to brute force those pieces of shit, it's a net win for society if you just drink the beer.

    Gee, I wonder if I was joking...

    Gee, I wonder if I was, too...

     

    STOP CONFUSING ME



  • @morbiuswilters said:

    Because it is twice as slow.  Or do it a million times.  That's the entire point of a password hash--it shouldn't be fast.

    Of course your point above is true on some level -- that's the whole point of cryptography.  However, the salt+hash technique is well accepted in the real world as a "good enough" solution to the problem for the example I gave, which is web servers.  On a web server, you don't have the option of sitting there locking up the CPU for a long time for each user login.  Processing resources are not infinite, and thus we have to find real world solutions.

    @morbiuswilters said:


    @sidecomment said:

    One of the nice things about the hash+salt scheme when properly implemented is that the output of a particular hash function will have fixed width.  So you could store the hash output as binary data in a database, or base 64 encode it and put it in XML, etc.  The width of a password entered has no relationship to the storage requirement for the hash.  The latter is known and set deterministically.

    NO NO NO NO NO NO.  Goddammit, stop spreading your ignorance.  A fixed-length output is not a benefit.

     Cut out the nasty attitude, please.  The "benefit" I referred to (of a fixed length output) was referring to convenience of storage, not security.  It's nice when setting up the hash column of your user table to know exactly how many bytes are required.

    @sidecomment said:

    And (once again) the hash+salt scheme when properly implemented (i.e. just to be clear, "hash(pw+salt)") is that it is _not_ susceptible to dictionary attacks, which is where morbiuswilters' post was misleading (are we dead yet?).

    @morbiuswilters said:


    NO NO NO NO NO NO NO NO.  Lookup dictionary attack, please.  It is not (necessarily, at least) a pre-computed attack.  The "dictionary" is the list of likely candidate passwords to try.  It can just as easily be run with or without a salt.  Salts are important at defeating pre-computing attacks, but that is not the primary concern when your hashing algorithm can be brute forced at a rate of 500 million hashes a second.  Okay?  In fact, dictionary attacks would be the prime candidate for cracking a password database that used individual salts because rainbow tables would be useless.  "Dictionary attack" and "rainbow table" are not synonymous.

     

    I know what a dictionary attack is.  I guess I interpreted your post as highlighting a flaw related to the hash+salt approach, whereas it looks like all you meant to say is that any password based system has a weak point that (individual) weak passwords can be guessed.  Fair enough, I guess I misunderstood you.

    What I was talking about, and what the hash+salt approach addresses, is the attack vector of database access (think SQL injection).

    If you use plaintext passwords, then they are trivially accessible -- no dictionary attack needed.

    If you just hash the passwords, then dictionary attack of the database is possible, revealing lots of peoples' passwords.

    If you use proper hash+salt, then even having full database access is not a useful attack vector to compromise the system.  That's what I meant about the NSA, etc.

    So talking about this totally separate attack vector that admittedly still exists (individual password guessing via dictionary attack) doesn't really have anything to do with your decision about password storage -- it's misleading and inappropriate to even suggest that it has something to do with the decision of password storage.  So my point there still stands.

    P.S. MD5 is generally deprecated these days.  People should use SHA1 or better.  Not sure why you mentioned MD5 in your reply.  Is that what you use?  :)



  • @Sir Twist said:

    What's worse is when the login form accepts a longer password than the registration form, so that if you use a password safe (like KeePass) you have no fucking idea what the password is because the registration form truncated it somewhere, so your only option is to use the password reset because otherwise you'll lock yourself out trying to guess how long the actual password is.

    That happened to a friend of mine back around the turn of the millenium, with an extra-WTFy twist.  She was using a Hotmail account and had to get her password reset for whatever reason, and then couldn't get in.  She called me over to take a look at it and try to figure out what the problem was.

    Turns out the problem was the well-known issue that the morons at Microsoft have no clue how to write code.  When my friend had her password reset, they assigned a new default password that was longer than the maximum acceptable password length.  Yeah, that's right. The too-long password was set by Hotmail themselves, not by my friend!  It didn't take me too long once I understood the problem to find a way to hack around that so she could reset it to something that it would accept, but... sheesh!



  • @morbiuswilters said:

    That's fine.  I'm not saying plaintext is better than MD5, or that salting isn't important (it is).  It's just that MD5/SHA is shit and to see people still doing md5(salt + password) in the year 2010 kills me inside.  This is supposed to be a site dedicated to doing things the right way.  Encouraging long-obsolete security practices (I know that's not what you were doing, but some people were) is not good.  Even hearing how many people on here have no idea how to hash passwords properly is a bit depressing.  Of course, cryptography is a complex, delicate subject so it's not something most programmers need to know, but so many apparently think they know enough to write their own password hashing schemes instead of using a well-designed, cross-platform library like bcrypt.

     

    Ah, good.  So here morbiuswilters is saying that we should use hash+salt, it's just down to the question of what hashing algorithm to use.  Cool.  I'm fine with that, now that we've moved past the silly-sounding "hash+salt is not much better than plaintext".

    Probably the remaining area of disagreement would be how strong an algorithm we can get away with employing on the average web service in terms of CPU load -- for certain websites with lots of users, it simply isn't possible to go to the extent morbiuswithers might be suggesting here.  Sure (barring some leaps and bounds in cryptography) the Blowfish password hashing scheme is great and all, but if you have to let a million users log in in a short time, you're probably going to have to compromise a little bit.



  • /me gives morbiuswilters a chill pill :)

    I agree, MD5 + Salt is bed. The best way is clearly to use several salts AND use the length of the password in the hash. People would Never guess that!

    sprintf (temp,"chocolate%s-salty%x-balls", password, 42+strlen(password));
    storedpass = md5(temp);

    http://www.youtube.com/watch?v=lnNYXgV7L-c



  • This thread reminds me a lot of that javascript loopy button thing, except Chrome doesn't automatically suppress it. I'm not sure how to file a bug report about it. Something like 'there's a strange whiny noise coming from my computer'.



  • @sidecomment said:

    However, the salt+hash technique is well accepted in the real world as a "good enough" solution to the problem for the example I gave, which is web servers.

    No, it's not.  It's easy as hell to crack.

     

    @sidecomment said:

    On a web server, you don't have the option of sitting there locking up the CPU for a long time for each user login.  Processing resources are not infinite, and thus we have to find real world solutions.

    How many logins are you processing?  And are you really arguing that it's better to accept lousy security that is literally 8 orders of magnitude easier to crack simply to conserve CPU time?  CPUs are cheap.  You might as well argue that SSL is a waste of CPU and ROT-13'ing the page is "good enough".

     

    @sidecomment said:

    I know what a dictionary attack is.  I guess I interpreted your post as highlighting a flaw related to the hash+salt approach, whereas it looks like all you meant to say is that any password based system has a weak point that (individual) weak passwords can be guessed.  Fair enough, I guess I misunderstood you.

    You misunderstood more than that.  A dictionary attack against MD5 or SHA is literally millions of times easier than one against a proper password hashing algo.

     

    @sidecomment said:

    If you use proper hash+salt, then even having full database access is not a useful attack vector to compromise the system.  That's what I meant about the NSA, etc.

    Which is where you are simply fucking wrong.  When you can do hundreds of millions of hashes per second, distributed dictionary attacks of hash+salt become quite achievable.  The primary purpose of hashing passwords is because many users use the same password for multiple systems.  It's not to protect the security of the current system (since it's likely already compromised) but to protect the security of other systems where users have the same password.  Towards that end, if someone is going to bother stealing the password in the first place, it's probably worth their time to throw your shitty salted hash at a botnet and have it crack the password, no?  If you're going to bother implementing password hashing, you should actually use a method that isn't trivial to crack.  The two principle rules of cryptography are: 1) don't write your own crypto stuff because you will just fuck it up--use a well-tested library; and 2) nothing is uncrackable--the goal is to simply make it too expensive to crack.  This isn't 1990: salted hashes are not expensive enough.

     

    @sidecomment said:

    So talking about this totally separate attack vector that admittedly still exists (individual password guessing via dictionary attack) doesn't really have anything to do with your decision about password storage -- it's misleading and inappropriate to even suggest that it has something to do with the decision of password storage.  So my point there still stands.

    What in the fuck are you talking about?  Jesus Christ, I'm wasting my time arguing with a complete moron.  The dictionary attack would be run against the compromised password database.  If I have the hashes and I know you are using salted MD5/SHA, I can simply run a dictionary attack against the password database.  Salting protects against rainbow tables (which would be very fast) but it does nothing to protect against a dictionary attack (which is still pretty damn fast against MD5/SHA--that's the entire point).

     

    @sidecomment said:

    P.S. MD5 is generally deprecated these days.  People should use SHA1 or better.  Not sure why you mentioned MD5 in your reply.  Is that what you use?  :)

    Yes, I explain in great detail why MD5 is shit and why you should be using bcrypt, but then use it myself.  For password hashing, SHA1 is also "deprecated" because it isn't expensive enough to make dictionary attacks infeasible.



  • @sidecomment said:

    Ah, good.  So here morbiuswilters is saying that we should use hash+salt, it's just down to the question of what hashing algorithm to use.

    No, unless you consider bcrypt to be "hashing".  MD5/SHA+salt isn't much better than plaintext.  You might as well not even bother.

     

    @sidecomment said:

    Probably the remaining area of disagreement would be how strong an algorithm we can get away with employing on the average web service in terms of CPU load -- for certain websites with lots of users, it simply isn't possible to go to the extent morbiuswithers might be suggesting here.  Sure (barring some leaps and bounds in cryptography) the Blowfish password hashing scheme is great and all, but if you have to let a million users log in in a short time, you're probably going to have to compromise a little bit.

    You are a goddamn retard.  I suppose you consider SSL "not worth the overhead".  Please, tell us all of the shitty apps you've written so we can avoid them.  All cryptography is a trade-off between CPU time and the security of what you are trying to protect.  You are advocating a technology that is so weak it barely even qualifies as cryptography.  You might as well just use DES or ROT-13.



  • @morbiuswilters said:

    @sidecomment said:
    I know what a dictionary attack is.  I guess I interpreted your post as highlighting a flaw related to the hash+salt approach, whereas it looks like all you meant to say is that any password based system has a weak point that (individual) weak passwords can be guessed.  Fair enough, I guess I misunderstood you.

    You misunderstood more than that.  A dictionary attack against MD5 or SHA is literally millions of times easier than one against a proper password hashing algo.

    You are correct that a weak password (i.e. the kind that's susceptible to a dictionary attack) should be regarded as a weak link under any system.  I have no disagreement with that.

    You are incorrect with your universal declarations about bcrypt and a one-size-fits-all approach to web security.  For many people, CPU load does need to dictate where a developer draws the line on these things, and it's just silly to make universal statements otherwise ("CPUs are cheap, so you must use at least bcrypt or else you're a @#*(&#$@ &@*#($&*& *@(*&@!"). Without specific numbers and scenarios -- real context, this discussion is pointless.

    * sidecomment borrows the the Chill Pill bottle from Mole for a second and reads the label to see why the dosage doesn't seem to be working.*



  • @sidecomment said:

    * sidecomment borrows the the Chill Pill bottle from Mole for a second and reads the label to see why the dosage doesn't seem to be working.*
     

    Oh, he's always like that. Just play along and respond with content, as you've done so far. He's like Serious Content and Comic Relief all rolled into one (very) compact package.

     

    I have serious doubt that CPU load is going to be an issue when verifying a login, or fifty-thousand logins, or half a million logins, as logging in can't be more than a tiny tiny tiny tiny fraction of the CPU required to let users actually use the application's features, such as searching for and displaying highly interrelated statistics (last.fm compatibility and neighbours), or processing uploaded images (flickr) or video (youtube).



  • @sidecomment said:

    You are correct that a weak password (i.e. the kind that's susceptible to a dictionary attack) should be regarded as a weak link under any system.  I have no disagreement with that.

    When you can do billions of hash searches per second (distributed) then your "dictionary" will hit a lot of passwords.  Sure, the good passwords will still be uncrackable, but you're not worried about good passwords.  Security-conscious users who use good passwords will also be smart enough to use a unique password for each service.  You don't need to worry about a compromise of your password database opening up other services to compromise for them.  The weakest link is always the problem, and using a real password hashing scheme makes the weakest link all the stronger.

     

    @sidecomment said:

    You are incorrect with your universal declarations about bcrypt and a one-size-fits-all approach to web security.  For many people, CPU load does need to dictate where a developer draws the line on these things, and it's just silly to make universal statements otherwise ("CPUs are cheap, so you must use at least bcrypt or else you're a @#*(&#$@ &@*#($&*& *@(*&@!"). Without specific numbers and scenarios -- real context, this discussion is pointless.

    You are so full of shit.  You just can't admit you don't have a clue what you are talking about and that you've been doing it wrong for awhile.  Login verifications are just a fraction of the requests an app will serve.  It's an insignificant amount of CPU time.  If you are bothering to do hashing in the first place, you clearly are concerned with having your password DB compromised.  Why half-ass it?  Why use a method that is literally millions of times weaker?  As I said, SSL is expensive, so do you decide that doing SSL just isn't worth it and write your own half-assed page encryption algorithm?  Because that is precisely what you are doing here.  You are ignoring secure technologies created by actual experts to subsitute your own mediocre, home-grown method.  All to reduce the CPU usage of your app by less than 1%.  That is the definition of sloppy, half-assed security.  You aren't being clever or reasonably "drawing a line", you are doing it wrong.  I've worked on web apps far larger than anything you've ever been allowed near and I can guarantee you that your concerns are nothing more than pretend "engineering" masquerading your own ignorance and incompetence.



  • Have a nice day, Dean!



  • @dhromed said:

    @morbiuswilters said:

    What interests me more is the "must start with a letter" condition.  Perhaps they're using a language with type coercion and had problems with passwords being converted to ints unless there was a letter at the beginning?
     

    I am unwilling to invest time in coming up with a code situation where such a thing would occur.

     Passwords are stored in Excel !



  • @sidecomment said:

    Have a nice day, Dean!

    Dean?  Like.. the academic position or the name?  I don't think either one applies to me...



  • @RogerWilco said:

    Passwords are stored in Excel !
    Using rot13 for extra security?





  • @dcromed said:

    I am unwilling to invest time in coming up with a
    code situation where such a thing would occur.

    Unfortunately, all I have to do is invest in some memory.

    So I was working as a tester/code reviewer for a website written in perl CGI. The code in question took the username and password from the POST form values, and then, in a senseless string eval, attempted a bind to the LDAP server. This caused the username and password to be evaluated as code. If they were not legal barewords, and they weren't a deliberate abuse of the eval, the code would bomb and display an error page.

    I'll skip the saga of getting it fixed, and simply mention that, while this could have been "fixed" by ensuring that all entered usernames and passwords were legal barewords, and it could have been kludged by escaping the variables, I found it easier to just not bother doing the eval.



  • @Who_the_Fuck said:

    barewords
    ... no quotes?


Log in to reply