0

My client wants to include some rules to validate the passwords his clients can choose when creating a new account. Since his company handles sensitive client data, I think I want to convince him to drop some of his desired validation rules for the sake of security. So I started calculating some things, but I got stuck with the second rule.

According to two of the rules, the password can not contain:

  • Space characters
  • Three of the same character (e.G. ramadan1 or scooter666 would be invalid)

Considering an 8 digit (a-Z 0-9) password:

  • All possible combinations including Space (63^8) are 248.155.780.267.521
  • All possible combinations without Space are 218.340.105.584.896 (62^8)

this would reduce the possible combinations by roughly 30 trillion for no apparent reason.

But I'm not sure how to calculate how much impact that second rule would have. Can you help me?

Tom M
  • 101
  • 2
  • 1
    Character restrictions and an 8 character limit seem like they want to integrate with an ancient authentication system in the back end. I'd probe to see if this is the case. Otherwise, if passwords use modern hashes there's no practical reason to create an upper limit on password length that is any smaller than the size of the hashed output. – tjd Apr 05 '19 at 18:41
  • @tjd thanks for your response, but 8 is the possible minimum. I want to do the calculation considering the most unsafe password – Tom M Apr 05 '19 at 18:44
  • Fair 'nough. In which case you may want to search for research on how long it takes to brute-force passwords of length X. For minimum character length, I've been seeing recommendations of 12 or 14 characters in recent years. – tjd Apr 05 '19 at 18:47
  • @tjd the question is about how to get all possible combinations when you can't use three of the same character in the password. How can I edit it to make that more clear? – Tom M Apr 05 '19 at 18:51
  • 1
    62*62*61*61*60*60...... – tjd Apr 05 '19 at 18:53
  • 1
    Are you sure the 3 of a char rule is not 3 in a _row_? Or (more likely) has your client confused this? Because that rule is often enacted to prevent `aaaaaaaa` style passwords. My suggestion is ask them to justify these requirements, and explain every time you make your set of possible passwords smaller, it becomes less secure unless you're offsetting a different danger. – Kevin Mirsky Apr 05 '19 at 20:31
  • 1
    I haven't quite been able to work out the math, but I _have_ discovered that the term you're looking for is "partial permutation of a multiset". https://en.wikipedia.org/wiki/Permutation#Permutations_of_multisets Wikipedia, unfortunately, didn't list a formula for that, I couldn't easily find one on Google, and I'm not really up to trying to derive it myself at the moment. Anyway, the reasons why this is a bad idea have less to do with the exact number of passwords it would disallow and more to do with the poor user experience it would create for little to no actual security benefit. – Ajedi32 Apr 05 '19 at 20:42
  • 1
    Specifically, I'd consider pointing out that the longer a password is, the more likely it is that it will contain three of the same character. ["correcthorsebatterystaple"](https://security.stackexchange.com/q/6095/29865), for instance, contains 4 e's, 4 r's, and 4 t's entirely by coincidence and would thus be disallowed by those restrictions. – Ajedi32 Apr 05 '19 at 20:49
  • This is easy for me to say, but you should really tell the client that these validation rules break [Schneier's law](https://www.schneier.com/blog/archives/2011/04/schneiers_law.html) and that they should just implement [NIST 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) and then get on with their lives. – Graham Hill Apr 06 '19 at 13:31
  • 1
    @KevinMirsky yes, it's not 3 in a row. That's specifically my concern. I'd be able to comprehend 3 in a row, to prevent trivial passwords like `aaaaaaaa` but this just doesn't get to me – Tom M Apr 08 '19 at 09:18

0 Answers0