Is problem with string length in token (read password) randomization a security flaw? Is there any impact for the same?

Question

this application sends a password to user's email when user click on forgot password on login page. However, the password is not the same in length always something it will be a 25+ string and something less than 10 chars, this is not at all constant.

Can this be considered a security issue in any way? As per my knowledge since its not affecting anything it won't be considered so thought to know if anyone in community knows any way to exploit this (except brute force obliviously)?

PS: I have access to application's source code, maybe I should do a source code review and try to chain this issue with something else.

EDIT: Just checked my mails, one of the passwords I received was as high as 95 char string. Isn't this stupidity, sometime 95 char long string and sometime just 10 chars?

Answer 1

One consideration is DoS.

Hashing algorithms require computational power. When you give a hashing algorithm a large amount of data it has to make computations and run operations on all of it to create the correct output.

Perhaps if the server is running with minimal computational power, a resource exhaustion attack could take place by repeatedly registering, or changing users' passwords to extremely long passwords in order to for the CPU to hang. If thousands of users did this in a distributed fashion it would be an application denial of service.

Answer 2

As long as a truly randomly generated password is at least 6 characters long, it passes the NIST's password standards, which is regarded by many to be a good bare minimum standard. (A user-generated password should be at least 8 characters long, because it's much less likely to be randomly generated.) Your own security team should decide on reasonable minimums for your organization.

The most important factor in any secure password is how random it is. If we assume that the passwords are generated in a secure way, then varying their length will tend to improve the security of the overall system.

Applying Kerckhoff's Principle, that everything in a system is public knowledge except for the key -- in our case, except for your password -- we must assume that an attacker will know the length of the passwords that such a system generates. If they can't be certain of the length because it can be anywhere from 10 to 95 characters, then this increases the search space, and can increase the time it takes to brute force a password (though if you're unlucky enough to get a very short password, it might decrease the time).

So, outside of any other considerations, the security of a system is not meaningfully impacted by having a random password length, when that password has a reasonably long minimum length.

You state in your comments that the emails are always sent encrypted. This removes one such "other consideration" that I allude to in the above paragraph. If they were sent unencrypted, then the proper action would to make these randomly generated password be one-time-use passwords which must be reset once you gain access to the account. This way, if someone did beat you to logging in, you would know, and could take additional action as necessary.

Another consideration is password storage. Since you have access to the application's source code, you can ensure that they're using a key stretching algorithm with configurable difficulties to make offline brute force attacks as expensive as possible. The NIST standard specifically mentions PBKDF2 and BALLOON. Other key stretching algorithms with configurable difficulties include bcrypt, scrypt, and Argon2. Simply salting and hashing a password is no longer considered secure, even if using the "best" cryptographic hashing algorithm. These hashing algorithms are indeed part of PBKDF2, but should not be used by themselves to secure passwords.

One final consideration is the human factor. People don't enjoy using very long, truly random passwords. The longer and less memorable it is, the more likely it is to appear on sticky notes tucked under keyboards. The solution to this, of course, is to encourage use of password managers.