0

I know that to store a password you have to hash it. I use password_hash and password_verify to do it.

But I am surprised that some people say that you do not need to validate a password before hash it, because you are going to hash it anyway.

I think that at least it would be good practice to validate that the user enters a password with length more than an amount of characters or to make the user to input a special character (*, ", ', etc). At least to make the password strong.

So here I have some questions:

  • Is it considered a good practice not validate anything about the password and only hash it?
  • Has an additional security to make a validation before hash the password?
  • If so, what should be considered in that validation?

Note: I want to know all of these questions from security point of view.

Thanks in advance!

Francisco Romero
  • 11,900
  • 18
  • 71
  • 151
  • 4
    Relevant: http://www.xkcd.com/936/ – ceejayoz May 31 '16 at 20:54
  • 1
    [Don't limit passwords.](http://jayblanchard.net/security_fail_passwords.html) – Jay Blanchard May 31 '16 at 20:55
  • 1
    I'd avoid the term "validate" here. What you're discussing are *password strength requirements*. – ceejayoz May 31 '16 at 20:55
  • You can and should validate password strength before hashing it. Anyone who suggests otherwise should be held down and [ticked](http://tickledmovie.com) – scrowler May 31 '16 at 20:55
  • 2
    You'll find plenty of discussion over on Security.SE. http://security.stackexchange.com/questions/85724/password-strength-metrics http://security.stackexchange.com/questions/51050/does-password-strength-matter-anymore http://security.stackexchange.com/questions/32222/are-password-complexity-rules-counterproductive http://security.stackexchange.com/questions/42134/is-there-any-point-in-using-strong-passwords http://security.stackexchange.com/questions/16455/why-do-password-strength-requirements-exist – ceejayoz May 31 '16 at 20:57
  • 5
    Set a minimum length and, if strictly necessary, a requirement for a single special character or number. Don't make it absurd, like "Must contain a prime number greater than nine digits, the Latin name of an animal spelled backwards, and proof that P=NP using emoji." Remember to keep your level of paranoia *appropriate for the security implications of the data being protected*. Too many message boards of no consequence have tons of security, and too many banks have extremely limiting password requirements. – tadman May 31 '16 at 21:00
  • 1
    @ceejayoz good list, I very much agree with this poster http://security.stackexchange.com/a/51051/28591 . Enforcing password rules is annoying, so enforce as little as you feel comfortable with. – JimL May 31 '16 at 21:00
  • I'd put in place a client and server side verification in order to ensure the password has a min. length, digits, upper, lower and special chars. Make sure you really need this, otherwise users may get annoyed. – Pedro Lobito May 31 '16 at 21:02
  • @ceejayoz Thank you for your reply! I just thought to make some minor validation before hash it. Just to make it more strong (I thought). – Francisco Romero May 31 '16 at 21:18
  • @tadman Yes, it was what I thought. To make a minor validation (not overkill it) to make the password a bit stronger (I thought). – Francisco Romero May 31 '16 at 21:27

1 Answers1

0

Password strength requirements are context sensitive. You don't talk about your context.

Normally I would set a minimun length, and compute some sort of complexity index, so as to prevent people from entering 'aaaaaaaa' or '12345678'.

But password strength requirements are annoying, especially when you dictate many rules.

I often try to implement another strategy: I choose the password for my visitors. This is not a new idea; Think about the personal identification number for a credit card. This has many benefits:

  • My visitors don't have to choose a password, something they often find awkward.
  • I definitely control the complexity of the passwords.
  • I cannot possibly know the often used password of my visitors (and hack their accounts on other sites).

There's also a downside: The visitor has to 'remember' the password I chose. Keep it simple. A four digit PIN already has 10000 variants. To prevent abuse I limit the number of tries.

For sites that needs to be very secure you could increase the complexity of the password and reissue passwords regularly. Do not store the password in your database, only store a salted hash. Don't email the password but show it in a SSL secured HTML page. If the security requirements aren't that high you can ignore some of these rules.

KIKO Software
  • 10,480
  • 2
  • 13
  • 28