Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)
Scarier still is when it's a server-side response that rejects my password for its contents...
Why: Because if they were (at least) hashing it the output from the hash would be a binary string in which case they would have to be 8-bit clean through to the DB column where the hash output resided, and then there would be no reason to care what character was in the input.
Caring specifically about a + in a password also implies that their authentication might be setup internally as a http endpoint with URL encoding of a "password=" form variable (because + is used as the escape for hex encoded characters in URL encoding).
Both, of course, imply a lack of proper secure design in their password handling.
I don't think that is true at all.
I may very well want to put a few simple rules I validate serverside, such as
1) No username in password 2) No email in password 3) No list of 100 most common passwords in password
All of which require me to look at the text for your password, none of which mean I am storing it in plaintext.
I've run into a couple of sites that reject passwords containing ', %, and other special characters that suggest there may be some truth to it.
If you're scrubbing input as if it's about to be insert into a database via SQL, then there's really only two possibilities. Either a) you're running legacy code that still does the check and does blind escaping (which has its own set of implications) or b) you really truly are storing passwords as plain text.
It's the five monkey experiment:
http://johnstepper.com/2013/10/26/the-five-monkeys-experimen...
Let's use the "filtering chars from password" example above. You can't put some special chars in password field, and you want to change that so it's doing normal hashing where special chars don't matter.
In a larger org, even changing a practice like that so that it "makes more sense" can have a big ripple effect.
You have to
* explain to someone else on the team who came up with the original process that it's flawed (and why)
* explain to other dept that they need to update their testing process (and why)
* get support dept to change their language/process
* change outbound messaging in all affected places (perhaps with code you can't touch, involving other teams)
* possibly have a flag that deals with 2 versions of data
Even if your change brings you in to line with normal/safe practices, you may have to fight multiple inane battles, spend loads of time and political capital, and at the end of the day, you'll be able to also accept a !"@+'$ in a password field? Most people will not grasp the bigger issue at play.
If a business can't handle a change like this, something is really broken in the development pipeline. Granted, that describes a lot of medium sized companies…
You can says "the process is broken" but it's also that same process that got people where they are, puts food on their table, pays for the lifestyle, and precious few people are willing to ever rock the boat at any company for anything.
Even worse when that "Security Consultant" is still a retained coworker with a fiefdom to maintain by war at all costs, a wizened old greybeard whose seniority will always trump yours, and/or your boss.
This should not harm security, but it can improve it if someone on the datapath is logging requests but does not alter them.
The only security benefit is that it offers a bit of support for those that are reusing passwords since it doesn't expose the plain text.
Not really. JavaScript crypto is fundamentally broken: an attacker, malicious server or disgruntled employee can replace server-side JavaScript and remove the client-side hashing at any time. This is, notably, why Firefox Accounts are completely and totally insecure (and hence why Sync is unsuitable for storing any private data at all).
That is: a listed-and-enforced ban on obscenities in passwords. Is there any world in which that company isn't butchering their security in some serious way? (It's Time Warner, so not a small-time deal here).
There is no reason to assume rejecting of a + means they don't hash, and browsers escape the password for you in POST/GET etc. The fact that + is used for space really isn't relevant.
(That said, I think it's pretty stupid to "validate" passwords beyond checking for "12345", "password", a min length, and other public info. e.g. your password should not be your name or date of birth. Anything any password generator spits out, so long as it meets the min length criteria, should be accepted).
It annoys me to no end when I have to hand-craft a password to stay within the silly rules of some service.
Be vocal about this! Keep complaining to the services you use that don't accept such valid passwords. Banks for example are notorious in insisting on short passwords and arcane limits on which characters to use (ING in the Netherlands limits you to 20 characters, and nobody there seems to be able to explain why).
So secure.
And they force a change every 3 months. As if a new 6 digit pass was more secure than the last 6 digit pass.
Speaking of annoying validations, my name has a hyphen in it but you'd be surprised how often that's rejected with the familiar, "Please enter a valid last name." Sigh.
Btw, almost nobody is actually storing hashes as binary blobs. Pretty much every framework I know stores either base64, or direct hex encoding of the value.
For commands, shell metacharacters like `, |, &, and $() are much more important.
Why? Assuming that you have established a secure connection with that server (i.e., HTTPS by means of TLS), then it is perfectly fine for the server to check, at the time you are setting the password, if your password confirms to the rules established. And when the password turns out to be suitable, it is okay for the password to be sent to the server as-is.
Now it goes without saying that as soon as you have picked a suitable new password, that the server will store only a (proper) hash — by using BCrypt for example. At no time is the plain text password stored anywhere, and any proper HTTP API will send the password via POST to prevent it from being logged in the server's access logs (which is where it could end up if sent as parameter via a GET request).
There are plenty of services that screw up and try to apply nonsensical rules (such as limiting the length of the password to anything less than, say, 256 characters), but in general this is done to prevent weak passwords. You can't exclusively do this client-side, because in security terms, the client cannot be trusted to actually apply the validation and to generate a proper hash; the client can be bypassed. Of course the client can and should validate any input before the server gets to it, so ideally the server need not even come into it during validation, but the server has the final word.
As user though, you have the responsibility of not reusing passwords anywhere (and you don't, because you sensibly use a password generator as you mention). Don't assume that any service handles security well.
Hopefully. When I see rules limiting passwords to 16 characters and disallowing SQL special characters, I'm having doubts.
Next day I get around to downloading and setting up their mobile app. Login and get a prompt that since it is my first time using the mobile app. They have sent me an email with a 4 digit code I need to enter before proceeding in the app. The email with the code arrives quickly and I enter the code. Proceed to get an error message "Error 400: This service is not available at this time." Ok, they must be down I'll try again later. The code is good for 24 hours. Next morning find time to try again and get the same error message except this time it also informs me that my account has been locked. Call up customer service and with scarily little information get them to unlock my account. Explain what is happening with the app and the CS rep puts me on hold. Comes back and tells me the IT folks thought it must be a problem because of my email address. "Do you have a normal email address like from Gmail, Yahoo or hotmail?" I release a great sigh and give in to the stupidity I'm about to have to navigate. I provide a gmail address. They change the email associated with my account on their end and tell me I should try again in 24 hours. I do with the same results. Call back again and the CS person puts me on hold again while she reaches out to IT. This time whoever she talks to knows the issue right away.
Turns out that when you login to the mobile app for the first time and submit the code it is actually appended to the end of your password and submits it as your password. Which if you have a password with more than 28 characters means you are exceeding the 32 character password max which causes them to return the informative, "Error 400: This service it not available at this time.", message.
It's not even proof against MITM attacks, which are the only thing it's supposed to prevent!
Have you ever heard any reasoning behind why they do this? The "best" excuse I've heard is so that customers don't forget. As if they don't have a "Forgot password?" link right there.
A friend's project decided to disallow umlauts, combined characters like ´e (can't type the correct e with accent mark), the pipe symbol and a couple more in new passwords.
Not due to plaintext storage or so, but because of customer service issues - people were bugging support all the time because they were e.g. abroad and couldn't enter umlauts or on a Mac and couldn't find the pipe symbol (it isn't written on the keyboard!)... of course, a quick direction to the Zeichentabelle in Windows helped, but what for Mac users? At least it did take a huge load off the customer service guys.
I'm looking forward to the date when some clueless user will input a UTF8 emoji as a password, given that Android and iOS keyboards now include these on special keyboards...
Looking forward? That happened a year ago and caused problems because the OS X Yosemite login screen had no way to input emoji:
http://apple.stackexchange.com/questions/202143/i-included-e...
You mean é ? :-)
Also the default configuration for a couple versions now (which I hate, but I know it benefits others) is if you hold a commonly (western) accented character, it'll suggest accents for it.
option-u and then a vowel will create {ä ë ï ö ü ÿ}
option-n and then an 'n' will create ñ
Found this out while learning Spanish since holding down keys to select their alternate was way too slow.
option-n and then 'a' will create ã
option-n and then 'o' will create õ
--
[1] Yes, I know you are OSX, but someone else reading this might not be.
By pipe, you mean "|", right?
That could be confusing to someone who doesn't know better.
Now, why would you preemptively (and explicitly) throw out a candidate password string based on its characters?
At least make the validation consistent.
I also had trouble with connecting to a wifi network with a WPA password containing an ampersand in Arch Linux using the Arch Wiki's recommended command line network manager utility (netctl, if my memory serves me correctly), and I tried all sorts of ways of escaping it and quoting it in the configuration file.
The Arch devs on IRC just told me to change my AP settings so that the wifi network doesn't use a password containing an ampersand character. Well, that would have been a good idea, but it wasn't my network, so I didn't have the ability to change its WPA password.
It means you have to execute commands through a shell. A real API would be something you could include in your program, execute a method against and get a list of objects back. Instead all these basic command are replicated in every framework.
As far as encoding properly, you're preaching to the choir, but out in the real world there is still injection attacks everywhere.
Except you don't. There is no need to involve a shell.
> A real API would be something you could include in your program, execute a method against and get a list of objects back.
So, Web APIs are not APIs?
Also, you can execute methods against command line programs, method names usually start with a dash.
Which you shouldn't. execve (and friends) will let you pass an explicit array of flags, and you should always use one of those functions if you're calling another program. No interpretation.
(There are some characters that are treated specially by shells, and require escaping - but you don't normally spawn child processes via a shell.)
Why: Because if they were (at least) hashing the password, then the output of the hash would be a fixed size token unrelated to the length of the input plaintext password, and no such arbitrary short limit would be necessary on the plaintext password itself.
It's as though the developer only ever thought of how people wouldn't meet their minimum requirements, wrapped it all in a case or switch and let the default be whatever they hadn't checked in previous conditions.... not thinking that anyone would exceed their requirements.
Very annoying and sloppy.
In reality, sometimes I'm on someone else's computer or something else comes up that I need to open my database up on my phone and type it in by hand.
For instance, I can't imagine trying to enter a 100 character password with a PS3 controller to log myself back into Netflix...
If I'm already at "it's going to take 100 quintillion years to break this hash, even if they're only using MD5", then I really don't see any security benefit to using a longer password... But there's a definite loss of usability.
In those cases where I might need to manually enter a passphrase and I can't rely on the password manager functionality, I use a pass-sentence that is both long and includes some random characters thrown in. That can still get me to 100 characters pretty easily. But those cases a fairly rare for me. I'm also only very, very rarely using a device that I don't own (ok, I do access systems I don't own frequently, but using my device... ssh, etc).
Most of the time my 100 character default doesn't give me any greater security than your 14 characters (assuming they're well constructed or random passwords) and things like multi-factor auth are often times much more important anyway. There are some times it can be useful; sometimes I can remember a 14 character password just by looking at it, even if it's random and not mine. 100 characters I can't. Since password managers can rely on things like cut and paste, rarely, but occasionally, I might accidentally paste a password somewhere I don't mean to: at 14 characters I might not notice, but at 100 I more likely will (or overrun the field and lose a piece of it anyway). At the end of the day, I have a password manager and I'm going to turn it to 11 and let it run. My personal practices are not necessarily my recommendations in this area, but they suit my needs.
Either way, my point still stands: if you build software that takes passwords and you limit the length (or can't take longer passwords), provide meaningful feedback if your requirements are exceeded... makes me wonder what else I might be able to do if you didn't expect me to exceed your password length and respond properly.
Bets on how long before those folks make the news for losing a hundred million unhashed passwords?
I can't think of a good way for a business that has an online interface and frequently handles phone calls from customers to validate that they're talking to the correct person. Asking for other personal information can be used by an attacker to compromise multiple accounts via social engineering: http://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/
Pretty much all organizations that allow phone authentication seem to be at risk of engineering attacks. The only ones that manage it send you something verifiable they can ask about like a credit card, and people who really care like the government just send an actual human to your house.
The best guess I've seen is that they might be hashing, but also having people read passwords to customer service reps. That would justify caring about rude plaintext, but it's also a terrible system.
Terrible security, sure, but at least it came from the desire for usability, not just basic encryption idiocy.
The text of the password should not persist.
I tried to explain to my boss why this was such a terrible idea and he was not hearing any of it.
The other is still not great but it’s less bad: “Thankyou for registering. Your registered password is: xxxx”. In this case they’ve just passed the user details to an emailer before (potentially) encrypting and storing them.
Neither is good, but the first is awful.
In disbelief I logged out, tried again but this time I intentionally didn't use any special characters. It worked....
Account synchronization was involved - IIRC the initial address confirmation message got thorough.
The problem here, though, is that the email sender just stripped the + and sent the content to foobar@gmail.com. That's just a totally different account, chosen without warning.
A lot of people either had hardcoded lists, or they checked the length and refused TLDs longer than 3 characters. We kept e-mailing people about it, and kept getting messages back from people who had "fixed" it by adding just us (we'd generally have pointed people to articles listing other new TLDs too, to make it clear to them that this wasn't just one TLD), or increasing the limit to 4 characters... We quickly gave up on trying to get these people to stop having useless checks and settled for just getting them to accept ours.
It's quite shocking people still haven't learnt even after the number of expansions since.
\.[A-Za-z]{2,4}$ (this is the end of the regex in Angular 1.15, it also doesn't support brackets or quotes in the local part, poor showing from Google)
At the time when they were written, gTLDs didn't exist, so the longest a tld could be was 4 characters (.info, .mobi). It's pretty piss poor futureproofing to be honest.
But it does get awkward quite a few times when having to interact with a human (customer services, hotel bookings, etc) via email or phone when they get a bit confused why their company name is my email alias....
Spelling a long alias over the phone letter by letter is especially tedious...
Also responding to emails either means I have to configure yet another sender alias, or mostly just send from my normal alias, which sometimes gets rejected or confuse whomever I interact with.
Also hate unsubscribe links that insist on sending unsubscribe email from that alias(mailman etc).
I had that problem so many times that I whipped up a quick Rails app that generates new email addresses. Type in the company name, hit submit. It uses a random project name generator gem to create something like SteelyFishSauce@<mydomain>.com, displays it on the screen, and emails "<Company name> has been associated with SteelyFishSauce@<mydomain>.com" to the spamcatcher address.
The nasty part is replying with the main address as the sender. I'd really love to have email clients with reasonable support for this usage pattern for the platforms I use, but maybe then the pattern might become popular enough to lose some of its advantages.
Originally, I wanted to create a Postfix filter based on an HMAC together with a browser extension which would simply let me generate new valid email addresses in the form of prefix.HMAC(secret, prefix)@example.com but I have never implemented it.
But I have an acquaintance who is constantly bickering and venting about this issue. If he strongly suspects that a signup form will reject his plus address, he will enter it even more fervently to prove they are idiots.
I'm firmly on the side of "Too bad. Maybe you could simply move on with your life? Just use a dash if you need sub-mailboxes"
Why are you so firm on this position when it seems to be a legitimate problem for him?
What is easier and better for your nerves? Moving to another mail provider or getting worked up for years?
Or if moving is not an option: how about stop wasting time and nerves on it? Just accept that your mail address doesn't work everywhere. There is no possible uture where you will force everyone on earth to stop mis-validating email addresses!
And I've never disputed that the problem is legitimate. I actually said in my comment!
Speaking as someone who uses + addresses to filter stuff from mostly well-known websites, I have never seen this. I have seen this a few times on old, crusty, finance websites etc. but I hardly ever need to use a + address with them anyway. (It does make me wonder about how good their internal security is, though.)
It's less common, but some websites ask you to type your email address once they realise they can't find you on record. If the "+" doesn't work in that field (server side rejected), then you can try %2B there as well.
Also, there's always https://mailhero.io/
Interestingly, though, the support email address they had hanging around at the bottom of the login page actually routed to an engineer (somewhere), which was nice, although they did claim repeatedly that the "+" character wasn't valid in an email address, which is of course not true. I was floored just to get a response from my complaint, though, even though it didn't seem likely to lead to them fixing the problem.
I find common culprits are service companies; gas, electricity, real estate websites, insurance companies etc.
EDIT: Oh, and warranties! Man warranty websites tend to suck. Samsung for instance won't let you register your product to an email with a +.