If want to limit the number of possible characters that could be used for a password in my database (mysql), do I just set the type to varchar(#of chars) for example: varchar(15). For 15 maximum characters that can be used?
-
4You should read up on password hashing. Limiting the length of a password is rarely, if ever, a good idea. – spenibus Jul 31 '15 at 19:01
-
1Please **do not** limit a password's length. Also, do not restrict the character set of a password. *Always* hash a password and store the hash, not the plaintext password. This implies that there needs to be a mechanism to set a new password when the old is forgotten. – wallyk Jul 31 '15 at 20:12
2 Answers
Certainly you can limit the length of something by setting its field length in the database. But this would result in confusing situations for your users. Someone might think he's using a strong password by typing in 20-30 or more characters, but you're silently storing only the first 15. That might even cause him trouble later on if he changes his password and only changes the last few characters - to you it would be the same 15-character password. Very puzzling.
If you do limit the lenght, be very clear about it in your UI with instructions and good error messages after you check length.
But better yet, don't limit password length. The longer the better for strong passwords!

- 19,439
- 4
- 63
- 103
-
"That might even cause him trouble later on if he changes his password and only changes the last few characters - to you it would be the same 15-character password." Plus, if you ever make the column longer, everyone with passwords longer than 15 would suddenly stop working. – ceejayoz Jul 31 '15 at 20:12
-
I agree with the basis of this, though there's probably no extra value for passwords longer than, say, 128 characters. It prompts me to wonder what the opportunities are for denial of service if a malicious user tries to send passwords close to the post size limit, which is (I think) 2M by default in PHP, and larger site-wide on some systems, to cater for large file uploads. Hashing passwords of those kinds can't be good for the CPU. – halfer Jul 31 '15 at 21:16
I think you are in a very bad mindset when it comes to passwords. Here are some things to keep in mind when working with passwords.
You should NEVER store plain passwords in the DB. All passwords should be hashed before being stored. The industry standard way is to use bcrypt hashing. It creates a 60 character long string.
Longer the password, harder it is to crack. That means ideally you shouldn't limit the max number of characters in a password. On the other hand, limiting the min number of characters is a good idea.
Read up on password salting. It is a way of adding more security to your password. bcrypt libraries do this for you - you should let it, rather than trying to come up with your own salts.
If you really need to limit the number of characters in a password, do it programmatically. This way you can inform the user that it exceeds the limit. If you don't you have a scenario described in @n8wrl's answer.
If I have missed anything, leave it in the comments and I will edit the answer accordingly.
-
11.) md5 is not an encryption. 3.) Salting does not provide security for the used login. It only avoids that a password can be reconstructed from the hash using rainbow tables. (Also it ensures that - if a attacker gets access - he could not reconstruct all passwords with a single "go", but need a individual salt per password) – dognose Jul 31 '15 at 19:58
-
1
-
You are correct. I was trying to say that passwords should be encrypted or hashed. Didn't really meant that MD5 was an encryption algorithm. As far as salting goes, you are correct again if someone has already managed to get a hold of your DB. However, depending on how you create the salt, it can be an added security. – RisingSun Jul 31 '15 at 20:09
-
MD5 is a hashing algorithm, not an encryption algorithm, but people's objections to it are that it is too fast these days, and thus not safe if you don't want passwords to be brute-force retrieved. – halfer Jul 31 '15 at 20:12
-
@halfer MD5 has many issues but I think it is a good place to start instead of jumping straight to the "best option" because if they did, they wouldn't really learn the basics and reasons behind why that is used over other method. It just would be something that is used with password because someone said it should be. Starting with MD5 and seeing why it needs more safeguards around it and why others don't is an excellent learning experience. – RisingSun Jul 31 '15 at 20:20
-
And risk user's password security in the process? No, that's really not recommended. People can play with `md5()` if they wish, but it's just as easy to use `password_hash()`. – halfer Jul 31 '15 at 20:22
-
I don't think many people start coding something straight in production. If you are doing your due diligence, you can easily find the issues with MD5 while in development. Otherwise it is just something that is blindly used. It is better for the programmer if they knew why they were doing things in a certain way. I still recommend playing around with MD5. It wasn't until not too long ago that everyone used md5. – RisingSun Jul 31 '15 at 20:28
-
2Yes, but security moves on. One of the problems I see frequently is that beginners are not only coding "straight into production" but they're writing tutorials. Lots of them, and they're mostly terrible. SQL injection, XSS, plaintext passwords, no salting and inadequate hashing. We need to be careful we're not fuelling these poor practices here. – halfer Jul 31 '15 at 20:33
-
"you can easily find the issues with MD5 while in development" is plainly false, since thousands of tutorials still feature it, and a lot of developers are still using it as a magic panacea. Yes, it is blindly used. It should not be used for password hashing, blindly or otherwise. – halfer Jul 31 '15 at 20:34