Passwords and coding practice

[Anon]

I am working on developing my first user authentication library (I hate using other people's libraries - don't ask me why), and have a question: do you general do any type of validation for the password a user chooses? Right now I have my library make sure the password is at least 6 characters long, and as it stands now, I'm forcing it into an alphanumeric string.
i.e.:
ereg("^{[_A-Za-z0-9-]{6,}$")}
Am I being to controlling to my uses? Should I let them put anything they want in their passwords, like !@#$%^{&*()~`[]{};:'",<.>/?} and spaces? Will these characters screw anything up if I am using md5() encrypting to protect the password? What kind of validation do others usually use on their password fields?
Thanks for your help,
Justin Kohlhepp
http://justink.net

[Anon]

No I think you should't
The best way is to allow them thats availible on Unix passwords its A -Z a -z and _
and 1 -9
To use md5 is a good idea i think cos I do it too.
Best Regards
Ufux
www.isletmekulubu.com

[Anon]

Well, I'll be contrary and argue the opposite point.

I think you should allow any characters a user might want to use, and you should allow plenty of space to do it. In fact, I think you should allow 80-character passphrases.

Unix logins won't allow that, but not everything Unix is a good idea.

History lesson: For many years, Unix software commonly used gets() for user input, including the login/password sequence. The gets() function in C doesn't check to see whether the input string is bigger than the buffer size. This allowed Robert T. Morris to overwrite the input buffer with binary data, push instructions into unprotected code space, and gain entry into systems.

He wrote a worm program that exploited that and other weaknesses, and that program replicated itself. He made a little coding error and the program replicated itself too quickly. In one afternoon he brought the entire Internet to a halt. This happened before most of you ever heard of the Internet; in fact, most news media had never used the word before. You can verify this by going to a commercial online library service (Lexis-Nexis, for instance) and doing some searches.

The point is that although some things about the Unix architecture reflect brilliant thinking, there are many historically common Unix system practices that are really, really dumb.

More modern (and security-paranoid) software, such as ssh, allows longer passphrases that may include all sorts of characters. I think it is perfectly legitimate for a user's password to be "my mom's c@t ate the n-e/i\g^h~b*o(r)'s canary."

md5() won't care. It's just computing a really complicated checksum on whatever you feed it.

[Anon]

One thing you may wish to add is to keep people from using nothing but 1 letter/number, or something to that effect.

It really all depends on how anal you wish to be.

I for instance, often use varied case passwords which cannot possible be found in any dictionary, totally excluding prefixes or suffixes of words, NO proper names or sequential numbering, often in excess of 12 characters long.

No matter how good the encryption, it's only as strong as the key used to encode it.

A little for instance.

Remember, to calculate the possible combinations, you multiply the amount of possibilitys in the first spot by the amount of characters in the second spot, and then multiply by the next spot, and so on and so forth.

Now, in a 4 character password which only allows a-z, not case sensitive, there are 26⁴ possibilitys, which is 456,976 possibilitys.

By adding "_" and " " you increase it to 614,656 possibilitys.

By only adding 1 more digit (so it's 5 digits, each digit being 1 of 28 possible choices), it increases the combinations to 17,210,368!

Now, make that password case sensitive and remove "_" and " "?

380,204,032 combinations! Add 1 character (let's say "_") and you have 418,195,493 possibilitys!!! Not bad for a single space, eh?

Now, going from A-Za-z to: A-Za-z0-9 !@#$%^{&*()-+/[]{}<>,.}

You now have 4,704,270,176 possibilitys. Not too shaby eh?

Let's make the jump to your very wise use of 6 characters or more, and you have sigh:

86⁶ (86 to the 6th power, that is), for a total of: 404,567,235,136

Now, don't get too exited with the insane mass of password possibilitys, as reading in on applications like l0phtcrack (good old l0pht heavy industrys! 😉 ), advanced dictionary password cracking and various such applications, and you'll see that the majority of passwords can be cracked in a sad 24 hour period on only a marginally faster computer.

Some people just don't get that your name, followed or preceeded by a numerical digit or alphanumerical character, does nothing but slow down a cracking app by a pitifull second at most.

Just because your paranoid, doesn't mean they aren't out to get you.

I love that saying 😉

In closing...yes, as long as you prepare your script properly to accept the password, allow as many characters as you can 🙂

[Anon]

Okay, thanks to all of you for your help. Since two of you thought that MD5() won't care about special characters, and that there is no issue with those characters screwing up my script, I've decided to let the user put in anything they damn well please, as long as it is 6 characters or more.
So we're back to:
ereg("^{[_A-Za-z0-9-~`!@#$%&*()+={}[]:;"'<,>.?/|\} ]{6,}$");
OR
ereg("^.{6,}$"); :-) much simpler
Thanks for yr help guys,
Justin