It may simply be coincidence, but this past week I noticed three sites on which I was creating accounts set an arbitrary limit on the password length.
One of those sites was the new HealthCare.gov (which has a few other problems; see below).
I simply cannot deduce any reason you would limit the number of characters in a password. The worst offender forced me to no more than 8 characters!
Please enlighten me or correct me if I am mistaken about this.
The US Government’s new HealthCare.gov site does a few other peculiar things. I believe they are ridiculous and demonstrate a lack of understanding about how the web works.
The username must contain this small set of non alpha-numeric characters
The password must not contain an arbitrary set of characters; which includes underscore, even though it is not listed
I wanted to use a password that included an underscore and it was (as you can see) rejected.
I understand the desire to prevent ‘SQL Injection’, but to exclude underscore is simply stupid.
Furthermore, I like to use my Gmail account and the ‘filtering’ feature it provides. But the plus (+) is rejected when used as part of the email/username on many sites because they are using a RegExp validation copied from StackExchange (I suspect).
It annoys me too when websites put arbitrary character limits on passwords. Short passwords are insecure and easily crackable these days. The longer the password is, the more secure it can potentially be, since it can take an obscene amount of time to even attempt to crack it.
I’ve noticed that financial institutions are notorious for character limits.
And, if you publish a list of “disallowed” characters you are providing me some direct guidance on SQL injection. It is laughable when you see these character filters enforced in Javascript (in the browser) only on the client-side.
My personal favorite is $FINANICAL_INSTITUTION_YOU_HAVE_HEARD_OF that lets you have as many characters as you want but only actually looks at the first 8. Anyhow, alot of that is tied up with old systems built in pre-modern eras when space was at a premium and people were using 8-character block encryption to handle passwords. Loads of dependencies on the old stuff so updating isn’t necessarily in the art of the possible – it can actually be cheaper to have a security breach than to replace the massive mainframe system your business has been running on for 40 years now.
My general understanding of healthcare.gov is that the front end guys and the back end guys never spoke so it doesn’t surprise me that the front end has wacky password stuff that might not even match the back end.
Email validation is a pretty tricky problem. The regex that validates a full RFC addy is http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html. We pretty much don’t validate beyond splitting at @ and making sure there isn’t anything too hinkey FWIW.
If they are handling passwords correctly by hashing them then it shouldn’t matter how long the password is as the hashed version will always be the same length.
That they put a limit on the length is a good indicator that their password processing is a lot less secure than it could be.
I think you are absolutely correct, @wwb;, about the legacy systems. Those old FORTRAN and COBOL mainframes must be quite tired and worn by now.
Ultimately, you cannot “Validate” and “Verify” an email address unless you send-and-receive a message with that address.
So that silly (ugly) Regular Expression ultimately only validates that the user did not make a mistake during input of the address. And then only with respect to the format; the address could still me wrong.
Not from US, so have not checked out the healthcare.gov myself, read quite a few articles regarding it during the last months though.
From a security point of view as mentioned, the restrictions on the password does not make sense at all. Not only would you never want to run a regex on the password, SQL injection is also a mute point since it can be prevented even if the text contain it, and if it is hashed the length does not matter.
The only thing I can think of is if they need backwards compatibility with a older system, which was also mentioned earlier, but even if this was the case. The problem could have been solved in a much better manner without restricting the password for the new system.
Its also odd that they require a “username” instead of using your email or even SSN for logging in (considering its a government website), since it add another “weakness” as over time it will get more and more difficult to enter a unique username.
In the end the problem here is most probably the same issue as in every other country on government projects, unless you know the right people you wont get the project.
I can’t even come up with one Norwegian project offered by the government which you can call successful the last decade (i.e. according to the quality delivered vs. the amount of money the company got for the work).
Yes, this was something someone figured out in the late 90s. Don’t help you when you are AMEX and you’ve got mainframes running your business with software written in the early 80s with presumptions you’d make then.
The mainframes themselves have probably largely been virtualized into IBM blade centers by now. But the software hasn’t changed.
I feel the same as you, Thom!
For a long time at work we were limited to passwords of 8 characters in length.
I asked why this was and was told that it was something to do with some the old unix-based servers they were using and their integration with Active Directory.
On a similar note I was astounded to see that my web hosting provider (Strato) offers SFTP as a “pro feature” which you have to pay more for.
I would have thought it was their priority to keep their users secure.
I agree. That would be a reason to change hosts.
And I am reminded of an incident that occurred several years ago (perhaps 8-10). I was living outside DC, drove up to the Drive-In Teller at my bank - the branch where I normally do business, as a matter of fact - and after carefully counting the money I had received from cashing a check I realized the teller had given me $20 too much!
I parked the car, walked into the bank, and asked for manager. I then insisted they close ALL MY ACCOUNTS immediately.
This reminds me of [yet another] “slap our forehead” type of security policy. In the early 90s, I was involved in some of the earliest of Voice Processing systems (that’s what they were called because they did Automated Attendant and some did Voice Mail; which was not yet a common thing). One system in particular would key the user’s account on their password. Which meant two users could not have the same password (regardless of having different extension numbers!). What’s more astounding is that, while setting up your [new] voice mailbox, if you happened to choose a password that duplicated one already on the system it would say, “Please choose another password, that one is already being used”. In other words, “HEY HACKER! Here is a password to try on every extension number you can devise!”
My previous hosting company was the same - but then, their whole approach to security turned out to be something of a joke. When three of my sites were hacked, they insisted the problem must be at my end - and then they were hacked, too. I moved my sites away from them some time ago, but I’ve recently received an e-mail from them, saying they know their service wasn’t always the best, but they’ve invested in upgraded hardware and if I come back to them, my sites will now be lightening fast. Did they mention security anywhere? SFTP? Nah. Dig deep on their website, and you’ll find their “security features” listed - Password Protected Directories and Shared SSL.[/ot]
I remember that I had that limitation in a cube server, some 10 years ago at least. The actual limit was 12 characters.
It’s kind of funny to find systems that still have this problem after all these years.
I don’t understand why they limit the number of characters (at least to such a low number as 8, I could understand it if your password was much longer, like 15 or 20) but I do understand why they should publish a list of disallowed characters.
While it is true that you give some clues, it is also true that you need to guide your users of which characters they need to use to write a password that will be accepted in the system.
Off Topic:
You really closed your accounts because the teller gave you $20 more than he should? You’re harsh! Everybody can do a mistake or have a bad day
More than some, but I like to see the upper limit at 150 or more. I tend to set them at 250. Originally, this was simply the biggest round number that could fit in a VARCHAR without resorting to going to TEXT datatypes in a MySQL database back in the day. Today, since VARCHARs can be much larger than that and since it’s standard practice to hash passwords, there’s no huge reason to have an upper limit. It’s an artificial limit these days.
So, if I want to use a password like this:
ThisIsMyUb3rSecretPasswordThatN0b0dyWillEverGuess
I guess, but I use a “Pass-Phrase” on my new MacBook Pro, and it is under 40 characters and I think it’s a bear to remember and type in every time, and realistically it is very secure.
I can maybe see upping things to 60 characters, but beyond that its just silly in my humble opinion…
On a side note, could someone explain how the hashing thing works?
I know that felgall has consistently talked about how passwords get hashed to some fixed-length, and if that is so, then it makes me wonder…
Don’t you end up with tons of collisions if you take any length password and change it to, say a 40-character hash?
In your case, Force Flow, your 150 character Password would have to get condensed down to a 40-character hash, as would a 100-character Password, and so on.
If the optional raw_output is set to TRUE, then the sha1 digest is instead returned in raw binary format with a length of 20, otherwise the returned value is a 40-character hexadecimal number.
So even the shorter 32 character hash has over 340282366900000000000000000000000000000 possible values. (that’s 3^38)
True a collision is possible, but hardly likely.
For perspective the world’s current population is ~7130000000
So, Mittineague, what do you think an appropriate Password-Length Upper-Limit should be?
Do you think my choice of 8 to 40 characters is too limiting?
(I hope not, because I thought I chose a very good upper-limit, and it would be an enormous undertaking having to track down all of my places in my code where I have that set!! I used Regex…)
hosting company was the same - but then, their whole approach to security turned out to be something of a joke. When three of my sites were hacked, they insisted the problem must be at my end - and then