61–70 of 111 posts
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.
No password policy is as egregious as American Express http://www.techrepublic.com/blog/security/american-express-p...
Passwords must contain 2 of each character type:
Caps alpha, lower alpha, symbol, number
Symbols can only be a handful, rather than anything goes.
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. md5('something silly' + password + 'qtjwtrb89ujq309') Now, if I were to make an authentication system again, I would use custom salt for every user, something like sha1('random1' + username + 'random2' + password + 'random3') This way, there is no way to use r…
To beat the dead horse one more time, please use per-user salts and bcrypt, scrypt, or PBKDF2 (RFC 2898). Single time hashes (even per-user salted), are no longer sufficient protection.
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 proce…
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 complai…
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.
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.)
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 j…
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.
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 abro…
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.
No password policy is as egregious as American Express http://www.techrepublic.com/blog/security/american-express-p...
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…
Double entry when setting a password, at least, is reasonable: a typo in a password field is going to be impossible for you to spot.
Double inputs tend to seduce the user to copy&paste.