Jeepers, I just changed my linked in password. I had the source for PGP back in 1993, I don't recycle passwords for anything remotely important, I use gnarly long passphrases, two factor authentication and what-all else, and I AM SICK OF IT. I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops. I'm tired of the maintenance security imposes on me, the lack of a meaningful industry certification, and on developers' insistence that I use passwords of between X and Y length and containing particular combinations of characters, numbers, etc.
Every time I read about one of these avoidable breaches, I feel tempted to gin up a class action lawsuit and force a company to either write a painfully large check to acknowledge the time and trouble it has imposed on its customers - say, about $5 each - or sell itself to its users in lieu of money. I'm not actually going to go to that effort, but sooner or later some enterprising law firm will, and I'm sure everyone here is going to be all hand-wringy about it.
We need to automate security and make it customer-centric. It is plainly too complicated to be left to individual web service providers, just as brick-and-mortar stores do not manufacture their own door locks or burglar alarms. Vendors, if you feel you can't safely outsource this job to a third party, then you need to hire full-time security monitors and start facing up to security as a line-item cost rather than a check-box you can forget about after you've put it in place.
Sorry to be ranty, but when established firms are losing millions upon millions of passwords literally on a daily basis, something is drastically wrong with the state of the art. This is a problem that can't be prettied away with CSS or smoothed over with a few tweets and blog posts.
Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords.
It indeed appears that the entire system is broken beyond repair. It seems like it is becoming the norm to expect to be exploited at some point so the de-facto preemption is to have someone to blame. As the manager of a datacenter we recently moved into said "we're here to provide a subject for you to point your finger at should there be a breach".
Many banks are encumbered by old mainframe systems that still do a lot of their computing. I don't know how much of that bubbles up through to the web interfaces we deal with, but I know many tellers and agents are still on green screens, or on interfaces that are just pretty wrappers to mainframe terminals.
I've heard that excuse from banks and such before, and, frankly, I suspect they are lying.
Oh, I fully believe that whatever ancient mainframe they are using might limit passwords to some small number of mono case characters with no funny characters allowed.
However, that would only apply to passwords for mainframe accounts. The bank is NOT going to be creating a login account on the mainframe for each bank customer. Our bank accounts are just entries in an application database on the mainframe.
If there is some kind of per customer password that the mainframe stores with the bank account data and that the online system has to provide when sending transactions to the mainframe, and it has such a limit, and the bank cannot update the application and database for some reason, that still should not be visible to the customer doing online banking.
The part the customer sees online should have its own password database, which allows good passwords, and in there it should have (encrypted!) whatever the ancient limited mainframe password is for that customer's account.
Unless the web interface itself runs on an ancient mainframe, I strongly suspect that there is no acceptable excuse for only allowing short passwords from a limited character set.
Banks are simply not very good at security, or they don't care. Hell, they insist on mailing me things that include my full credit card number, ensuring that someone who wanted to inconvenience me just has to drive by my mailbox at the right time and steal my statement. How freaking hard would it be for them to X out all but the last 4 digits. Yes, that would mean someone whose statement covers multiple cards might have a collision--so don't issue two cards with the same last 4 to two people who receive a joint statement.
The reason they don't allow special characters is to prevent situations where the customer has forgotten his password and needs to go through an excruciating verification process to access his own account.
As someone that penetration tests a lot of banks it does sometimes make it's way through. Larger and more established banks (at least in EMEA) sometimes tend to use highly distributed systems that all interoperate in very strange ways, which can sometimes lead to interesting results on web application penetration tests (e.g. there's no data store, so no SQL injection but there'll be some obscure pre-relational data store you can inject right into if you only know how to talk to it).
It's not that easy to get rid of either, the banks have to support internal applications that expect things in those formats, as well as all the unofficial apps that plug in via messaging systems and may not be aware of the other app from either end.
At last Chase allows us to have rather long passphrases (mine is well over 16 characters). Discover has the same alphanumeric-only rule, but limits you to 10 characters. 10. Then we have the silly little sites that don't retain any important information aside from a contact email that force you to have high entropy and two-byte non-latin characters in your password. (OK, so that's an exageration, but not much of one.)
Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords.
Special characters don't make as much of a difference as password length: http://xkcd.com/936/ (a comic that must appear on any password-related thread). According to the XKCD analysis, an 8 character password based mostly on letters with some numbers and symbols has ~28 bits of entropy, while a random four word password has 44 bits. [Edit to add: http://news.ycombinator.com/item?id=4083381 claims over 3 billion MD5 hashes a second for $1000, meaning your 28-bit password could be cracked effectively instantaneously by a high school kid buying phishing gear with stolen credit cards or a summer job].
If you're an international web site, it might make sense to disallow symbols, as your customers may not be able to enter their chosen symbols when traveling internationally.
The short XKCD password is based on a dictionary word, making it vulnerable to intelligent brute force (oxymoron of the day).
I imagine the calculation goes something like this:
1/50000 Likelihood of a particular uncommon word
1/8 Substitute up to three letters for numbers
1/2 Initial capital or initial lowercase
1/32 Add a punctuation character at the end
1/10 Add a digit at the end
1/2 Possibly swap punctuation and digit at the end
----------------------------------------------------------
1/512000000 Resulting probability
-28.93157 log2(1/512000000) -- number of bits of entropy
So, if e.g. XKCD assumed only 25000 uncommon words to choose from, that would give ~28 bits of entropy.
Thanks for the thorough answer! I originally missed the part about using a real word as the base.
For my passwords, I use 8 character random strings so hopefully I am a little safer. Although, as I'm learning from all of these password leak debacles, you are only as secure as the systems using those passwords.
I also have Chase and have heard the explanation for not allowing symbols in passwords to be that they are harder to grep out of logs if someone is keylogging you. Seems like BS to me, but either way is is extraordinarily frustrating to not be able to use a strong password for your bank.
Something even more ridiculous Chase does is assign a default pin of '3210' to checking accounts.
My (German) bank only allows passwords up to 5 characters.
When I ranted about it on twitter some IT guy from a local branch commented about that is totally enough since they do an hour lockout after 3 wrong tries.
o Your German bank may have your password stored in an Utimaco/Sophos Hardware-attack-resistant keysafe, not hanging out in some linux hash file.
o If they lock you out after 3 tries, and the keyspace is [a-zA-Z0-9] - that's 916,132,832 combination, and only three attempts to get it right before being locked out.
On the surface, it sounds much less secure, but, depending on their procedures and hardware, it might be significantly more secure than a 9 character password that goes into a hash file that is software accessible.
Of course - better case - is a Hardware key safe that lets me store my 30 character 1password random password.
I receive spam (not marketing crap, but pump-and-dump penny stock fraud spam) at an email address I created only for use at TD. Either they sold their email database to spammers, or they got hacked and failed to disclose it.
> I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops.
MythBusters looked at fingerprint scanners in episode 59, "Crimes and Myth-Demeanors 2". They were able to easily bypass both the cheap consumer models and an expensive professional one with advanced features that supposedly check for body heat and a pulse to make sure you aren't using a fake finger.
Another problem with biometrics: it allows unapproved sharing of identity information. If I use a fingerprint or iris scan or some such to identify myself to entity X and to entity Y, then even if I'm using different names with X and Y, they could compare biometric data and correlate my identities.
All they needed was a photocopy of your thumb-print that was licked, stuck to your thumb, and applied to the scanner. If it was 'warm' enough and had some kind of pulse, you were in.
The "Jell-O finger", made much the same way, using a standard electronic board etched to make an inverse thumb-print also worked freakishly well.
On the other hand, it's much harder to crack a hashed thumprint image.
[edit]
evan_ is right, you don't hash scan images. The question is, how much usable bits of entropy you can extract from a thumbprint scan? Anyway, I retract my main point.
Definitely. A 256 x 256 pixel grayscale image (8 bits per pixel) is half a million bits of entropy... try cracking that on your botnet!
Although the real entropy of thumbprint images is likely to be much smaller, considering that they share many simliar pixels... but it's still unimaginably huge compared to a short alphanumeric password.
Draw a picture on a piece of paper. Sign it, write your name, arbitrary words, whatever. Hold it up to a camera.
Could something like this be made to work? Work in the sense that a variety of cameras could read the same "password"? I guess QR codes have a fair bit of redundancy built-in...
And the 11th time? I think I've had significantly > 10 sites I use have major password leaks. And I just turned 26 - my 10 fingers (ok, 20 with toes) would need to last a lifetime for this to be a viable solution.
I'd be more concerned about government mandated fingerprinting. Using public key authentication, it would be possible to make biometric keys nigh impossible to steal (such that they don't ever exist on disk in any form whatsoever.) However, they're really easy to steal if you can ever get physical access to the person or any personal records that happens to record said information.
You can get rid of a huge amount of password-related frustration by using a good password manager (not the rinky-dink ones that browsers come built in with).
I've been very satisfied with 1Password and I can't imagine going back to not using it.
I've just spent the last couple of hours creating unique longins for every site I can remember having a login for and storing them in Keepass (opensource password safe). The Keepass database is stored on my dropbox account so it's automatically synced to all machines / devices I use.
I get the impression this is going to be a bit of a PITA, but with the rate these sites are being breached it's probably a sensible move.
FWIW, I did this a few years back (with 1Password, after having used Password Gorilla for a while). With the browser integration 1Password (and, I think keypass and lastpass) use, I think it's actually a productivity plus rather than a PITA...
Concur: I use 1password and lastpass. There are a couple of critical accounts that are actually wrong in each (non-overlapping) and a couple I still only have in my head, but overall it's a huge plus on a day-to-day basis. And it's an incredible relief to read these announcements, pull up my password for that site, and see it's 20 random characters that I know aren't useful on any other site.
Yeah, my three internet banking passwords are in my head only, as are my two dns registrar accounts - they're all 5-6 word passphrases (with non grammatical capitalisation and punctuation) for memorability. The email account that all those accounts send password resets too is two factor authenticated and not used (or published) anywhere else. (I've got hints about these phrases stored in 1Password, but not the passphrases themselves.)
Everything else is 16char upper/lower/digits/punctuation randomly generated by 1Password (except where I need t back that down for sites/services that wont accept that length/charset).
I've also got my random 16char AppleID password in my head, since I end up entering that often enough into place 1Password can't autofill.
I _think_ that's "paranoid enough" at least for now.
One thing I'd like 1Password to do, is bug me about passwords that haven't been changed in some (configurable per login) time. I'm pretty sure in 2 years (or less) I'm unlikely to consider 16char passwords "long enough".
I'm not really knowledgeable enough to rate different solutions, which is why I resorted to ranting rather than articulating a good alternative or working on one myself. Security is something that I have to do rather than something I am personally excited by, and I don't actually want to be encrypting everything for the same reason that I don't want to live in a bank vault or build a ten foot wall around my property.
I guess what I'm saying is that I will pay for a frictionless system whose operator is prepared to place a cost on failure, same way that I am willing to pay for a decent padlock or mortise lock for my physical property. It doesn't have to utterly impenetrable, but I would like the security provider to have skin in the game.
I thought openID was an excellent idea; I'm not sure why it didn't take off, maybe Google took too much of a monopolistic approach or something.
Every time I read about one of these avoidable breaches, I feel tempted to gin up a class action lawsuit and force a company to either write a painfully large check to acknowledge the time and trouble it has imposed on its customers - say, about $5 each - or sell itself to its users in lieu of money. I'm not actually going to go to that effort, but sooner or later some enterprising law firm will, and I'm sure everyone here is going to be all hand-wringy about it.
We need to automate security and make it customer-centric. It is plainly too complicated to be left to individual web service providers, just as brick-and-mortar stores do not manufacture their own door locks or burglar alarms. Vendors, if you feel you can't safely outsource this job to a third party, then you need to hire full-time security monitors and start facing up to security as a line-item cost rather than a check-box you can forget about after you've put it in place.
Sorry to be ranty, but when established firms are losing millions upon millions of passwords literally on a daily basis, something is drastically wrong with the state of the art. This is a problem that can't be prettied away with CSS or smoothed over with a few tweets and blog posts.