Timeline for Why not allow spaces in a password?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 3, 2019 at 10:49 | comment | added | Martin Kochanski | IBM's CALL/360 timesharing services even allowed backspaces in passwords. It was intended to add security when signing in on terminals that printed what you typed. | |
| Jul 3, 2019 at 9:57 | comment | added | Aron | How can a user be expected to write down their password on a postit, if it contains whitespaces?! Madness! | |
| Jul 3, 2019 at 8:18 | comment | added | forest | and the corresponding CPU time to hash the input because you use a slow algorithm, right? Slow KDFs don't get slower if the input is large. PBKDF2, for example, will pre-hash a large password with a fast hash before performing the slow iterated HMAC on it. The bcrypt algorithm only takes a password up to 72 bytes, so larger passwords are usually hashed with a fast algorithm first. Argon2 uses BLAKE2 for this. | |
| Apr 9, 2015 at 22:31 | comment | added | Neil McGuigan | You probably shouldn't allow the null control character, as a) you can't input it in Chrome and b) Postgres will raise an exception | |
| Feb 23, 2015 at 18:22 | comment | added | Jorge Leitao |
and a "sanity" maximum length so somebody doesn't soak up 1MB of bandwidth, right: cvedetails.com/cve/CVE-2013-1443
|
|
| Dec 9, 2014 at 13:34 | comment | added | laurent | Then how about someone saving their password that includes a tab character in a text file? Then they cat the file in a terminal and the tab becomes spaces. They cannot login and contact support, waste their time, telling them they've copied and pasted the password so they are sure it's right. Again wasted money and time, and next to no added security. Of course, we don't like that users save their password in text files but it happens (especially when the super-secure system forces a password change every two days). | |
| Dec 9, 2014 at 11:47 | comment | added | Mark K Cowan | @this.lau_ : I have "hackers keyboard" on my Android devices for that very reason! | |
| Apr 25, 2013 at 2:39 | comment | added | laurent | And what about allowing "any block of data" as suggested in this question? That might be ok from your laptop, but then some day you try to login from a mobile device that won't have a tab key or the special non-printable characters you entered, and you're stuck. That's why I suggest to keep it simple - allowing more just leads to more troubles, with little added security. | |
| Apr 25, 2013 at 2:38 | comment | added | laurent | @jürgenA.Erhard, I don't entertain any thought, just stating facts. Users sometime do "the wrong thing" and we shouldn't pretend it never happens. There's a cost/benefit for any feature we implement. In this case, allowing spaces has only a very minor benefit, but a potentially high cost (in support calls or in wasted development time to find "bugs" when in fact it's just users typing their password wrong). | |
| Apr 24, 2013 at 15:07 | comment | added | Jürgen A. Erhard | @Laurent: it's the user's job to make sure they can. But frankly, what are you doing here if you entertain the thought of "sharing passwords"? | |
| Mar 16, 2013 at 12:15 | comment | added | Reactormonk | Don't forget to force the browser to actually send UTF-8 all the time, otherwise you'll have nasty bugs. | |
| Mar 16, 2013 at 5:39 | comment | added | laurent | That's looking at it from the point of view of a computer. Sure, computers don't mind what sequence of bytes they get. But what if you need to share this password between humans? | |
| Mar 15, 2013 at 21:52 | comment | added | Roy Tinker |
I would check relevant client environments for field entry limitations. For example, an online service needs to allow logins from web browsers, so input restrictions should correlate to browser form field limitations (if any). Also, rejecting newlines might prevent client platform inconsistency problems (\r\n vs \n).
|
|
| Mar 15, 2013 at 17:33 | comment | added | Jeff Ferland♦ | Well, I wouldn't call it irrelevant, but you're right that the time complexity is the same for all rounds after the first round no matter what the input is. | |
| Mar 15, 2013 at 16:25 | comment | added | Lekensteyn | Isn't hashing time is irrelevant when using key derivation methods, even if the first round takes slightly longer? | |
| Mar 15, 2013 at 16:18 | history | answered | Jeff Ferland♦ | CC BY-SA 3.0 |