6 ms·

The real problem of passwords in general is the complete lack of a standard to what a password can be. Basically every service with a login reinvents the whole

• wisty 15y ago
  Silent truncation is another gotcha. They drop everything after character 8 (so it fits in the database?). Then they change the schema, and stop truncating at 8 characters, but only on some forms. Oh, the joy.
  • ovi256 15y ago
    MSN and Hotmail used, and maybe still do this, after 14 characters.
    • bwooce 15y ago
      My bank does it after 6! It even reminds you that it is 6 chars max on the login page.
    • kijin 15y ago
      Now it's 16 characters at Hotmail.
  • cpeterso 15y ago
    I think the common problem of silent truncation after 8 characters suggests they are using the (outdated) crypt(3) API. The man page says "By taking the lowest 7 bits of each of the first eight characters of the key, a 56-bit key is obtained."
• drostie 15y ago
  This is at least partly true. I remember using passphrases which involved spaces, until PayPal said "no we don't like spaces". I have no idea why; the only case that I can think of where spaces would really matter is if you were piping your password to an encryption command via a shell script -- in any other case it shouldn't be tokenized that way. There also should never be a rule about maximum length, and all passwords should be valid Unicode strings. Storing a hash of a unicode string should not be hard in this day and age. Part of the problem is that languages never standardized one password interchange format. It could be really simple. Here's one example: 13 ffH+5dfGr64h UYDpAQkrzmvI8fZhqtXQNqCGLouWn2edKowiyqTlzsg This is an interchange format based on computing PBKDF2(HMAC(SHA256)) with 2^13 = 8,192 rounds and a salt of ffH+5dfGr64h, to hash the given password. The exact mechanisms aren't important here, what's important is that there is no portable primitive which does this. The closest that the above comes to being realized is a system called bcrypt. It isn't PBKDF2, but oh well: find a bcrypt module and use it.
  • tomg 15y ago
    > There also should never be a rule about maximum length What about hash collisions? Is there a good way to handle that?
    • drostie 15y ago
      Collisions can be handled with two different approaches. The first problem with collisions is when two people have the same password. This is one of the reasons you should salt a password before hashing. If you choose a random m-bit salt then due to the "birthday phenomenon", you can go to around 2^{m/2} users before there is a significant risk that some pair of them shares the same password. This actually isn't too hard to understand. If you have N people who want to high-five each other (e.g. N ~= 18 at the end of an Ultimate frisbee match, everyone from both teams generally high-fives everyone on their own team as well as everyone on the other team), then there are N * (N - 1) / 2 high-fives, or roughly N^2 / 2 for very large N. To see this, enumerate all of the pairs (1, 1), (1, 2), ..., (N, N -1), (N, N), N^2 of them in total, then cross out the ones of the form (k, k), N of them in total, because nobody high-fives themselves, and then cross out the half (a, b) for which a > b, because 3 high-fiving 2 is the same as 2 high-fiving 3. Then (N^2 - N) / 2 = N (N - 1) / 2. But if each of these comparisons has a roughly independent chance p of sharing the same salt, like 1/2^72, then the number you need before you get towards a 50/50 chance is approximately p * N^2/2 = 1/2, or N = sqrt(1/p). If p = 1/2^72, sqrt(1/p) = 2^36 = 68.7 billion. So a 72-bit random salt will make sure that everyone shares a salt with less than a billionth of your users or so. If you want even better, you might want to know that a salt doesn't have to be random, and you could generate them incrementally to get even more security. For example in Node.js: var new_salt = (function () { var counter = 0, buf = new Buffer(8); return function () { counter = (counter + 1) % 1e6; buf.writeDoubleLE(new Date().getTime() * 1e6 + counter, 1); return buf.toString('base64') }; }); Now as long as I have fewer than one million new passwords per millisecond, there is no chance at all of two people having the same salt. (I'm sure Windows has timing issues so that this has to be much more than once per millisecond, but the point stands.) You asked about hash collisions in particular, and in the context of not having a maximum length. That's a little trickier of a problem. Yes, there exist attacks, particularly on MD5, which use a bunch of arbitrary output blocks to steer a hash to a particular value. But that usually requires a hash to be well-broken. In the case of SHA-256, you would need something like 2^128 user accounts before you'd map different inputs to different outputs. So you're protected from both: you ensure different inputs to the hash function and then you choose a hash function which requires too much work to generate collisions.
• ploxination 15y ago
  The state-owned swedish gambling-company Svenska Spel set the bar high with only allowing numbers in their password, with a max length of 6. Good times.
• 16s 15y ago
  This is so true. You may have a great password, like this: 9rIqIiGByCzcWq But, it may be considered too long by some services, or not complex enough by others (as it lacks special chars), or it can't begin with a number, etc. Adding special chars breaks it for some DB apps (oracle can't take some chars in the password). It's really frustrating that it's 2012 and there's no global ISO password standard (or something similar).
• mistercow 15y ago
  Maximum length is the worst. If I discover that a service enforces a maximum length (besides simple practical limits like, say, 255 characters), I do not use that service if I can avoid it. You know when you see that that you are not dealing with someone who understands security.