Allow or not allow end spaces in passwords?

Question

The @dvd answered about password validation in Javascript. In his reply, he suggested removing spaces from the ends when validating the size:

It is interesting [to validate the password size] also, to eliminate blank spaces on the edges of the string with the method .trim()

We discussed briefly on the subject, but found the field of comments too shallow for that. So I ask:

• Should we or should we not allow passwords with end spacing?
• We should consider end spaces as a password strength/length indicator?

I ask this because, as far as I’m concerned, the ideal would be store the password in an unrecoverable way however verifiable. And so, hash algorithms would only do mathematical operations with the bytes and I would have to (without the quotes)

"pizza de bacon"

is a hashed password other than (also without the quotes)

"pizza de bacon  "

So what would be the advantage of prohibiting or allowing the existence of spaces at the ends of passwords?

Answer 1

I return the question: what problem you see in considering white space?

I don’t see any technical problems. Maybe from UX. But then it’s relative, it depends on the public.

Space is a character like any other, I can’t see why it should be treated differently from a or 1 or 個, least of all because of his position. Unless the password is used somewhere that does not allow this character, for example some input control or data transmission that does not allow the use of space or even the stored password is entered in another location.

One can say that one can forget that one had space there and then create "headache" so that one manages the system because of this. It is a valid argument, but I think I should allow any character typically used. Some say it should be any Unicode.

For me these cases that the system puts too many rules is complicated, measure and show the strength as the person type. Any password strength calculation should consider the repetition of a character next or not as something of low strength.

Rules need to be informed and this lowers security, as Phelipe mentioned in his comment.

Answer 2

In thesis...

If your encryption algorithm accepts them, any data printable should be able to be part of a password, the rest is service policy.

Defining a Service Policy

You need to define a service policy to avoid strange behaviors like:

• trimming of passwords
• accept control characters as Ctrl+Backspace in Windows. Some are printable like the one I mentioned
• automatic behaviour caused by spell checkers or virtual keyboards such as smartphones.

Passwords: hard to break is different from being hard to remember

To help you define your policy, read this article by Jeff Atwood, co-founder of Stack Overflow, "Password Rules Are Bullshit". He cites the most common problems of the rules that most websites adopt and how to bypass them.

Processing time and CPU usage

To define your service policy, you can use as argument the processing time and CPU use, since encrypting a data of 100 Kb should not cost the same as a 3 Mb.

This is why some services limit the password to 32 characters, for example.

Copy and paste

What can harm usability is the copy-Paste of passwords, since with spaces there is no way to distinguish:

Sua senha é <b>darthépaidoluke</b>
Sua senha é <b>darthépaidoluke    </b>

How will the user differentiate these two after rendered? There is no way to know where these spaces end.

This is another reason not to accept spaces.

The sound of the keys

In terms of information security, some say that space has a distinguishable sound on the keyboard, (extra!), so it shouldn’t be accepted or anything. If the attacker can hear the sound of the keyboard, it is much easier to break the password if he knows it follows the pattern

XXX__XX
X: qualquer outro caracetere
_: espaço

Okay, I don’t want to accept spaces in passwords. And now?

You can show a validation message saying that you don’t accept spaces or trimming spaces (strategy that Google uses).

I understand that not using spaces can decrease the sample field of password possibilities, but allowing them can cause the user to enter a space unintentionally. That’s right! Unintentionally. The mobile web experience is good, but not perfect yet.

Particularly, and defended by UX, I don’t like the idea of doing Trim. Alert the user and ask for correction.

Also do not include 1,000 different rules for creating a password, this can harm usability. Large applications use on average 3 constraints at most.

As a power meter, one of the parameters can be how much effort a computer would take to crack such a password (!)

Answer 3

I will only contribute a more user-side-focused view and not the developer side and validation in the database itself.

Take a test first! If you’re in the Gmail for example and try to log in with your default password, but putting a blank at the beginning or end of the password the Google will ignore this space and accept the password!

All these options will be accepted "minhasenha", " minhasenha" or "minhasenha "

I believe it is very common for users to receive or save passwords in an email or a Notepad. Also, on Mobile devices is like the broker adding some White Space mainly at the end of words.

Here you can make a simple test, when you click 2x in the password (newpassword), will select together the white space that comes after her.

Follow your new password no v a s e n h to mister.

Another example is when you copy and paste the password and include the space in front of the word, as in this simple example, which ends up selected together the space after the :

So the way I see it, you yes it shall allow spaces, either at the beginning or at the end, but considering these spaces at the ends as part of password validation is already something to be asked...

Apparently Google disregards these spaces and you can log in quietly with the "your password       " in the Gmail

Answer 4

Formerly:

Because databases used ascii, and there was a conversation problem between line break and space, if you have seen some sites have a message "do not copy and paste your password" to prevent the line break appear...

Nowadays:

The pattern remained, and yes it is a practice. You can use blank space because the banks use utf8 but if it is an old system that uses ascii avoid.

Answer 5

It’s really not a good one nay allow blanks on the edges of the password. As mentioned in the Maniero response, the space must be treated with any other character.

In my reply which resulted in this question, I mentioned that "it would also be interesting to eliminate the spaces on the edges". I made this quote taking into account information in general from a field input, but really in case password not to do so (so much so that I deleted such a quote).

Since the password must pass through a hash algorithm, it will not handle the spaces differently other characters, so it doesn’t matter if you have spaces before, afterward or both.

By allowing such spaces, I do not see this as an advantage, but even as a recommendation.