Allow or not allow end spaces in passwords?

I return the question: what problem do you see in considering blank?

I do not see technical problems. Maybe from UX. But there it is relative, it depends on the public.

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

Someone may say that the person can forget that there was space there and creates "headache" to manage the system because of this. It's a valid argument, but I think it should allow any character used typically. Some say it should be any Unicode.

For me these cases that the system sets too much rule is complicated, measure and go showing the strength as the person is typing. Any password force calculation should consider repeating a character next or not as something of low force.

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

In thesis ...

If your encryption algorithm accepts them, any printable data 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 behavior such as:

• Password trimming
• accept control characters as Ctrl + Backspace on Windows. Some are printable like the one I cited
• Automatic behaviors caused by spell checkers or virtual keyboards such as smartphones .

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

To help you set your policy, read this article from Jeff Atwood, co-founder of Stack Overflow, "Password Rules Are Bullshit" . It cites the most common problems of the rules that most sites adopt and how to circumvent them.

ProcessingtimeandCPUusage

Todefineyourservicepolicy,youcanuseCPUtimeandCPUtimeasanargument,sinceencryptinga100Kbdatashouldnotcostthesameasa3Mb.

Itisforthisandotherreasonsthatsomeserviceslimitthepasswordin32characters,forexample.

Copyandpaste

Whatcandegradeusabilityisthecopy-pasteofpasswords,sincewithspacesthereisnowaytodistinguish:

Suasenhaé<b>darthépaidoluke</b>Suasenhaé<b>darthépaidoluke</b>

Howwilltheuserdifferentiatethesetwoafterrendering?Thereisnowaytoknowwherethesespacesend.

Thisisanotherreasonnottoacceptspaces.

Thenoiseofthekeys

Intermsofinformationsecurity,somesaythatspacehasadistinguishablesoundonthekeyboard, (extra!) , so it should not be accepted or anything like that. If the attacker can hear the sound of the keyboard, it is much easier to break the password if he knows that it follows the pattern

XXX__XX
X: qualquer outro caracetere
_: espaço

Okay, I do not want to accept spaces in passwords. And now?

You can display a validation message saying you do not accept spaces or trim 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 it! Unintentionally. The mobile web experience is good but not perfect yet.

Particularly, and defended by UX, I do not like the idea of trimming. Alert the user and ask for the correction.

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

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

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

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

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

I think it's very common for users to receive or save passwords in an email or in a Notepad. Also, on Mobile devices it is like the broker to add some whitespace mainly at the end of the words.

Here you can do a simple test, when you click 2x in the password (newename) , select the next blank space next to it .

  

Follow your new password again, sir.

Another example is when you copy and paste the password and include the space forward of the word, as in this simple example, that you just selected next to the space after the :

So, in my view, you should allow spaces , either at the beginning or at the end, but consider these spaces at the ends as part of the validation of the password is already something to question ...

As Google disregards these spaces, you can quietly log in with yours in Gmail

  

Formerly:

Because the database used ascii, and there was a conversion problem between line breaks and space, if you have seen some sites have a "do not copy and paste your password" message to prevent the line break from appearing ...

  

Nowadays:

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

It's not really a good not to allow blanks at the edges of the password. As mentioned in Maniero's response, space must be treated with any other character.

In my answer that resulted in this question, I mentioned that " it would also be nice to delete the spaces in the borders ". I made this quote by taking into account information in general from a input field, but really in case of password you should not do this (so much so that I deleted that quote).

As the password must pass through a hash algorithm, it will not treat spaces differently from other characters, so it does not matter whether or not it has spaces before , < in> after or both.

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