I would like to inform you that our website has a 128 bit encryption. With this base, passwords that comprise only of letters and alphabets create an algorithm that is difficult to crack. We discourage the use of special characters because hacking softwares can recognize them very easily.
I don't even need to dissect the "hacking software can recognize them very easily" in this forum. They sound like they are suggesting reducing the possible keyspace is a _good_ thing. It isn't. It really, really isn't.
The length of the password is limited to 8 characters to reduce keyboard contact. Some softwares can decipher a password based on the information of “most common keys pressed”.
This one is just so wrong as to make it hard to understand what they are saying. Ironically, _fewer_ keys, make it easier to guess based on the "common keys pressed (4 character passwords on Intercoms are easily guess based on "Wear")
Therefore, lesser keys punched in a given frame of time lessen the possibility of the password being cracked.
Still making no sense.
Moreover, American Express is committed to protecting the privacy and security of all of our Cardmembers, both on-line and off-line. We believe that our current security measures, which include our sophisticated monitoring systems to detect unusual or fraudulent card activity, provide strong, ongoing protections for our Cardmembers.
Nothing to do with passwords, and, based on the previous sentences, doesn't really inspire faith on their Sophisticated Security. I'm not saying amex doesn't have their act together, it's just not coming through in this email.
Rest assured, I have forwarded your comments to our webmaster for review. During this review, we may contact you if additional information is required.
Well, at least there is hope that the "webmaster" may come to their senses.
> With this base, passwords that comprise only of letters and alphabets create an algorithm that is difficult to crack.
Setting aside the strangely atypical abuse of ‘comprise’ (which does not take a preposition), what in the world does it mean to say that passwords create an algorithm?
As with all prescriptions, this is not universally agreed upon; Merriam Webster (the first Google hit for ‘comprise’, at http://www.merriam-webster.com/netdict/comprise) says (say?):
> Although it has been in use since the late 18th century, sense 3 [the relevant one for this discussion] is still attacked as wrong. Why it has been singled out is not clear …. You should be aware, however, that if you use sense 3 you may be subject to criticism for doing so, and you may want to choose a safer synonym such as compose or make up.
I disagree. If a password is lost on the user side, it's probably going to be due to a keylogger, phishing, or a trojan.
Requiring short passwords doesn't make the user any more vulnerable to phishing, and it may make it harder for keyloggers or trojans to identify the password. And since the bank locks your account after three wrong guesses, there is no vulnerability from brute force attacks, especially with an RSA token.
The number of people who lose their bank password from shoulder surfing or people noticing keyboard wear is probably virtually zero, so optimizing your system to prevent against these scenarios makes no sense.
* The word is out of context.
* There is usually a time delay on each side of the word.
So, even requiring that the user make it a straight forward english word provides little (no) defense against keyloggers. On the flip side, when the vendor's hash files (we are presuming at the _very_ least the passwords aren't stored in plaintext, or, the marginally better, "encrypted file") are compromised, having a broad keyspace makes cracking the passwords by brute force more difficult.
If you read the Amex email, they actually require _only letters_ - And, it's not even clear they require capitalization.
I'd love to see how quickly that hash file would fall apart. :-)
Making your password:
And if you think it's unlikely that AmEx will ever lose control of their user database, you clearly have not been paying attention the last few years.
So longer strings have their own vulnerabilities, but these may not weigh as much as the reduced keyspace of using a shorter string. You can pretty much assume that anything 6 characters or shorter has been entered in to a dictionary.
To be fair, while allowing "special characters" increases the possible keyspace, allowing them doesn't significantly increase the likely keyspace because even the people who use them don't use them in the same frequency that they use "normal" characters.
There's a difference between 64 random bits and 7 random seven bit quantities with an 8 bit random quantity inserted somewhere in the sequence. The latter is closer to 56 random bits. (Yes, I know that A-Za-z0-9 is not 7 random bits.)
Edit: Legacy COBOL, of course.
This would have all been built as a web application talking to the backend through a CICS gateway of some sort. The web app would be responsible for authenticating the user, not the legacy mainframe system.
that said, it's probably still quite expensive and this PR isn't that bad.
In fact, I've never dealt with a company that makes it easier to dispute incorrect charges on a card; It's usually a matter of calling them, to which they respond "ok, we'll take it off."
If AmEx thought the amount they'd have to spend on security upgrades would be less than the money they're losing to fraud, they'd spend it. It's almost certainly more difficult than it seems on the surface. A random confused customer service rep's mail is worth a chuckle, but it's not a smoking gun that proves widespread incompetence.
For example, let's say you are the customer, and someone gains access to AmEx's database of hashed passwords. All passwords are 8 characters long, so after a quick brute and dictionary attack, almost all of the accounts are cracked. Now, you along with all the customers get together and launch and class-action lawsuit. AmEx will only have to blurt out that they use: "RSA", "DSA", "128bit Encryption", "Monitoring" + many other security related jargon and that will be enough to get them of the hook. That's all AmEx needs to do.
They don't have to secure your data or personal information, they only have too fool most people in case of a lawsuit that they tried to secure the information. If they have that covered, they are all set.
Because almost nobody (except for HNers probably) includes security policies as the critical discriminant when shopping for credit cards, AmEx, Visa, MC and Discover others, don't really have to bother implementing any real security.
I met a guy who did that, and I definitely wouldn't bother with that. He ended up going off-grid too because the power company hated dealing with him and his cash so much. Well, his "eccentricity" might contributed to their opinion of him.
So then, if they hire one of the majority, what happens to them? Not very much. At worst, some people on Hacker News complain about it for a day or two when it becomes clear that they aren't doing their job, and they get a little bad press. At next-to-worst, someone breaks their system and commits a lot of fraud, but they can write a press release with a lot of handwaving and pretend that it's fine until it happens again. It's not as if the mainstream press is in a better position to judge the actual facts of the matter.
I phoned up my bank (HSBC in the UK) a few days ago to explain that their bank-issued Visa debit card is not secure: Verified by Visa is akin to protecting my money with a sheet of paper. Their explanation was, and I am not joking, that the system was American and so poor them can't do anything about it.
Honestly, the banks don't care. They've shifted the burden of dealing with fraud onto us consumers, but gave rubbish security tools. They have no incentive to change, until a big theft happens. Even then, I doubt they'll change their ways.
If your bank is providing a US based system with British liability rules, then you've got a real problem and I pity you.
If I found his password for this site was hunter2HN, I'm pretty sure I could guess his Facebook password...
#(%$^ -> hashleftparenpercentdollarcaret
Probably a might bit harder to crack, too.
The hypothesis that this is really because they're running very old legacy systems behind the scenes seems very plausible to me. Over a decade ago I occasionally worked with computer systems in banks and large retailers. In some cases the banks were still using computer systems for processing transactions which were more than 25 years old, and usually only one or two highly prized gurus on astronomical consultation fees knew how to run and maintain those systems.
It would be very interesting to hear the thoughts of some of the security expert HN-readers on this matter.
If the users system is compromised there is nothing you can do. Sacrificing general security for that case is silly.
The best defence to a keylogger attack is to have a secondary number vaidation alongside the password that requires you to enter a random subset of that number each time (eg 1st, 2nd, 8th).
I love my bank, their authentication is cheap, platform-independent and reasonably secure. It's definitely safe from keyloggers, because it requires access to items that are in my possession. And best of all, it's not annoying for me as a user.
The only better defence I can think is to have a user enter 3 genuine numbers from their password and 3 randomly generated numbers given to you, but it the 6 numbers are requested randomly. Requesting only random genuine numbers gives you encryption by hiding the sequence of the numbers, if you are also hiding the genuine numbers it's two levels of deceit.
For example there are tree keyboards for Spanish: "Spanish", "Spanish Variation" and "Latin American". http://en.wikipedia.org/wiki/Keyboard_layout#Spanish_.28Spai...
And usually, the computers are not correctly configurated, so to type the special characters you have to guess or try to remember where they are.
And the problem is worse when you type a password because can not see the characters.
(At work I have an "US" keyboard, but they are difficult to find here, and more expensive. At home I have a "Spanish" keyboad, but the key for typing "<" and ">" is missing, so I have to use an special keyboard driver from http://keyboards.jargon-file.org/ )
Now why would they worry about that?
...so yeah, I've always been bothered by their password hogwash. I suppose I'm glad to see that they're actually as terrible as I thought they were.
To enumerate, the password had to:
- have exactly 8 characters
- contain characters from 3 of the following 4 groups
-- lowercase letters
-- uppercase letters
-- ? . , _ - + = $ ! –
There were also some things that the password could not do:
- be a dictionary word
- contain any series of characters in your username
All of this was enforced.
Except, of course, that half the students will end up carrying their password on a piece of paper in their wallet.
Schneier may say it's ok, but to me it seems stupidly insecure, especially when you consider that we're talking about a student's university network password, and that there'll be identification in that student's wallet that allows the thief to make use of the password immediately.
That and it took far too long to some up with a password passing the description...
But they had a similar way to increase security as your online application:
Must contain 3 groups:
- numbers inserted in between normal characters
Special characters were optional but welcome.
Which is not to say it is good.
Accounts also have plenty of protection besides the password: IP is logged, if it's not the usual IP my bank asks a secret question, and after 3 failed tries it locks out the account until you phone them, succeed at getting a human on the line and explain your situation. You can't brute-force much in 3 attempts.
There was a guy by that name working for American Express though:
But the timestamp on the screenshot is recent.
This suggests it was copy-and-pasted either inside or outside AMEX.