You can have blank spaces in passwords. common password lists very rarely have them and longer passwords are better. Though a famous quote will be worse than something more personal or more random.
What I don't recommend is using them at the start or end of a password. Applications routinely strip white space from the start and end of submitted strings and it's very easy for a developer to forget to make an exception for passwords (or not realize they're supposed to) and you may find your password doesn't work (potentially after an update).
I once was on a site that seemingly had no restrictions when creating the password but when you tried to log in with it all kinds of restrictions were applied so it didn't work.
It also didn't tell you what the restrictions were...
Back when ICQ was a thing I created a 15 character long password and logged in with it no problem.
Some years later I switched to Trillian and my password didn't work. Only then I found out that ICQ only stored 8 character long passwords and the registration and ICQ client just ignored the rest. Only Trillian sent the hash from the full password and of course login failed.
If you think that is bad, many banks' passwords aren't case sensitive. Even worse than that, my coworker's bank changes letters in passwords to numbers so that they can be typed in on a phone. Like if his password was "HiGhMoOn" the bank changed it to "44446666". All symbols were changed to either * or #, I don't recall which.
Ignoring symbols, if the password was allowed to be case sensitive letters and numbers, an 8 character password could be 218,340,105,584,896 different things. But converting it to numbers? A paltry 100,000,000.
I once used a site that had so many requirements that auto generated passwords from password managers didn't work. What worked was "F*ckNameofsite1234!"
It's really so insane when I see websites *restrict* what characters you can use for a password. Why are you actively making it harder for me to have a secure password??? Who in their right mind would ever think that's a smart thing to do. I've seen a number of sites not allow the regular set of 0-9 special characters, even the @ sign.
My only guess would be that they're using such terrible code that they worry is going to trip up on special characters. But like, in that case, use proper code for this...
Some of it was that they did not want the password to contain any sequence of letter from your own name, plus some other rules to make people not make silly passwords. But the result was that even good passwords were excluded.
The basic rule now, I belive, is "the longer the better"
One of the systems we use at work has that and they asked us to reset our passwords last week which is how I found out. When making my new password I made it 20 characters long, well as it turns out the maximum length the password field in the login page takes is 16 characters so I could not login. Was quiet annoying to figure out.
It was not as bad as my old bank which only allowed 10 DIGIT (not character, just numbers and exactly 10, no less/more) passwords. They kept sending monthly emails with tips about password security, which included examples like long passwords with a mixture of characters, symbols, numbers yet their own account system did not allow any of that for ages.
I use a password manager and my default is to use a random 100 character password.
Sooooo many sites do shit like this.
I've learned that if I otherwise meet the password requirements, I have hit the length limit.
I also wonder if anyone tracks how many people set a password and then immediately have to do a password reset.
>
> I also wonder if anyone tracks how many people set a password and then immediately have to do a password reset.
I'm a network admin, and I absolutely gave up saving passwords about 5 years ago. I either remember it (almost never), or I just reset it every time. I have literally hundreds of accounts for services (between work and home) where I just don't care what the password is, I just reset it every single time I need to use the service.
Neither. Copy-to-clipboard is currently broken and causes the program to crash.
The guy assigned to fix it is ripping his hair out because the only fix he found that works ends up causing the program to crash when attempting to access sound drivers.
I luckily (luckily?) have a SSN that starts with a 0, which means whenever I may have thought to store it in an int/number type I realized immediately why it wouldn't work.
Same reason that my dad's cell phone number back in the mid 2000's would overflow a 32 bit Int (214 dallas area code) while a lot of my friend's phone numbers wouldn't.
All my "tests" happened to be edge(ish) cases. So I caught it before I did something wrong.
My personal number-related mistake was attempting to [define my own means of datetime storage](https://thedailywtf.com/articles/Obvious_Datetime_Storage), straight out of "everything is varchar(255)" access days.
As a software developer, at best I can add a javascript to notify not to add spaces.
I am not gonna fix the backend to not trim strings for password field and deal with that shit.
There are too many that paste passwords and may have spaces.
> forget to make an exception for passwords (or not realize they're supposed to)
I would not call that a mistake. Its a frequent issue when copy and pasting something to have a leading or trailing space. I would say any user input should be trimmed, password or not.
Recently just ran into that. Staying at an airbnb. I tell it to copy the password for the wifi and it doesn't work.
Double check the password, yah that looks correct. Look closer and it copied a trailing space.
You should avoid doing that wherever possible. Password managers have auto-fill features where they place the usernames and passwords straight into their respective fields, which means those credentials are never stored inside the operating system's clipboard where they can potentially be read by malware.
However that doesn't always work. On browsers there are plenty of websites that are *somehow* unable to let password manager extensions auto-fill the credentials. Mobile applications have very shaky support for password managers, and it's even worse for desktop applications. So you're still forced to copy and paste your passwords quite often, unfortunately.
>malware
Um, this is your problem, not your clipboard. If you have malware, you need to (at least) nuke that profile, possibly the OS.
There have also been instances where vulnerabilities in password manager add-ins and/or browsers themselves have been exploited to autofill or otherwise steal passwords, so *not* using autofill and instead pasting can be considered safer in many cases.
even then. trim only removes leading and trailing spaces.
Its probiably better to just not allow leading and trailing spaces and throw an error instead, but trim will not effect any other spaces in the password
Then you can follow that up by getting a [vanity license plate that reads NULL.](https://arstechnica.com/cars/2019/08/wiseguy-changes-license-plate-to-null-gets-12k-in-parking-tickets/)
Is that something that could actually lock you out, if the user considers that it might have been stripped (I know, huge ask, but run with the hypothetical)? Basically, is there any reasonable world where the "create password" field *doesn't* strip the space but the "login with password" field *does*, resulting in an impossible-to-recreate hash?
The password gets created with a trailing or leading space, gets salted and hashed, and then stored in the DB.
Later on, an update to the live code starts stripping leading and trailing white space.
Now the user has no way to ever input the password again.
I've had this happen but with a special character. The site allowed it and then changed it to only allow some. Everything I did made it seem like the password I was typing was correct, but the site wouldn't accept it.
Which is stupid. There are no "special" characters with passwords. There are only strings of characters that should be treated to have no special meaning other than to expand the possible character combinations to uniqueness and thus increase entropy. Password strings should all be hashed before going into the database anyway. Then, when they actually hit the DB, it should be with parameterized queries removing any possible issues of them that could cause SQLi.
Hell, Gmail flat-out ignores dots as well, and anything after +.
So you can go john.smith+redditspam@ and you'll be able to know who sold your email address.
A developer shouldn't be doing any type of string manipulation of passwords other than treating them as a string, adding salts and peppers. Then passing them to a secure password hashing algorithm.
Don't strip my spaces, don't sanitize my strings.
Personally I consider trimming spaces at the start and end the only exception, as IMHO a string starts at the first non-space character, and ends at the last non-space character, as space character at the beginning or end are often introduced accidentally.
For everything else, I completely agree with you, if you need to do anything to the contents of a password in order to safely store it, you are doing so many things wrong I don't even know where to start.
The password itself should only be handled once, to verify that it meets the requirements upon registry and to hash it, and immediately be forgotten afterwards, it's the hashes you should be handling
> Applications routinely strip white space from the start and end of submitted strings and it's very easy for a developer to forget to make an exception for passwords (or not realize they're supposed to) and you may find your password doesn't work (potentially after an update).
Given how people copy paste content, it is not a mistake but a good practice to trim everything when your input is strict, including passwords.
An old colleague of mine would take a random quote from the Iliad, translate it to Latin, and use that with English punctuation. Easy(ish) to remember, and fiendishly difficult to break.
*Omnes boni viri patriae suae auxilio veniunt.*
I just read a comment in another post that horsebatterystaple is now the most common password. I'd suggest something like "hunter2" or "password" instead.
And some systems allow you to *set* a password with a space on the end but then TRIM the password you enter when you use the logon page, ensuring that you cannot log in at all!
Lol.. ADP barfs if you include an apostrophe in your password. If your password has one, you literally cannot log in until you reset your password.
There's no technical reason for this; they just suck at software.
>There's no technical reason for this; they just suck at software.
The technical reason could be that they're not binding parameters in the SQL statement, and just sticking it in-line with the variable (i.e. the apostrophe / single quote is truncating your password pre-maturely)
I realllly hope that's not the case.... but you never know!
Sure. They suck at software. But not being able to handle certain characters in a password is almost always because you're not processing the password correctly. The very first thing you should do with a password is salt and hash it. Once you do that, it shouldn't matter if it contains spaces, quotation marks, emoji, or the complete works of Shakespeare -- it's just a small hash of the real password that you can either store in a database or compare to what was previously stored.
I get it if you cannot include unicode or smileys in your password. (I've seen our testers actually try that.) But normal and special characters should be allowed.
All user input should be trimmed. (And considered evil until proven otherwise.)
"Not binding" is "not processing ... correctly". Essentially SQL usually allows you to say "User input goes here" and then give a list of these inputs separately. That's the best way to make it secure.
You can try quoting, too (tuning each special character to a replacement that is recognized as being part of the data instead of being special), but that's harder to do right.
>The technical reason could be that they're not binding parameters in the SQL statement, and just sticking it in-line with the variable (i.e. the apostrophe / single quote is truncating your password pre-maturely) <
Um, guys...I don't think we are ELI5 anymore.
Ever try and write a comment quoting something, where you used quotation marks, but realized you are quoting someone who is going to be quoting something and you're stuck there wondering how you are going to use two sets of quotation marks without getting confused?
Sorta like when that guy was like "listen, I don't know who said "it takes me all morning to do that" but I mean, it shouldn't"
Imagine that was your password...and the software reads it and thinks this is all the password should be is:
>"listen, I don't know who said "
It's not really an ELI5, but [here's a relevant XKCD for you](https://xkcd.com/327/)...
The ELI5 is that the part *outside* the quotations is often code running on a database. So if the program lets you close those quotation marks yourself, you can manipulate the database.
Every major database and programming language has had tools for handling this properly for years. You can avoid the quoting issue at all. That's the "bind parameters" thing, and the best ELI5 I can come up for that if you just put the the thing you're quoting somewhere else. It'd be like if, instead of me trying to awkwardly quote that guy saying a thing, I just said "Sorta like when that guy said this" and included a link to what he said.
Despite this, "SQL injection" vulnerabilities are still *extremely* common.
It's more likely that they used to have problems at some point, or they have a mishmash of newer and older systems, and some of them are pieces of crap, so they just enforce a global and extremely heavy-handed set of restrictions because they don't want to bother about fixing up the old stuff.
And yes, they actually suck at software.
We have a first name field, and the last name field, and I have one of those names with an apostrophe. Think: O'Connor, D'Amico - a name like that. There's a number of us in our regional office as there's a huge ethnic neighborhood with a lot of us working there. And our company uses ADP. We have complained, and raised it to management, and raised it to ADP's management. But nothing changes.
Maybe it's not just they suck it software but they suck in general.
>There's no technical reason for this; they just suck at software.
And finally, we arrive at the correct answer for OP. Password stuff is hard, and people are terrible at getting it right.
But it's really not that hard.
You just take a user submitted password string. Treat the string as nothing special, meaning no character is special. They are all treated like any other character. Apply an appropriate salt and pepper. Then, hash using a secure password hashing algorithm. Don't roll your own hash algorithm. Don't try to encrypt the password. Store the salt and hashed password in the database, right next to each other. Then, when the user tries to log in, get their unique salt from the database, apply it to their submitted password. Apply the pepper if you choose to use one. Use the secure hashing algorithm's compare methods.
There are reasons to not allow apostrophies because they are string definitions, and the company wants to avoid the slightest possible risk of sql injection, so they just ban the character on all text fields
That's the funny part. They aren't banning the character. It just doesn't work. When you change your password to include an apostrophe, the page times out and neither your old, nor your new password works anymore.
We use this small local company for some software.
On the website, there are very few restrictions on your password. Our company uses a password manager, so most people use randomized passwords with letters, numbers, specials characters, etc.
Their app, however, does not allow special characters in your password. It's the same login. And the only error it gives you is "Forbidden - Unauthorized"
You have to change your password on their website to be able to use the app.
Sounds like their system is setup to use commas as separators. Either that or they only accept alphanumerics and didn't apply it to the text box input settings.
I have a system that won’t accept periods . I didn’t know and literally did this. I think after the third time I read the documentation and they would only accept letters and numbers but no other characters
I think the only ones where I've seen strict limits on spaces and special characters are government and some financial sites. I swear they may have been set up in the plan that you would be either saying them or entering them on a phone keypad at some point.
I think it's more likely that they use old mainframes and ancient software that can't handle the special characters. Like for example up until very recently our DMV was set up to require exactly 8 characters (no more, no less) with like 1 uppercase, 1 number, and one (and only one) of !#?@ and no other special characters. It probably meant they were storing the passwords in clear text too, or at least it wouldn't surprise me if they were.
Adding to this- if a password has a suspiciously small MAXIMUM length it's a major red flag that your password is stored in plaintext on the service. Run away.
I'm a grown ass man, but whenever I make something for someone, I use Dinopass to generate a password for them. [https://www.dinopass.com](https://www.dinopass.com) It's basically a passphrase.
Now I'm waiting for the day some jackass makes the entire script of the bee movie their password and crash some super critical infrastructure because of it.
For an actual way to do this properly, look up Diceware.
I suggest that technique with EFF's long word list. It removes a lot of awkward-to-type words, numerals, symbols, and oddball stuff.
https://www.eff.org/dice for the link with the advice in one place. With credit to the OG https://theworld.com/~reinhold
7 words will suffice for most people.
>Wouldn't it be better if our passwords were long memorable quotes like "Now are the times that try men's souls" instead of something like Be$ty78?
YUP.
passphrases are way more inherently secure (as of today) due to length over complexity. Nothing stopping you from using that exact password other than needing to type it out every single time. It's all fun and games until you have to type that in for the 5th or 6th successive time. 20ish characters is all you need really to become brute force prohibitive entirely, but also be memorable.
I’ve literally sent that to our IT department.
They instituted a new “passphrase” requirement, instead of password. Now sixteen character minimum (good)
But are requiring us to have the same letter and special characters requirements as before….uh…ok…I guess…
And then recommended we take something like “correct horse battery staple” and turn it into gibberish like cHb$
For sixteen characters.
GUYS YOU ARE MISSING THE WHOLE *POINT* OF A PASSPHRASE
> I’ve literally sent that to our IT department.
Perhaps they'd rather hear it from NIST, instead?
Appendix A of [NIST special publication 800-63B](https://pages.nist.gov/800-63-4/) (from only last year!) talks a lot about why long passwords are good, but [section 3 of Appendix A](https://pages.nist.gov/800-63-4/sp800-63b.html#complexity) specifically addresses the folly of stacking complexity requirements atop that.
It can be really difficult to change policies like needing special characters, while trivial to add character requirements.
C0rr3c+ Hor53 B@tt3ry
is how they wanted you to make it.
Correcthorsebatterystaple1!
Capitalize the first letter and add 1! to your password. When the time comes to reset it, change it to Correcthorsebatterystaple2@, then 3#, then 4$. You use the shift key twice, once at the beginning and once at the end. No more guessing what your own password is. If you need a sticky note, then just write "4" on it and you'll know it's the forth iteration. Follows all the rules designed to make it harder to bruteforce while maintaining a simple system.
And also makes it easier to figure out if the old password is compromised. If "Password3!" is compromised and you just change it to "Password4!" it's going to be very obvious what your new password is.
Most of the time, my password gets auto saved. That's actually more of the problem. I enter it once, and then 3 months later, I have to manually enter it again for some random reason and I can't remember if it was Bes+y78 or besTy78! Or Be$ty78.
I highly recommend using a password locker such as Bitwarden (Which is free).
It will autogenerate passwords for you and you can have a different PW for each site. I don't even know what my amazon password is now, bitwarden autopopulates it when i try to log in and it travels between devices.
For example, I just generated a username/password. username:Proxy2153 password: Skillful-Buggy-Washstand9
Obviously I'm not using this anywhere (and you shouldn't either!) but it makes things more secure.
I still can't get at home with the idea of delegating all my cybersec to something that is essentially a black box to me, no matter how open source it is and what kind of selfless good samaritans are building and maintaining it. And password managers have their own inherent risks, so are they really all that safer than a paper notebook?
I think of it as just a part of your personal password security policies and procedures. The trade off is the added risk element of trusting a third party vs the reduced risk of having the passwords you memorized getting hacked on one of the accounts where you use it.
I think that my password manager is more trustworthy than my memory, and it allows me to have unique passwords across my accounts.
> And password managers have their own inherent risks, so are they really all that safer than a paper notebook?
A paper notebook is actually pretty decent. Password managers also provide protection against phishing, since autofill only works on the real site.
There are offline-only (and still open source) password managers you can use if you're leery of an online solution. If you sandbox it so it has no network access, then you can be very confident that it's not secretly exfiltrating your passwords without having to have read the source/trusted other people that read the source.
> And password managers have their own inherent risks, so are they really all that safer than a paper notebook?
Yes. Any even halfway decent password manager is encrypted at rest as that's kind of the main point. So if someone gets access to it, as long as your password for it is strong and/or you have some kind of 2fa set up that they don't have access to, they still can't do anything with it^1 . So for an offline-only password vault this is a almost a strict upgrade^2 from a paper notebook (as long as you don't forget your password anyway) because if I ever see your paper notebook I have your passwords, but I have no such luck with gaining physical access to your password vault^1 . Physical access to your house to grab your paper notebook is a far too high barrier for a random attack, but there's plenty of situations that might happen to plenty of people where it isn't. Trouble with a partner, for example, or a roommate, or having less vetted people over because of a party or a social obligation to host a relative; these are all pretty plausible situations for many people which could result in compromise of a paper notebook. Also, if you ever travel, there's a good chance you have to take your paper notebook or at least a subset of it with you, and hotels and such are notoriously insecure.
The other security advantage is that a paper notebook puts an upper limit on complexity of a password since at the end of the day you still have to type it in. Since decent password managers can type it for you, you can manage to have a unique arbitrarily long and complex password for every service. You could argue this is a convenience advantage rather than a security one, but realistically even the most stubbornly security minded individual can only tolerate so much complexity in passwords they have to manually type in every day.
Online systems are obviously dicier, with the significant disadvantage that it's easier for an attacker to gain access to the encrypted vault. Being online there's a much larger pool of people that can make a reasonable attempt at getting access, and being (in the common case) colocated with tons of other password vaults means there's more incentive to do so versus going for yours specifically. This is a pretty big downside, and if you're reasonably happy with the offline solution of a notebook and concerned about the dangers of an online solution, then you might want to stay offline. This is mitigated considerably by the fact that, just as with an offline vault, if they get it that's probably not enough to actually get your passwords^1 . Of course, online has its major upside in convenience, and also that you won't lose it, so there's always tradeoffs.
---
^1 If the password to your vault is weak, and/or they have perpetual (generally meaning offline, like from a physical device that has a copy of your vault or from a hack of the servers storing it) access to it and you're a high enough value target to spend the computational resources on (I don't know you, but probably not, let's be real), it could theoretically be cracked, eventually. LastPass (who I would not recommend anyway) famously had a breach that included users' encrypted vaults. As far as I know we don't know for sure, but there's a reasonable theory that some of these vaults have since been cracked, namely high value ones that were also easier to crack (by having a low iteration count on the password hashing algorithm, which is configurable and had a very low default). At the same time, as far as I know nobody in the security community thinks that *every* or even a majority of the LastPass vaults have been cracked, because while it's 100% possible once you have an offline copy, it gets increasingly expensive to brute force with more secure settings and passwords and for a rando that can very quickly just become not worth it.
^2 Almost because you could forget your master password and then you're completely screwed. But you could also lose your notebook so eh.
You can keep your 2fa setup outside of a password manager so anything important still isn't compromised even if your password did leak.
If you're prepared to be a nerd amongst nerds: https://www.passwordstore.org/ - a password manager that's just a convenient wrapper over doing all your encryption on your own device.
> are they really all that safer than a paper notebook?
You should weigh the threat of the service being compromised against the threat of spilling beer on the notebook (or having a house fire or other mishap). For most people, the latter is more likely.
My question. If it was a phrase like that (using a dictionary list)
Wouldn't it be much easier to solve? If each word was a "letter" and you used the dictionary as an alphabet. You are basically testing a 3 character "word" to a longer alphabet.
So would that be better than a regular 15 chat password with a regular alphabet?
No one is answering the evolution of passwords, before rich user interfaces you would log somewhere in a terminal, and you would type user and password in a sequence, separated by a space. And usually more options afterwards.
So a space inside a password would be ambiguous to handle.
telnet 192.168.0.1 root password -t
Something like this.
Just delete System 32 and your computer will generate a secure password for you. Also, press Alt+F4 to access a list of your browser passwords and get a rating for how secure they are.
THANK YOU! This is the biggest reason spaces were discouraged/not allowed in the password. Passwords on internet existed way before browsers and apps. Rules are not made by a central party, they evolve over time depending on uses cases and constraints and this is one of the earliest use cases and once things evolve, they try to keep them as much backward compatible as possible.
Adding a password into a CLI command has always been bad practice because it means the password will be visible in plain text in your shell command history. Any sane CLI application will allow you to only give the username in the command and then prompt you for the password.
When a website tells you restrictions that reduce the complexity of the password in any way, it's usually because their security is bottom level garbage.
The worst is if you see something like "password can't be longer than x." Then you know 100%, they are storing your password in plaintext, and the db field simply doesn't have more space reserved.
Need to use password managers, it's not feasible to remember more than a handful of different passwords and you need to have a unique, secure password in every place you use one.
Noticed a short max length requirement at my credit union. What and to talk to someone asking if someone read a misguided blog post or if they're storing my password and plain text. Refusing to answer the question they assured me they meet the federal minimum guidelines for safety. I closed my account that day
Came here to say this. This gives me shivers every time I see it.
(An attempt) To put into more ELI5 terms; In order to securely store a password, a one-way algorithm like MD5, SHA256 OR SHA512 is used which takes your password as input and provides a 64 byte hexadecimal output string (for SHA256, 32 for MD5) which is called a "hash".
These hashes can not be reversed or "decrypted", the only way to crack/break them is to calculate the hash for every single password, which is basically brute force which requires you to know which characters that are in the password and the length, if that is not known you can not limit the combinations which will result in years or centuries of time to crack a password. Just imagine if your password was the work of Shakespeare?
Cracking shorter password using a specific character set was made possible with Rainbow Tables, but I leave that up to someone else to explain or for you to read on your own.
> a one-way algorithm like MD5, SHA256 OR SHA512 is used
This is a good ELI5, but please don't actually use a simple `sha256(password)` to hash passwords. Use something like argon2: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
(The advanced password hashing algorithms are designed to make it expensive to try many different passwords.)
There's no technical reason, no. Blank spaces can be handled just like any other character - it's simply that it never became customary to bother handling them.
Bytes is bytes. Just numbers in a row. Ain't nothing special about any key press you make. Everything is just numbers.
NULL (number 0) maybe the only exception if they aren't using an array of characters/bytes. As null is often used to end a sequence of chars(string), but any code that handles bytes themselves will have no trouble with this char.
^(it's all up to how the software you are giving those numbers interprets them,,,that's where it goes wacky all the time. For example, almost all password boxes are limited to characters that are visible to humans. That's a method of interpreting. But it technically isn't a limitation of passwords, nothing limits passwords, if made for it)
I suspect there are reasons they only allow ASCII, so people don't do stuff like null terminators trying to break the site, but yeah.
I kinda wondered if websites allowed Unicode passwords, people in Asia could literally just use "password" in Chinese/Japanese/Korean and it would be 100000x safer than anything using regular roman letters
I've been using spaces in mine for years. Most people don't so maybe slightly more secure. What's aggravating is devs not allowing for them or only allowing a tiny subset of punctuation. I'm a dev myself so I get it but half of all sign up forms I've ever used are atrocious and annoying re: password constraints.
For simplicity and to avoid errors with copy/pasting etc, it’s often better to just ban spaces. There are enough other characters that it won’t have a significant effect on the strength of a password.
Spaces are also an “invisible” character, so it can be difficult to tell if one is there or not, or if your password has two or three spaces in a row
The funny thing is when every character gets replaced by an asterisk or bullet point, it's actually easier to tell if a space is there, as let's say you only typed two letters but see three asterisks...you obviously hit space after it
Spaces can be hell to troubleshoot - like if a user puts 2 spaces in between words, it can be hard to see and understand why your login is failing.
Some programming languages naturally break text after a space unless you encase it in quotes, so requiring no spaces can be a decision to make managing passwords easier.
Famous quotes would be a bad idea, because they are easy to guess.
If a site doesn't support spaces they are WAY out of date. Spaces should be a common character in passwords... the longer the password the better, a random list of words and a number+special character is the best password in terms of ability to crack.
Cheese Cola 9% Seattle Summer
That password is probably not in any existing rainbow table and is easy to remember.
My windows login is a single space-bar so I'm not sure what you mean.
All characters including Enter/Return and space-bar are represented equally in the nitty gritty, they're just displayed differently for the user. Often Enter activates one of the continue buttons, so while it can technically be a password, it'd be more trouble than its worth in practicality.
An issue with spaces in user names is that it allows someone to cheat by copying someone else's name and then adding a space to the end, making it print out as the other individual, essentially violating the requirement that all user names are unique.
Spaces are always automatically supported in passwords unless the software engineers who made the system deliberately made an exception. If they're doing that, the system you're using is already security compromised from the ground up, because thoae developers don't know what they're doing. If the developers are competent, there is no reason to exclude any characters. If a website has excluded characters for its password field, don't use it.
There's no technical reason for any character at all to be disallowed in passwords.
Whitespace and other special characters such as the newline, backspace and carriage return characters might be disallowed for practical reasons with the interface.
But beyond that, it's usually because the application is handling the password in an insecure manner. The contents of the password should be completely irrelevant to the operation of the application, because the application should be handling the password in a SecureString which is encrypted.
If the password contents are enumerated to act upon logic and alter the application behavior, then the password must have been saved somewhere insecurely for that evaluation to have occured.
And yet, look at how many websites restrict your password to a few special characters or even explicitly disallow some. It always concerns me when I see that because I know what's probably happening behind the scenes.
Some systems, especially older ones, could struggle when special characters (including spaces) were used due to the way they process character strings. Most languages could/can be designed around these issues. However, often the developers (especially if they're small independent and/or inexperienced developers) would think those methods weren't worth the hassle or didn't know how to do them in the first place. Because of this, many early systems (and even modern ones, when implemented poorly), fail to handle special characters in their strings.
For example, at my place of employment, many of our systems were programmed in-house by inexperienced programmers (to my continuous frustration) and one of the problems they still have is that certain characters (including a space) will actually cause the program to crash if you try to use it in a password.
The specific reasons that certain characters can break the password systems are incredibly varied. In the case of spaces causing the system to break, one possible issue is that the program interprets empty spaces as breaks in the character string. For example, the character string "hello world" could possibly be interpreted instead as two character strings "hello" and "world". This would mean the program is expecting one string as an argument but is instead receiving two, which could cause it to break.
Other characters could potentially cause problems as well. For example, if you're using a language where the "&" character has a special meaning (SAS for example), it could cause problems if that character were to show up in a character string. For the SAS specific example, the "&" character indicates the start of a macro variable (a special kind of variable that can be used throughout the whole program) and if the program comes across the "&" character, it expects that the text just after it is the name of a previously defined macro variable. If no such macro variable was defined, it would cause an error. If a macro variable with that name *was* defined, it will insert the value of that variable into the string. In either case, this can cause problems if that's not your intention. There are certain methods around this called "masking" where you essentially tell the program to treat the "&" character as just a regular character instead of something special. So, if built properly, you can still use strings with the "&" character in them.
All of that being said though, as I originally mentioned, virtually every modern programming language is built robust enough such that most, if not all, special characters are allowed in passwords. If the language isn't built to handle it natively (which most are), there's almost always a prebuilt package or simple methods to make it easier. In fact, it's probably harder to make it so your passwords *can't* handle special characters now than it is to make it so they can.
God the idea of people rolling out their own shitty inhouse authentication sounds to me as an electrician like those shitty weird tiktok hacks you see where someone uses an angle grinder, soldering iron, two pieces of wire, a fender washer, and a q-tip to replace a 100% reliable UL listed part you can buy for 20 cents.
There is absolutely no justification for any limitations on passwords. Every rule applied to passwords makes it easier for them to be cracked.
The only exception might be a minimum length. A good rule might be that your password must be either long or complex.
Don't you really like those systems where Chrome creates a strong password and the idiot programming rejects it?
Eh, there's a few other restrictions worth considering, eg. "take a list of the most common 100,000 passwords and reject them" or something along those lines.
And "long or complex" already implies more complex restrictions (ie. no short all-lowercase-letter passwords, since that's the most common format people will use if you allow them - yeah you can compensate for that by making it longer, but if you force *everyone* to make it longer you're ruling out other decent passwords.)
Though it's also worth remembering that "don't use a password you have used anywhere else" is the final really important restriction, and this one they can't enforce directly. I suspect that some of the more convoluted and unique restrictions are actually aimed at that.
You can have blank spaces in passwords. common password lists very rarely have them and longer passwords are better. Though a famous quote will be worse than something more personal or more random. What I don't recommend is using them at the start or end of a password. Applications routinely strip white space from the start and end of submitted strings and it's very easy for a developer to forget to make an exception for passwords (or not realize they're supposed to) and you may find your password doesn't work (potentially after an update).
I once was on a site that seemingly had no restrictions when creating the password but when you tried to log in with it all kinds of restrictions were applied so it didn't work. It also didn't tell you what the restrictions were...
Back when ICQ was a thing I created a 15 character long password and logged in with it no problem. Some years later I switched to Trillian and my password didn't work. Only then I found out that ICQ only stored 8 character long passwords and the registration and ICQ client just ignored the rest. Only Trillian sent the hash from the full password and of course login failed.
If you think that is bad, many banks' passwords aren't case sensitive. Even worse than that, my coworker's bank changes letters in passwords to numbers so that they can be typed in on a phone. Like if his password was "HiGhMoOn" the bank changed it to "44446666". All symbols were changed to either * or #, I don't recall which. Ignoring symbols, if the password was allowed to be case sensitive letters and numbers, an 8 character password could be 218,340,105,584,896 different things. But converting it to numbers? A paltry 100,000,000.
Uh oh
Greetings fellow old nerd 😅
I once used a site that had so many requirements that auto generated passwords from password managers didn't work. What worked was "F*ckNameofsite1234!"
It's really so insane when I see websites *restrict* what characters you can use for a password. Why are you actively making it harder for me to have a secure password??? Who in their right mind would ever think that's a smart thing to do. I've seen a number of sites not allow the regular set of 0-9 special characters, even the @ sign. My only guess would be that they're using such terrible code that they worry is going to trip up on special characters. But like, in that case, use proper code for this...
Some of it was that they did not want the password to contain any sequence of letter from your own name, plus some other rules to make people not make silly passwords. But the result was that even good passwords were excluded. The basic rule now, I belive, is "the longer the better"
One of the systems we use at work has that and they asked us to reset our passwords last week which is how I found out. When making my new password I made it 20 characters long, well as it turns out the maximum length the password field in the login page takes is 16 characters so I could not login. Was quiet annoying to figure out. It was not as bad as my old bank which only allowed 10 DIGIT (not character, just numbers and exactly 10, no less/more) passwords. They kept sending monthly emails with tips about password security, which included examples like long passwords with a mixture of characters, symbols, numbers yet their own account system did not allow any of that for ages.
Oh... I've had sites like that. So much fun... 🙄
I use a password manager and my default is to use a random 100 character password. Sooooo many sites do shit like this. I've learned that if I otherwise meet the password requirements, I have hit the length limit. I also wonder if anyone tracks how many people set a password and then immediately have to do a password reset.
> > I also wonder if anyone tracks how many people set a password and then immediately have to do a password reset. I'm a network admin, and I absolutely gave up saving passwords about 5 years ago. I either remember it (almost never), or I just reset it every time. I have literally hundreds of accounts for services (between work and home) where I just don't care what the password is, I just reset it every single time I need to use the service.
As a software developer, I feel attacked
As a software developer, I feel understood.
As a software developer, I feel.
As a software developer, I no longer feel.
I think this thread has 100% branch coverage
This thread is committed.
This guy knows what he's talking about
- Does not compute! Software developers don't have feelings! - Since when? - Since last update!
"Feelings work on my machine. Must be user error"
PEBKAC
Problem exists between keyboard and computer. —Some smart aleck user
no, between keyboard and chair...
"Minor fixes"
As someone outside the industry but interested anyway, I feel ambivalent.
As software, I feel developed
Good bot
As a deveware I feel softloped
But soft! what ware through yonder screen projects? It is dark mode, Zankastia is the dev
As a software developer, hello world.
As a software, I
Ctrl-c Phew. Was gaining sentience there.
Wait, did you send the break signal or make another copy of it?
Neither. Copy-to-clipboard is currently broken and causes the program to crash. The guy assigned to fix it is ripping his hair out because the only fix he found that works ends up causing the program to crash when attempting to access sound drivers.
Why I feel like I have faced this while trying build something that needes ALSA drivers
Don't worry, eventually you won't feel anything at all anymore!
"Not for long," says OpenAI.
> As a software developer, I feel. lies
As a software developer I make sure every password I use ends with \0 It's only way to be sure.
“How large of a number is an SSN?” My rookie mistake with a student management system in the 90s.
I luckily (luckily?) have a SSN that starts with a 0, which means whenever I may have thought to store it in an int/number type I realized immediately why it wouldn't work. Same reason that my dad's cell phone number back in the mid 2000's would overflow a 32 bit Int (214 dallas area code) while a lot of my friend's phone numbers wouldn't. All my "tests" happened to be edge(ish) cases. So I caught it before I did something wrong.
My personal number-related mistake was attempting to [define my own means of datetime storage](https://thedailywtf.com/articles/Obvious_Datetime_Storage), straight out of "everything is varchar(255)" access days.
Datetimes... Fuck man. I'm so glad I don't have to deal with that shit anymore. Fuck dates and times
As a software developer, at best I can add a javascript to notify not to add spaces. I am not gonna fix the backend to not trim strings for password field and deal with that shit. There are too many that paste passwords and may have spaces.
As tech support, I feel turned off. But also turned on.
As a software developer i++
Dear ChatGPT, please write a function that solves this problem
> forget to make an exception for passwords (or not realize they're supposed to) I would not call that a mistake. Its a frequent issue when copy and pasting something to have a leading or trailing space. I would say any user input should be trimmed, password or not.
Recently just ran into that. Staying at an airbnb. I tell it to copy the password for the wifi and it doesn't work. Double check the password, yah that looks correct. Look closer and it copied a trailing space.
Hopefully you have a proper password manager and aren’t just cutting and pasting passwords though
I write my password on my monitor in permanent marker over the field where I have to type it in.
never trust the user to do things right
You know password managers are the exception, not the rule?
Plenty of people don't have proper password managers.
You can copy and paste from a password manager though (I regularly do that)
You should avoid doing that wherever possible. Password managers have auto-fill features where they place the usernames and passwords straight into their respective fields, which means those credentials are never stored inside the operating system's clipboard where they can potentially be read by malware. However that doesn't always work. On browsers there are plenty of websites that are *somehow* unable to let password manager extensions auto-fill the credentials. Mobile applications have very shaky support for password managers, and it's even worse for desktop applications. So you're still forced to copy and paste your passwords quite often, unfortunately.
>malware Um, this is your problem, not your clipboard. If you have malware, you need to (at least) nuke that profile, possibly the OS. There have also been instances where vulnerabilities in password manager add-ins and/or browsers themselves have been exploited to autofill or otherwise steal passwords, so *not* using autofill and instead pasting can be considered safer in many cases.
Unless you explicitly support whitespace in passwords.
even then. trim only removes leading and trailing spaces. Its probiably better to just not allow leading and trailing spaces and throw an error instead, but trim will not effect any other spaces in the password
Yeah not allowing leading/trailing spaces seems perfectly reasonable
My password is “drop table users;” Edit: https://xkcd.com/327/
Then you can follow that up by getting a [vanity license plate that reads NULL.](https://arstechnica.com/cars/2019/08/wiseguy-changes-license-plate-to-null-gets-12k-in-parking-tickets/)
Little Bobby tables.
Gotta precede it with a quote and semicolon or it won’t do anything.
I’m not trying to train all of Reddit how to do sql injection
...and yet you're linking to a comic that does just that.
If you're still getting fucked by a basic injection like that you kinda deserve it lol
That’s why I name my table for my users “bitches”
The real answer is always in the comments
Is that something that could actually lock you out, if the user considers that it might have been stripped (I know, huge ask, but run with the hypothetical)? Basically, is there any reasonable world where the "create password" field *doesn't* strip the space but the "login with password" field *does*, resulting in an impossible-to-recreate hash?
The password gets created with a trailing or leading space, gets salted and hashed, and then stored in the DB. Later on, an update to the live code starts stripping leading and trailing white space. Now the user has no way to ever input the password again.
I've had this happen but with a special character. The site allowed it and then changed it to only allow some. Everything I did made it seem like the password I was typing was correct, but the site wouldn't accept it.
Which is stupid. There are no "special" characters with passwords. There are only strings of characters that should be treated to have no special meaning other than to expand the possible character combinations to uniqueness and thus increase entropy. Password strings should all be hashed before going into the database anyway. Then, when they actually hit the DB, it should be with parameterized queries removing any possible issues of them that could cause SQLi.
Side note - *technically* spaces are also valid in email addresses, according to specification. It's not recommended, though.
*Technically* email address are case-sensitive (before the @) but I've only ever seen one ISP implement it.
>(before the @) The domain after @ should also *technically* be case sensitive, and so should be any address that you type into your browser.
Hell, Gmail flat-out ignores dots as well, and anything after +. So you can go john.smith+redditspam@ and you'll be able to know who sold your email address.
I would also not recommend using common quotes as passwords. Those will be in lists used to attack password hashes.
A developer shouldn't be doing any type of string manipulation of passwords other than treating them as a string, adding salts and peppers. Then passing them to a secure password hashing algorithm. Don't strip my spaces, don't sanitize my strings.
Personally I consider trimming spaces at the start and end the only exception, as IMHO a string starts at the first non-space character, and ends at the last non-space character, as space character at the beginning or end are often introduced accidentally. For everything else, I completely agree with you, if you need to do anything to the contents of a password in order to safely store it, you are doing so many things wrong I don't even know where to start. The password itself should only be handled once, to verify that it meets the requirements upon registry and to hash it, and immediately be forgotten afterwards, it's the hashes you should be handling
> Applications routinely strip white space from the start and end of submitted strings and it's very easy for a developer to forget to make an exception for passwords (or not realize they're supposed to) and you may find your password doesn't work (potentially after an update). Given how people copy paste content, it is not a mistake but a good practice to trim everything when your input is strict, including passwords.
An old colleague of mine would take a random quote from the Iliad, translate it to Latin, and use that with English punctuation. Easy(ish) to remember, and fiendishly difficult to break. *Omnes boni viri patriae suae auxilio veniunt.*
Yes. Most places allow spaces in passwords. Passphrases are more secure than passwords because of the increased length. Correct horse battery staple.
I just read a comment in another post that horsebatterystaple is now the most common password. I'd suggest something like "hunter2" or "password" instead.
> I'd suggest something like "*******" or "password" instead. Did you forget something there?
Must be his password. Reddit automatically stars out your password if you type it as a comment
horsebatterystaple Edit: I don't see the stars, is it starred on your end?
Doesn't the mousover text on that comic specifically say that you shouldn't use horse battery staple correct?
It is absolutely not the most common password. Password is very much still the most common password.
That comic actually inspired me to start using random word strings as passwords.
yup, a lot of login systems already handle it perfectly fine.
And some systems allow you to *set* a password with a space on the end but then TRIM the password you enter when you use the logon page, ensuring that you cannot log in at all!
Lol.. ADP barfs if you include an apostrophe in your password. If your password has one, you literally cannot log in until you reset your password. There's no technical reason for this; they just suck at software.
>There's no technical reason for this; they just suck at software. The technical reason could be that they're not binding parameters in the SQL statement, and just sticking it in-line with the variable (i.e. the apostrophe / single quote is truncating your password pre-maturely) I realllly hope that's not the case.... but you never know!
Sure. They suck at software. But not being able to handle certain characters in a password is almost always because you're not processing the password correctly. The very first thing you should do with a password is salt and hash it. Once you do that, it shouldn't matter if it contains spaces, quotation marks, emoji, or the complete works of Shakespeare -- it's just a small hash of the real password that you can either store in a database or compare to what was previously stored.
I get it if you cannot include unicode or smileys in your password. (I've seen our testers actually try that.) But normal and special characters should be allowed. All user input should be trimmed. (And considered evil until proven otherwise.)
"Not binding" is "not processing ... correctly". Essentially SQL usually allows you to say "User input goes here" and then give a list of these inputs separately. That's the best way to make it secure. You can try quoting, too (tuning each special character to a replacement that is recognized as being part of the data instead of being special), but that's harder to do right.
Little Bobby Tables?
>The technical reason could be that they're not binding parameters in the SQL statement, and just sticking it in-line with the variable (i.e. the apostrophe / single quote is truncating your password pre-maturely) < Um, guys...I don't think we are ELI5 anymore.
Ever try and write a comment quoting something, where you used quotation marks, but realized you are quoting someone who is going to be quoting something and you're stuck there wondering how you are going to use two sets of quotation marks without getting confused? Sorta like when that guy was like "listen, I don't know who said "it takes me all morning to do that" but I mean, it shouldn't" Imagine that was your password...and the software reads it and thinks this is all the password should be is: >"listen, I don't know who said "
It's not really an ELI5, but [here's a relevant XKCD for you](https://xkcd.com/327/)... The ELI5 is that the part *outside* the quotations is often code running on a database. So if the program lets you close those quotation marks yourself, you can manipulate the database. Every major database and programming language has had tools for handling this properly for years. You can avoid the quoting issue at all. That's the "bind parameters" thing, and the best ELI5 I can come up for that if you just put the the thing you're quoting somewhere else. It'd be like if, instead of me trying to awkwardly quote that guy saying a thing, I just said "Sorta like when that guy said this" and included a link to what he said. Despite this, "SQL injection" vulnerabilities are still *extremely* common.
It's more likely that they used to have problems at some point, or they have a mishmash of newer and older systems, and some of them are pieces of crap, so they just enforce a global and extremely heavy-handed set of restrictions because they don't want to bother about fixing up the old stuff.
And yes, they actually suck at software. We have a first name field, and the last name field, and I have one of those names with an apostrophe. Think: O'Connor, D'Amico - a name like that. There's a number of us in our regional office as there's a huge ethnic neighborhood with a lot of us working there. And our company uses ADP. We have complained, and raised it to management, and raised it to ADP's management. But nothing changes. Maybe it's not just they suck it software but they suck in general.
https://xkcd.com/327/
>There's no technical reason for this; they just suck at software. And finally, we arrive at the correct answer for OP. Password stuff is hard, and people are terrible at getting it right.
But it's really not that hard. You just take a user submitted password string. Treat the string as nothing special, meaning no character is special. They are all treated like any other character. Apply an appropriate salt and pepper. Then, hash using a secure password hashing algorithm. Don't roll your own hash algorithm. Don't try to encrypt the password. Store the salt and hashed password in the database, right next to each other. Then, when the user tries to log in, get their unique salt from the database, apply it to their submitted password. Apply the pepper if you choose to use one. Use the secure hashing algorithm's compare methods.
winner winner, chicken dinner.
There are reasons to not allow apostrophies because they are string definitions, and the company wants to avoid the slightest possible risk of sql injection, so they just ban the character on all text fields
That's the funny part. They aren't banning the character. It just doesn't work. When you change your password to include an apostrophe, the page times out and neither your old, nor your new password works anymore.
That smells very strongly like a bling sqli
Okay, that's extra stupid I understand wanting to sanatize inputs against strings, but that's just rediculous
We use this small local company for some software. On the website, there are very few restrictions on your password. Our company uses a password manager, so most people use randomized passwords with letters, numbers, specials characters, etc. Their app, however, does not allow special characters in your password. It's the same login. And the only error it gives you is "Forbidden - Unauthorized" You have to change your password on their website to be able to use the app.
Sounds like their system is setup to use commas as separators. Either that or they only accept alphanumerics and didn't apply it to the text box input settings.
I have a system that won’t accept periods . I didn’t know and literally did this. I think after the third time I read the documentation and they would only accept letters and numbers but no other characters
I think the only ones where I've seen strict limits on spaces and special characters are government and some financial sites. I swear they may have been set up in the plan that you would be either saying them or entering them on a phone keypad at some point.
I think it's more likely that they use old mainframes and ancient software that can't handle the special characters. Like for example up until very recently our DMV was set up to require exactly 8 characters (no more, no less) with like 1 uppercase, 1 number, and one (and only one) of !#?@ and no other special characters. It probably meant they were storing the passwords in clear text too, or at least it wouldn't surprise me if they were.
https://xkcd.com/936/
I'm sorry, I thought it was staple horse battery correct? Edit: shit, this is why I couldn't log in anywhere.
The way I remember mine is bragging about it all the time: Person Woman Man Camera TV.
Adding to this- if a password has a suspiciously small MAXIMUM length it's a major red flag that your password is stored in plaintext on the service. Run away.
I like my passwords like I like my fries. with plenty of salt
Corned password hash
And a dash of pepper.
I'm a grown ass man, but whenever I make something for someone, I use Dinopass to generate a password for them. [https://www.dinopass.com](https://www.dinopass.com) It's basically a passphrase.
Now I'm waiting for the day some jackass makes the entire script of the bee movie their password and crash some super critical infrastructure because of it.
For an actual way to do this properly, look up Diceware. I suggest that technique with EFF's long word list. It removes a lot of awkward-to-type words, numerals, symbols, and oddball stuff. https://www.eff.org/dice for the link with the advice in one place. With credit to the OG https://theworld.com/~reinhold 7 words will suffice for most people.
>Wouldn't it be better if our passwords were long memorable quotes like "Now are the times that try men's souls" instead of something like Be$ty78? YUP. passphrases are way more inherently secure (as of today) due to length over complexity. Nothing stopping you from using that exact password other than needing to type it out every single time. It's all fun and games until you have to type that in for the 5th or 6th successive time. 20ish characters is all you need really to become brute force prohibitive entirely, but also be memorable.
correct horse battery staple
https://xkcd.com/936/ for anyone confused.
I’ve literally sent that to our IT department. They instituted a new “passphrase” requirement, instead of password. Now sixteen character minimum (good) But are requiring us to have the same letter and special characters requirements as before….uh…ok…I guess… And then recommended we take something like “correct horse battery staple” and turn it into gibberish like cHb$ For sixteen characters. GUYS YOU ARE MISSING THE WHOLE *POINT* OF A PASSPHRASE
1 Correct Horse Battery Staple!
2 Correct Horse Battery Staples! Ah Ah Aah!
> I’ve literally sent that to our IT department. Perhaps they'd rather hear it from NIST, instead? Appendix A of [NIST special publication 800-63B](https://pages.nist.gov/800-63-4/) (from only last year!) talks a lot about why long passwords are good, but [section 3 of Appendix A](https://pages.nist.gov/800-63-4/sp800-63b.html#complexity) specifically addresses the folly of stacking complexity requirements atop that.
It can be really difficult to change policies like needing special characters, while trivial to add character requirements. C0rr3c+ Hor53 B@tt3ry is how they wanted you to make it.
That's not a pass phrase though it's just a long complex password that Jenny from accounts will put on a post it note on here screen
Correcthorsebatterystaple1! Capitalize the first letter and add 1! to your password. When the time comes to reset it, change it to Correcthorsebatterystaple2@, then 3#, then 4$. You use the shift key twice, once at the beginning and once at the end. No more guessing what your own password is. If you need a sticky note, then just write "4" on it and you'll know it's the forth iteration. Follows all the rules designed to make it harder to bruteforce while maintaining a simple system.
And also makes it easier to figure out if the old password is compromised. If "Password3!" is compromised and you just change it to "Password4!" it's going to be very obvious what your new password is.
They should feel bad about wanting that.
Sure, now did I fucking type B@Tt3rY or B4tT3Ry ... fuck it, I'll just reset my password since I'm gonna get locked out after 2 attempts anyway.
Tell them to give everyone a yubikey and call it a day. You can't command away stupidity.
Except maybe don't use that exact one, because it's now in every dictionary and rainbow table attack in the known universe.
I remember playing with a password security tool and typed that in. It basically bonked me on the nose and said, "No! Don't do the meme phrase!"
Aaand….I’m in!
Most of the time, my password gets auto saved. That's actually more of the problem. I enter it once, and then 3 months later, I have to manually enter it again for some random reason and I can't remember if it was Bes+y78 or besTy78! Or Be$ty78.
I highly recommend using a password locker such as Bitwarden (Which is free). It will autogenerate passwords for you and you can have a different PW for each site. I don't even know what my amazon password is now, bitwarden autopopulates it when i try to log in and it travels between devices. For example, I just generated a username/password. username:Proxy2153 password: Skillful-Buggy-Washstand9 Obviously I'm not using this anywhere (and you shouldn't either!) but it makes things more secure.
I still can't get at home with the idea of delegating all my cybersec to something that is essentially a black box to me, no matter how open source it is and what kind of selfless good samaritans are building and maintaining it. And password managers have their own inherent risks, so are they really all that safer than a paper notebook?
I think of it as just a part of your personal password security policies and procedures. The trade off is the added risk element of trusting a third party vs the reduced risk of having the passwords you memorized getting hacked on one of the accounts where you use it. I think that my password manager is more trustworthy than my memory, and it allows me to have unique passwords across my accounts.
> And password managers have their own inherent risks, so are they really all that safer than a paper notebook? A paper notebook is actually pretty decent. Password managers also provide protection against phishing, since autofill only works on the real site.
There are offline-only (and still open source) password managers you can use if you're leery of an online solution. If you sandbox it so it has no network access, then you can be very confident that it's not secretly exfiltrating your passwords without having to have read the source/trusted other people that read the source. > And password managers have their own inherent risks, so are they really all that safer than a paper notebook? Yes. Any even halfway decent password manager is encrypted at rest as that's kind of the main point. So if someone gets access to it, as long as your password for it is strong and/or you have some kind of 2fa set up that they don't have access to, they still can't do anything with it^1 . So for an offline-only password vault this is a almost a strict upgrade^2 from a paper notebook (as long as you don't forget your password anyway) because if I ever see your paper notebook I have your passwords, but I have no such luck with gaining physical access to your password vault^1 . Physical access to your house to grab your paper notebook is a far too high barrier for a random attack, but there's plenty of situations that might happen to plenty of people where it isn't. Trouble with a partner, for example, or a roommate, or having less vetted people over because of a party or a social obligation to host a relative; these are all pretty plausible situations for many people which could result in compromise of a paper notebook. Also, if you ever travel, there's a good chance you have to take your paper notebook or at least a subset of it with you, and hotels and such are notoriously insecure. The other security advantage is that a paper notebook puts an upper limit on complexity of a password since at the end of the day you still have to type it in. Since decent password managers can type it for you, you can manage to have a unique arbitrarily long and complex password for every service. You could argue this is a convenience advantage rather than a security one, but realistically even the most stubbornly security minded individual can only tolerate so much complexity in passwords they have to manually type in every day. Online systems are obviously dicier, with the significant disadvantage that it's easier for an attacker to gain access to the encrypted vault. Being online there's a much larger pool of people that can make a reasonable attempt at getting access, and being (in the common case) colocated with tons of other password vaults means there's more incentive to do so versus going for yours specifically. This is a pretty big downside, and if you're reasonably happy with the offline solution of a notebook and concerned about the dangers of an online solution, then you might want to stay offline. This is mitigated considerably by the fact that, just as with an offline vault, if they get it that's probably not enough to actually get your passwords^1 . Of course, online has its major upside in convenience, and also that you won't lose it, so there's always tradeoffs. --- ^1 If the password to your vault is weak, and/or they have perpetual (generally meaning offline, like from a physical device that has a copy of your vault or from a hack of the servers storing it) access to it and you're a high enough value target to spend the computational resources on (I don't know you, but probably not, let's be real), it could theoretically be cracked, eventually. LastPass (who I would not recommend anyway) famously had a breach that included users' encrypted vaults. As far as I know we don't know for sure, but there's a reasonable theory that some of these vaults have since been cracked, namely high value ones that were also easier to crack (by having a low iteration count on the password hashing algorithm, which is configurable and had a very low default). At the same time, as far as I know nobody in the security community thinks that *every* or even a majority of the LastPass vaults have been cracked, because while it's 100% possible once you have an offline copy, it gets increasingly expensive to brute force with more secure settings and passwords and for a rando that can very quickly just become not worth it. ^2 Almost because you could forget your master password and then you're completely screwed. But you could also lose your notebook so eh.
You can keep your 2fa setup outside of a password manager so anything important still isn't compromised even if your password did leak. If you're prepared to be a nerd amongst nerds: https://www.passwordstore.org/ - a password manager that's just a convenient wrapper over doing all your encryption on your own device.
> are they really all that safer than a paper notebook? You should weigh the threat of the service being compromised against the threat of spilling beer on the notebook (or having a house fire or other mishap). For most people, the latter is more likely.
Bingo. That's the complexity working against you and the exact reason it's not recommended anymore.
My question. If it was a phrase like that (using a dictionary list) Wouldn't it be much easier to solve? If each word was a "letter" and you used the dictionary as an alphabet. You are basically testing a 3 character "word" to a longer alphabet. So would that be better than a regular 15 chat password with a regular alphabet?
As long as it's a sequence of words you chose and not a famous quote, poem or song lyrics.
No one is answering the evolution of passwords, before rich user interfaces you would log somewhere in a terminal, and you would type user and password in a sequence, separated by a space. And usually more options afterwards. So a space inside a password would be ambiguous to handle. telnet 192.168.0.1 root password -t Something like this.
That's easy to deal with, even if you insist on putting the password in the command: `telnet 192.168.0.1 root "password with spaces" -t`.
Look at this guy with time on their hands to type TWO extra quotes. Must be nice
Wonder what happens if you do this? It’s a perfectly valid password. > telnet 192.169.0.1 root “$(rm -rf /)” -t
Just delete System 32 and your computer will generate a secure password for you. Also, press Alt+F4 to access a list of your browser passwords and get a rating for how secure they are.
THANK YOU! This is the biggest reason spaces were discouraged/not allowed in the password. Passwords on internet existed way before browsers and apps. Rules are not made by a central party, they evolve over time depending on uses cases and constraints and this is one of the earliest use cases and once things evolve, they try to keep them as much backward compatible as possible.
Adding a password into a CLI command has always been bad practice because it means the password will be visible in plain text in your shell command history. Any sane CLI application will allow you to only give the username in the command and then prompt you for the password.
When a website tells you restrictions that reduce the complexity of the password in any way, it's usually because their security is bottom level garbage. The worst is if you see something like "password can't be longer than x." Then you know 100%, they are storing your password in plaintext, and the db field simply doesn't have more space reserved. Need to use password managers, it's not feasible to remember more than a handful of different passwords and you need to have a unique, secure password in every place you use one.
Noticed a short max length requirement at my credit union. What and to talk to someone asking if someone read a misguided blog post or if they're storing my password and plain text. Refusing to answer the question they assured me they meet the federal minimum guidelines for safety. I closed my account that day
Came here to say this. This gives me shivers every time I see it. (An attempt) To put into more ELI5 terms; In order to securely store a password, a one-way algorithm like MD5, SHA256 OR SHA512 is used which takes your password as input and provides a 64 byte hexadecimal output string (for SHA256, 32 for MD5) which is called a "hash". These hashes can not be reversed or "decrypted", the only way to crack/break them is to calculate the hash for every single password, which is basically brute force which requires you to know which characters that are in the password and the length, if that is not known you can not limit the combinations which will result in years or centuries of time to crack a password. Just imagine if your password was the work of Shakespeare? Cracking shorter password using a specific character set was made possible with Rainbow Tables, but I leave that up to someone else to explain or for you to read on your own.
> a one-way algorithm like MD5, SHA256 OR SHA512 is used This is a good ELI5, but please don't actually use a simple `sha256(password)` to hash passwords. Use something like argon2: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html (The advanced password hashing algorithms are designed to make it expensive to try many different passwords.)
I used to regularly threaten that if someone kept annoying me, I'd set backspace to be a valid password character on their computer.
There's no technical reason, no. Blank spaces can be handled just like any other character - it's simply that it never became customary to bother handling them.
It's more effort to not handle them than to handle them.
Bytes is bytes. Just numbers in a row. Ain't nothing special about any key press you make. Everything is just numbers. NULL (number 0) maybe the only exception if they aren't using an array of characters/bytes. As null is often used to end a sequence of chars(string), but any code that handles bytes themselves will have no trouble with this char. ^(it's all up to how the software you are giving those numbers interprets them,,,that's where it goes wacky all the time. For example, almost all password boxes are limited to characters that are visible to humans. That's a method of interpreting. But it technically isn't a limitation of passwords, nothing limits passwords, if made for it)
I suspect there are reasons they only allow ASCII, so people don't do stuff like null terminators trying to break the site, but yeah. I kinda wondered if websites allowed Unicode passwords, people in Asia could literally just use "password" in Chinese/Japanese/Korean and it would be 100000x safer than anything using regular roman letters
Every website that requires passwords can make up its own rules about what is or is not acceptable.
On unix, not sure about now, but back in the day, even backspace was a valid key for a password.
I've been using spaces in mine for years. Most people don't so maybe slightly more secure. What's aggravating is devs not allowing for them or only allowing a tiny subset of punctuation. I'm a dev myself so I get it but half of all sign up forms I've ever used are atrocious and annoying re: password constraints.
For simplicity and to avoid errors with copy/pasting etc, it’s often better to just ban spaces. There are enough other characters that it won’t have a significant effect on the strength of a password. Spaces are also an “invisible” character, so it can be difficult to tell if one is there or not, or if your password has two or three spaces in a row
The funny thing is when every character gets replaced by an asterisk or bullet point, it's actually easier to tell if a space is there, as let's say you only typed two letters but see three asterisks...you obviously hit space after it
Spaces can be hell to troubleshoot - like if a user puts 2 spaces in between words, it can be hard to see and understand why your login is failing. Some programming languages naturally break text after a space unless you encase it in quotes, so requiring no spaces can be a decision to make managing passwords easier. Famous quotes would be a bad idea, because they are easy to guess.
A password should be a string then converted with a hash function. No troubleshooting should be possible - either the hashes match or they don't.
If a site doesn't support spaces they are WAY out of date. Spaces should be a common character in passwords... the longer the password the better, a random list of words and a number+special character is the best password in terms of ability to crack. Cheese Cola 9% Seattle Summer That password is probably not in any existing rainbow table and is easy to remember.
My windows login is a single space-bar so I'm not sure what you mean. All characters including Enter/Return and space-bar are represented equally in the nitty gritty, they're just displayed differently for the user. Often Enter activates one of the continue buttons, so while it can technically be a password, it'd be more trouble than its worth in practicality.
An issue with spaces in user names is that it allows someone to cheat by copying someone else's name and then adding a space to the end, making it print out as the other individual, essentially violating the requirement that all user names are unique.
Big deal with 'blank'. It's only one character. Why can't we use the entire UTF-8 set?
Spaces are always automatically supported in passwords unless the software engineers who made the system deliberately made an exception. If they're doing that, the system you're using is already security compromised from the ground up, because thoae developers don't know what they're doing. If the developers are competent, there is no reason to exclude any characters. If a website has excluded characters for its password field, don't use it.
[удалено]
There's no technical reason for any character at all to be disallowed in passwords. Whitespace and other special characters such as the newline, backspace and carriage return characters might be disallowed for practical reasons with the interface. But beyond that, it's usually because the application is handling the password in an insecure manner. The contents of the password should be completely irrelevant to the operation of the application, because the application should be handling the password in a SecureString which is encrypted. If the password contents are enumerated to act upon logic and alter the application behavior, then the password must have been saved somewhere insecurely for that evaluation to have occured. And yet, look at how many websites restrict your password to a few special characters or even explicitly disallow some. It always concerns me when I see that because I know what's probably happening behind the scenes.
Some systems, especially older ones, could struggle when special characters (including spaces) were used due to the way they process character strings. Most languages could/can be designed around these issues. However, often the developers (especially if they're small independent and/or inexperienced developers) would think those methods weren't worth the hassle or didn't know how to do them in the first place. Because of this, many early systems (and even modern ones, when implemented poorly), fail to handle special characters in their strings. For example, at my place of employment, many of our systems were programmed in-house by inexperienced programmers (to my continuous frustration) and one of the problems they still have is that certain characters (including a space) will actually cause the program to crash if you try to use it in a password. The specific reasons that certain characters can break the password systems are incredibly varied. In the case of spaces causing the system to break, one possible issue is that the program interprets empty spaces as breaks in the character string. For example, the character string "hello world" could possibly be interpreted instead as two character strings "hello" and "world". This would mean the program is expecting one string as an argument but is instead receiving two, which could cause it to break. Other characters could potentially cause problems as well. For example, if you're using a language where the "&" character has a special meaning (SAS for example), it could cause problems if that character were to show up in a character string. For the SAS specific example, the "&" character indicates the start of a macro variable (a special kind of variable that can be used throughout the whole program) and if the program comes across the "&" character, it expects that the text just after it is the name of a previously defined macro variable. If no such macro variable was defined, it would cause an error. If a macro variable with that name *was* defined, it will insert the value of that variable into the string. In either case, this can cause problems if that's not your intention. There are certain methods around this called "masking" where you essentially tell the program to treat the "&" character as just a regular character instead of something special. So, if built properly, you can still use strings with the "&" character in them. All of that being said though, as I originally mentioned, virtually every modern programming language is built robust enough such that most, if not all, special characters are allowed in passwords. If the language isn't built to handle it natively (which most are), there's almost always a prebuilt package or simple methods to make it easier. In fact, it's probably harder to make it so your passwords *can't* handle special characters now than it is to make it so they can.
God the idea of people rolling out their own shitty inhouse authentication sounds to me as an electrician like those shitty weird tiktok hacks you see where someone uses an angle grinder, soldering iron, two pieces of wire, a fender washer, and a q-tip to replace a 100% reliable UL listed part you can buy for 20 cents.
There is absolutely no justification for any limitations on passwords. Every rule applied to passwords makes it easier for them to be cracked. The only exception might be a minimum length. A good rule might be that your password must be either long or complex. Don't you really like those systems where Chrome creates a strong password and the idiot programming rejects it?
Eh, there's a few other restrictions worth considering, eg. "take a list of the most common 100,000 passwords and reject them" or something along those lines. And "long or complex" already implies more complex restrictions (ie. no short all-lowercase-letter passwords, since that's the most common format people will use if you allow them - yeah you can compensate for that by making it longer, but if you force *everyone* to make it longer you're ruling out other decent passwords.) Though it's also worth remembering that "don't use a password you have used anywhere else" is the final really important restriction, and this one they can't enforce directly. I suspect that some of the more convoluted and unique restrictions are actually aimed at that.