Is it sensible to accept a password + any other random characters for successful authentication?

Question

Supposing a user of my system has set their password to Password123

At the login screen, what would be the security implications of me accepting:

Password123 or Password1234 or Password123ABC

Based on the fact they all start with the password the user set?

To be clearer on the question, is this somehow less secure? How can I quantify that?

Surely this is as secure since an attacker must still know the password.

Also, with regards to the likes of a dictionary attack, it can only be more effort to guess - since it can only be longer than the password or the exact length of the password itself.

Note

I'm assuming this would imply the system is not hashing the password in it's entirety?

For further context, I accidentally discovered this was the case on a pretty large (understatement) system, and I'm wondering what the implications of that would be on security.

Answer 1

I would say that if it's a general rule that extra characters are always ignored, then yes, there's a security problem in there somewhere. Namely the fact that the system would either have to store your password length (so it knows when to start ignoring) or not use a hash, both of which are way less secure if/when the database gets breached.

If, however, it's as @gowenfawr suggested, that there's simply a maximum length of password, so any passwords longer get truncated, then that's only a little bit less secure (and no less secure than simply rejecting passwords longer than the maximum).

Edit: To explain the last parenthetical statement, let's say your system accepts passwords up to only 10 characters long (every system has a maximum, though I'm not sure why... that's another tangent). The usual method is simply to reject any password a user tries to create that is longer than that. Thus, this maximum is a known variable (a serious hacker may likely first create an account to find out the password limitations), and hackers need only to try passwords that long or shorter.

On the other hand, if the system accepts passwords of any length, but quietly truncates them, it would be slightly harder (but still not impossible) to figure out that that was going on. So if you consider more obscurity to be more secure, then the truncation method is actually more secure than the rejection method... unless both are being attacked by someone who is unaware of the maximum... then the truncation method would be slightly less secure if the attacker starts with longer passwords.

As @nobody pointed out, the situation where someone is relying on the length of their password to provide their security (as in pass phrases), them not knowing it's being silently truncated greatly reduces the security, since the password they thought was secure, "Passwords often 16 variable wrench sanctification for 53 sets behind morbid technicalities!" ends up getting truncated to a very insecure one, "Passwords "

Answer 2

A brute force attack is started by composing word containing few characters, so password is tried before password123. But for a dictionary attack this might be disadvantageous since JuliusCaesar might be accepted instead of JuliusNobody. Maybe the dictionary could contain only the long version of the word. I think if a user knows that they have fewer characters available they choose a more random password. The password could also be weakened, for example if someone uses the best friend full name and it get truncated to the first name only, obviously the password becomes more common. As a positive side the attacher needs to consider more possibilities. I would reject passwords that are too long directly in the interface, this strategy also removes additional work from the server.

Answer 3

This scheme is secure.

First off let me address a false claim made by another answer. This system does not need to forego hashing or store the length of the password. It could simply hash all prefixes of the entered password and test if any matches. Of course this implementation could be slow and storing the length solves that problem. But...

Storing the length of a password gives up very little security. If an attacker can crack the password given the length, the attacker could run the cracking algorithm with all lengths up to, say, 20 for a modest factor of 20 additional effort (realistically much less because all short passwords could quickly be attempted). So the length of a password may as well be stored (or even made public).

Now onto the security of this approach.

I will give a reduction showing that if your prefix approach is insecure, so is the standard approach of requiring an exact match. Suppose an attacker can break your approach. If you use a cryptographically secure hash function, this realistically means the attacker can somehow guess a password p' having a prefix that is the real password p. But if the attacker can guess p', given the standard approach of requiring an exact match, the attacker could try every prefix of every guessed password, eventually obtaining p with a small additional factor of effort.

The security of this scheme should not be surprising. We can use a heuristic to estimate how much security we lose by allowing an attacker to guess passwords longer than the real password. Suppose passwords are drawn uniformly from an alphabet of size x. Then given that the password has length y, the probability of a particular password p being selected has probability x^(-y). On the other hand, if p has length y, the probability of selecting a password of length at least y with prefix p is also x^(-y) by symmetry on the y-length prefix. So an attacker doesn't gain anything by guessing longer passwords and hoping the prefix is correct.