Having been an Online Architect brought in for a couple of major EA projects (other than this one) I can tell you that they have a very robust and secure centralized user account system available.
The problem comes when you have so many different game teams with varying experience in online security that are allowed to basically implement it as they see fit, and basically "proxy" the account generation/creation process to that centralized user account system. While the underlying system is very capable, the individual game team's end-user offering can be less than optimal, shall we say.
This particular password issue is not an EA-wide thing, to be sure.
As an end user, I could not care less about how robust the underlying architecture is or who inside the EA hierarchy is screwing things up. Bottomline is, weak passwords are being stored as unsalted md5 hashes, which is problematic.
If your car has 6 gears, why are you only using one?
Again, it's all about the implementation. Some game teams opt to do their own storage of user information rather than rely on the remote service call to the centralized system.
In some cases, like the two projects I worked on, the central system doesn't store all of the user data you need, so you end up storing some in the local system, extending the centralized one. "Some" teams opted to build their own rather than take advantage of the one that existed. (For what it's worth, there is a lot of "build it ourselves" mentality in some teams).
This particular team have a few "interesting" things that they've done beyond the user authentication. Their authorization and entitlement implementations left more than a few of us from other teams scratching our heads as to how they opted to utilize the centralized EA service. It was less than ideal, and did cause some issues for a few other teams.
I don't want to get into it too much, but I guess if there's one message I'd like to share it's that EA is not one big company, but rather a whole bunch of individual development teams working on their own things. As much as there is an attempt to centralize a lot of knowledge and services, it's by no means a given that everyone's doing the same or right thing.
Just because one team totally screwed the pooch on stuff like this, doesn't mean others have as well.
A lot of the teams have some leeway and discretion when it comes to what technologies or internal services they use, and sometimes that's a good thing, sometimes it's not.
Even better somewhere in the EA/BFBC2 account creation process it _allows_ you to use special chars, but when you actually login via the game it fails with a useless error message ("Unable to login. Please try again."), leaving you clueless as to the reason. Googling it tells you to switch of your firewall etc.
Isn't this the password reset form on EA.com? I encountered it the other day as well.
Also, I wondered why EA doesn't use a form of openid via the user account. It has so many games, they all require EA logins, but as we've seen, different sites have different (often bad) implementations. A one-click EA openid would work wonders.
Someone heard "must validate all input", scratched his head for a while going about how to validate the password field, and thus came up with some artificial limitations? If so, it's a huge misconception about what it means to "validate" data. If not, someone's just really stupid.
This goes into the same category as validating email addresses (just go ahead and send the confirmation email and watch me not replying in case I entered a bad address, instead of complaining I can't use plus or some other allowed character in it) or my phone number (if you're picky about formatting I can already give you 01234567890 if I want so just let me, in the first place, type in a nicely formatted "+44-123 4567890" or something that I like) or asking me to provide something twice (I'll just copypaste from the first field, thanks; would be more useful if you just printed a confirmation of what I wrote onto the next page).
I went through a phase of copy/pasting double inputs. That phase ended when I copy/pasted a mistake from the first input and it caused a whole lot of hassle sorting it out.
Now I just make myself type it twice. I tell myself it's for my own protection.
An option to unmask is, IMO, the best option. Please never show passwords in cleartext by default. My thoughts on the matter: http://alanhogan.com/password-masking
asking me to provide something twice (I'll just copypaste from the first field, thanks; would be more useful if you just printed a confirmation of what I wrote onto the next page).
Asking for something (normally a password or email) twice is for your benefit -- to guard against typos. There are many typos you might miss visual confirmation of, I'm fairly certain the type-twice method is a sound one.
Asking passwords twice is quite ok--even Unix does it; it's the other things sometimes asked twice which is totally useless. Most commonly it's something like having to retype your email address. Woot?! You can already see it in plaintext so you can just correct any errors there.
Argh, no! How many people would actually bother to visually verify their address? A typo here is actually more problematic than in your password -- if you typo that, you'll be instantly aware of it and can do an e-mail reset.
If there's a typo in the e-mail field, you won't be aware of it until you forget your password and try to do a reset -- and for the majority of services, that means you are now completely locked out of your account.
Unfortunately the silent limits of the password fields are very prevalent.
I found out the hard way after I'd started to use Keepass to generate and manage my passwords.
There are even sites that have different limits for the "Change password" and "Enter password" input fields. Eg change accepts up to 30 characters but enter accepts only 20 chars.
Obviously they don't even know why it matters.
I think the developer just silently presumed that no one would enter such long passwords.
Limits on password length smell like plain text storage. Hashes tend to make the length of the password irrelevant (although some bad implementations only look at the first n characters of the string and ignore the rest), but when you store it in a relational database row you need to come up with some arbitrary limit.
I'm not saying that this is the only reason why people come up with a limit on password length, but that I can imagine that some programmers who come up with such a limit do so because of plaintext storage in a fixed length database row (which is the only quasi-technical excuse for a limit I can up with).
Myspace used to not check the length of passwords on signup, but would on changing password. You could log into the website with a long password, but whenever you tried to logon to the IM client (well, pidgin plugin), it would complain. It was a ten character limit I think.
Usually something like this is just a sanity check. 16 characters is definitely a little stingy though, but I'd wager that a very small percentage of their user's ran into this limit (mostly those pre-encrypting locally like I do), so I think we're overblowing the issue a bit.
Those character restrictions are just silly and annoying though.
The worst example that I've seen has to be the site that could only handle password per {6,12}[A-Za-z0-9] - incredible.
Oh, I remember another one that's just as annoying. This site simply chopped of your password after n characters and it never gave you any kind of warning. Took a lot of troubleshooting to find out the exact position of n.
My bank is about to roll out a new online banking system. They are requiring us to create a new password for the new system. So in order to log into the new system for the first time, they emailed us telling us to email them back a 6 digit pin to identify ourselves for the first login. My response is to start looking for a new bank.
American Express' passwords are now case-insensitive too. Incredibly, this still qualifies as a slight improvement over their previous password regime, which used a maximum of eight characters, few "special" characters accepted.
Yes, I was just going to mention banks as well. I have dealt with multiple online banking systems for major banks that enforced ridiculously low maximum password lengths and alphanumeric-only restrictions. It's one thing for Electronic Arts to have not thought through this stuff, but another entirely when you're talking about a banking system.
I have an issue with att where a complex generated password was accepted as a new password, is rejected on the initial log-in page, then accepted on a subsequent "bad username / password" page. Fun and games.
"The new password is to be chosen as a combination of alphabetics, digits and special characters. It must be eight characters long and contain one of the special printable characters (eg $ - ! : / = _). Normal alphabetic characters are case sensitive ie "a" is not the same as "A". Special characters may not appear at the beginning or end."
While it's almost the exact opposite of [0-9]{4,6}, it's extremely annoying too.
This is fairly secure for usual website password, but the requirements would throw this away:
$ openssl rand -base64 9
TjB3tbYOo1wz
Okay, it's fine when you generate a random password for each site (then store it somewhere), but if you're generating password from some one-side function from a site URI, then you have a problem.
I activated an ATM card once and the automated system told me for a PIN "Many of our customers are choosing their mother's birthday, please enter the month and day your mother was born."
So, out of a keyspace of 10,000, they were shoehorning most
of their users into a space of 365(366). I tried to enter something that was not a valid 4 digit date and the system rejected it. I had to call back and talk to a customer service rep to get a non-date PIN.
Can anyone explain why would you want a password longer than 16 characters? Even if it's unsalted, all lowercase letters and md5 hashed, it's impossible to bruteforce crack it. And people who use 16 character passwords are unlikely to have them all-lowercase-lettered so it's even worse for the crackers.
Sure, the 16 char limit may be arbitrary but even if you make it 50, tomorrow some outraged blogger will be complaining that he can't enter his 100-character password.
A better question is> Why WOULDN'T I want a password longer than 16 chars?
The longer the password, the more secure I feel, even if it's one day leaked as an unsalted MD5. And I don't care whether I can remember it because my password manager has effectively superseded my memory.
There is no reason to put an upper limit to the password length.
Actually, you're right. For some reason, I was thinking that I have to pick a limit for the database field but, of course, the password is hashed so it doesn't matter how long it is.
I use 16 letter or longer all lowercase passwords. They're easy to type and easy to remember. For example, my HN password might be ishouldbemoreproductive. It's hard to crack, but doesn't require finger gymnastics to enter.
Actually, English phrases contain very little entropy -- as little as 0.6 bits per character. This is because the rules for what constitutes a valid word or phrase dramatically reduce the number of possible characters at a given position. To look at it another way: take an arbitrary string of letters. What's the probability that it forms a valid English word? Very low. Flipping this the other way, if we know that a password is constructed of English words, we can immediately throw out a vast majority of the search space simply because it contains substrings that never appear in real English text.
Here's a better way to construct a strong, yet memorable password:
Take a full sentence, including punctuation and capitalization. Use the first letter of each word as your password. For example, "I should go on Hacker News less frequently, because I'll be more productive." becomes "IsgoHNlf,bIbmp.". We now have three character classes in what appears to be a random sequence.
(Yes, this still has patterns due to being constructed from English. But we've effectively taken a longer English phrase, with higher total entropy, and compressed it into a string that doesn't exhibit the low per-character entropy of the full words.)
Obviously, there are rules for what constitutes a valid phrase, but they are rather complex for a password cracker to check.
My computer says there are 234979 words. Pick 5 and there are 716382975036689591261090899 combos. That is actually very very close to a 15 letter alphanumeric. 62 ^ 15 = 768909704948766668552634368.
I don't doubt that IsgoHNlf,bIbmp. is a secure password. But it's a bitch to type. Especially on a phone.
Although MD5 is a little on the short side and collisions can be generated for it easily, it would still be a noteworthy breakthrough for someone to produce a primary preimage for MD5.
That's what it would take for someone to find a working password for your account given your salt and MD5 hash.
In other words, there are still no known cracking tools that can do much better than dictionary or brute force against MD5, so a very strong password is still very strong and a salted SHA-1 password would be only slightly stronger.
Long, random strings with weird characters are unlikely to be in any md5 dictionary, so you'd have to bruteforce it. MD5 is a fast algo so that shouldn't take long for short passwords, but it does provide some security. If you've chosen a strong password then bruteforcing isn't a concern, so the fact they <s>hashed instead of encrypting</s> (edit: used a weak hashing algo) won't matter.
It's better than nothing, but not much. The fact that they md5'd it at all suggests they were thinking about security, just not very hard or well.
On my pair of HD 5870's I get about 6.3 billion hashes/sec - with lowercase alphanumerics, that's up to 8 characters in about 8 minutes, 9 in 5 hours, and 10 inside a week.
My bad, that was lazy of me. I was using the words sloppily. By "encryption", I was simply trying to say, "hard to break". I know that's not what it means, and apologize for any confusion.
My biggest surprise when resetting a bunch of passwords from the Sony hack was the fact that Paypal wouldn't let me use a complex password like the one in the article (no longer than 16 [or something like that] chars, no quotation marks, etc.
For another service, I would have thought that'd be okay - annoying, but okay. But a service with access to a whole bunch of my money? Not cool.
Perhaps it's changed since, but still, the fact that it once was that way is bad enough.
ASB Bank in New Zealand allows a maximum of 8 characters for your passwords. Numbers and letters only.
That's right, all that stands between you and your account details is 8 characters.
If someone tries to transfer out over ~$200 then you get a text message on your phone - IF you've enabled that service. So it's not the end of the world, but it's still pretty terrible.
Yes, but (like most banks) I dare say they'd lock your account after 3 incorrect attempts, and you'd have to unlock it out-of-band (e.g. calling their call centre).
I don't get why passwords ever have to be within a certain length, it just makes it obvious that they're not hashing it. I had to pick one between 6-10 characters (with no symbols) for my Visa securecode the other day.
The strenght(randomness), length, transfer and storage is essential. Its the product in itself here thats limited and should allow better security for its customers.
So when talking storage... go that nice looking search field in your imap interface and type "password", any results? I guess its pleasant to never feel the need to delete any mail when you can search for it. Nice collection when attackers breach due to limitations in product.
speculation: last few years, password resets have been a far bigger user hassle then compromised accounts.
obviously companies like EA will need to react to changing conditions -- which might be challenging -- educating computer-illiterate users isn't exactly a core business competency. Implementing more secure systems server-side only addresses half the issue.
Maybe the problem of website credentials could be better solved in the browser, or by the OS.
I had a similar issue a couple of days ago. reddit let me set a password that was longer than what the login box would accept. I used the email password reset instead of firing up Chrome Inspector so I don't know if it would have worked had I got rid of the maxlength attribute on the input tag.
I really wish more companies would be publicly shamed for having poor password practices.
Just the other day I tried to change my twitter password to a password that contained a space, and it was denied. Their site doesn't allow passwords with spaces.
Nice. EA aint the only ones. My online paystub system demands 6-11 characters, and alphanumeric+a few special ones. And thats sensitiveish data. Don't worry EA is not so terrible. (ok yes they are)... calling @lolsec and friends.
DEERS/RAPIDS (the DOD contractor/employee ID system, among other things) has the best restrictions EVER:
Passwords must be exactly 14 characters - no more, no less.
Passwords must contain 2 of each character type:
Caps alpha, lower alpha, symbol, number
Symbols can only be a handful, rather than anything goes.
I can beat that. For a while my timesheet software at work let us reset our passwords to something containing special characters, but sanitized the password field of the login to remove those special characters.
Backblaze enforces a limit to password length as well. Not as short as 16 characters, but still -- in Backblaze's case, we're talking about a backup of all your personal data and keys to said data.
Shameful plug for a tool I love: use Readable. It's like Readability, in that it strips all content other than the articles text and styles it to make it more readable (larger, aesthetic font), but unlike Readability (or perhaps more correctly, like Readability used to be), it's lightning fast.
Thanks! This is perfect, I dislike that Readability redirects you to their own server. I know they have to adapt their business model, but it's killing the usability factor.
Even worse, if I remember correctly they silently truncate passwords longer than 16 characters. I wasted nearly an hour trying to log in when they started doing that.
The only reason I had a Live account was for the xbox, and one day they updated something and I suddenly couldn't log in. It took me ten or fifteen tries to figure out why my newly-reset passwords weren't working, and it took their system two or three minutes to deliver each password-reset email.
Databases are stored all over, the user creates the md5 from a string and the webpage collect. When you reverse, they only check the hash against the database.
I'm serious, I've had to reverse-engineer projects I've inherited with pre-set administrator users, and simply googling the hashes reveals the password to be "elm", "password", or "9234" or something.
As for the "special characters" not being allowed, there is a sane and logical reason behind this (but whether or not EA's developers had this in mind will remain unanswered): the ASCII set is intuitively and easily available from any keyboard setup and locale in the world. Using special characters in your login/password, characters perhaps only available through your specific locale and keyboard - people living abroad knows this problem well - puts users in the situation of not being able to access the implied service if they happen to need to when away from their personal computer, unless they know how to summon and use an IME - something not many "ordinary" users know, trust me on that one. It is my personal opinion that a user should never have to end up in this situation just because he or she isn't savvy enough. The benefit of allowing characters outside the ASCII range is obvious to most people, but the problem that comes with it seems like something no one ever thinks about.
Passwords aren't inherently safe just because you use multibyte characters or the full ASCII set, and likewise they aren't unsafe just because you don't. It's not a bad excuse at all, but with that said it's not implied that EA took the best route on this regardless of the reasons behind their design. It could definitely be better.
I would not be surprised if the subset of allowed characters was motivated by ensuring easy input cross a variety of gaming devices and console UIs. Of course, I also would not be surprised if this was due to sheer stupidity.
OMG, that's all I can say.I'm no expert on security, but the few web sites that I wrote, I intuitively tried to do something as complicated as possible... e.g.
That's better, but still horribly broken. Sha1 and md5 simply aren't adequate for secure passwords, they are still broken too quickly. You should use bcrypt. http://codahale.com/how-to-safely-store-a-password/ explains why, and links to implementations of bcrypt in many environments/languages (in the opening when he says "Use bcrypt" a hundred times).
The problem comes when you have so many different game teams with varying experience in online security that are allowed to basically implement it as they see fit, and basically "proxy" the account generation/creation process to that centralized user account system. While the underlying system is very capable, the individual game team's end-user offering can be less than optimal, shall we say.
This particular password issue is not an EA-wide thing, to be sure.