AmEx: "We discourage the use of special characters because..." | Hacker News Reader

AmEx: "We discourage the use of special characters because..."

trn.n0t.net

259 pointsjohns102 comments

Interesting - almost every single paragraph of this response is incorrect:

<-- 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.

"They sound like they are suggesting reducing the possible keyspace is a _good_ thing."

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.

That's great until someone gets access to their user database and is able to crack every password in very little time. Increasing the key space (both through longer passwords and more allowed characters) makes these sorts of attacks far more difficult.

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.

Couldn't you just salt the user database with 100 fake accounts for every one real account, so that way as soon as someone tries to log into a fake account the bank knows its system has been compromised?

They could block whatever location the fake account was accessed from, but the attacker could try one account each from lots of different locations (perhaps through a botnet). For this to be useful the bank would have to lock all account access from everywhere when a fake one was accessed.

at which point the only thing to say is "denial of service"

Additionally, the mined usernames / passwords could still be used to brute force other banking / credit card web sites.

Interesting idea, but you need to save in your database which accounts are fake accounts, so if an hacker get an access to the database he will get this information too, unless this information is saved elsewhere.

I don't understand a lot about keyloggers. How would less characters in a password make it harder to find within a keystroke log?

It's debatable whether that's even true, but the argument goes something like 'if a unique, non dictionary string pops up with some regularity on the keyboard input it is probably a password', and longer strings stand out more against the background. A 1 character string would never stand out, but a 100 character string would stand out after only two uses.

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.

Alex - while on the surface what you are saying makes sense, as one who has looked at a lot of keylogger data, I can tell you that identifying passwords is fairly trivial, even when the passwords are simple english words like "house" or "dog" (let alone "scrambled words" like "zydkgel" that basically _scream _password. Two things make it straightforward.

   * The word is out of context.  
   * There is usually a time delay on each side of the word.

Also, you usually have them typing in their username/account number near the password, another dead giveaway

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. :-)

Ironically if they made their password the same as their username it might actually make it harder to spot in a keylogger context. (But trivially easy to guess.)

Making your password:

   http://google.com

would be pretty sneaky.

And, ironically, not allowed by Amex. :-) (BTW - you are correct, even _knowing_ that the password folllows the user account - a password that is a URL would be an incredibly effective way of defeating keyloggers. At least the ones who are trying to pull data in from thousands of people. Once you are focussed on the keylog data from a _single_ stream, it's basically game over.

Can alternating mouse input help? E.g. click over to your google-search box, type in p455w0rd, then click back over to your password box and type in your password, facebook.

Could you reduce the utility of a keylogger by allowing 64 chars, say, in which to embed your password and not allowing repetition of the same keyphrase within a given period? I'm guessing most would just enter the password as the first chars and then add a different digit at the end.

You didn't even single out my favourite bit of that:

> 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?

It can take a preposition, but only in the passive form. Valid: "x comprises y"; "y is comprised of x". Invalid: "x comprises of y".

I believe that that is not correct, and that correct usage says that the whole comprises its parts, the parts compose the whole, and the whole is composed of its parts.

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.

Yep. My applied crypto class is laughing about this on our newsgroup. Just awful.

> They sound like they are suggesting reducing the possible keyspace is a _good_ thing.

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.)

The reason for the character limitation is a lot more straightforward - on the backend its stored on a very legacy system (in plaintext.. but I didn't tell you that), and to increase the length of the database field would cost 7 figures.

Wikileaks, dude...

It's COBOL, isn't it? (Not being sarcastic; that's the only system I can think of that would cost 7 figures to change a field length in the database.)

At a past job, the mainframe "copybooks" required an extra digit for certain price fields (cars never used to cost > 100K). It was a months-long project which required tons of coordination with other clients systems. One could argue that the 27 other ways the company didn't have its house in order made the project costly, but the 30+ hour flatfile data conversion was an inherent part of the plan.

Edit: Legacy COBOL, of course.

why not just throw a hash function in the middle? technically you're not increasing the search space for a brute-force attack (but that's not the goal), but you are probably slightly increasing entropy. and most of all, you avoid bad PR like this. :)

that said, it's probably still quite expensive and this PR isn't that bad.

http://benlog.com/articles/2008/06/19/dont-hash-secrets/

Interesting post. But it doesn't make the case that the title promises.

C'mon - why is the troll/joke comment being upvoted? It doesn't add much to the discussion :(

It's being upvoted because it is probably true, despite being entertainingly worded.

I'm not a fan of meaningless speculation I guess (it more saddens me this is the top comment when all the value, the best of HN, is below it....)

Because it is almost certainly true. I used to work at Amex, it wouldn't surprise me if all banks are in similar situations.

This doesn't make sense to me. Any "legacy" systems involved surely pre-date online account access by consumers. They would not have ANY password field or even any notion of a "user" in the sense of someone who is able to access a specific account.

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.

They probably keep the password in an 8-char record that used to store something else.

Why not just hash the password and use the first 8 characters of the hash? That would at least stop things from being stored in plain text.

Holy living fuck. And this is a company that basically has encryption and security tied into its basic business. I think I might have to cancel my AmEx, cause they are obviously idiots over there.

Note: they only need to have the appearance of encryption and security. When they get investigated, they can always blurt out a list of jargon word technologies they use and thus they can prove to a majority if people that they are indeed "secure". And by majority here, I mean mostly judges, attorneys and the media. Yes, this is the same "security theater" that TSA is engaged in.

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 seriously doubt others are much better, so unless you're planning on withdrawing from the modern banking system, I wouldn't bother..

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.

I work for a bank, and while we have our problems (http://mcherm.com/permalinks/1/password-in-pieces), we aren't anywhere NEAR this bad.

Ehh, you're not going to be liable for the vast majority of security flaws. I wouldn't overworry yourself, the alternatives are much more dangerous.

Why does it matter, really? If someone hacks your account and somehow charges a bunch of stuff to your AmEx, then you're not going to be held responsible anyway. And since it's a credit card, you don't even have to pay out of pocket or take interest on the disputed amount.

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.

If they steal your identity, it might not be a lot of fun.

Identity theft's such a fun phrase. http://www.youtube.com/watch?v=CS9ptA3Ya9E

And after you cancel your Visa, Mastercard, etc., because they are no doubt the same kinds of idiots, how are you going to pay?

Cash?

Why are you making the assumption the person who wrote this response has anything to do with the security procedures that ensure data confidentiality? It's obvious the person is not a security specialist and is only repeating whatever he/she picked up at the last training session.

There are about half a dozen different kinds of institutional stupidity that could lead to a response like this. I'm not sure which kind of stupid worries me most. Do they let their customer service team just make shit up? Do they train them this way? Do they really think we're that stupid? Are they really that stupid? Gah.

Who's keeping them honest? 90% of people applying for jobs as security advisors or programmers or web developers or directors-of-logging-people-on are not going to understand about security. (I'm sure that most people would say that number is being very gracious about the quality of people applying for IT jobs, but I'm going with Sturgeon's Law to be safe.) Half of the remainder are the sort of people who won't do a good job without being cajoled into it, so unless their manager understands about security, we're out of luck.

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.

That response seems to be par for the course.

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.

The security in Visa, for the most part, doesn't come from protecting you from illegitimate charges happening in the first place, but rather in the fact that there's a chain of authentication so that charges can be reversed at any time, and an expert system trained on your buying habits so that you'll be alerted when you probably do need to make a reversal.

In the USA all potential costs from fraud go to the credit card company, not the consumer. This fact excuses a lot of stupidity, because the company bears the risk. In Britain the laws are, I understand, rather different.

If your bank is providing a US based system with British liability rules, then you've got a real problem and I pity you.

This seems reasonable to me. Key loggers on users' computers are probably their most common breach vector (by far), so whatever password policy minimizes that risk is probably best. You also see this in their other security policies - for example, asking a secondary password (security question) which sets a long-expiration cookie. With 128-bit SSL on the login page and a 5-guess lockout policy, there isn't much reason for strong passwords.

Damn text. So hard to get sarcasm sometimes. It was, right?

Considering that andreyf posted original link -- yes, it was a sarcasm :-)

No special characters in passwords is one of my biggest pet peeves. It really screws up my general system for generating passwords for different sites.

You can just "describe" your password for the special-character-impaired:

#(%$^ -> hashleftparenpercentdollarcaret

Probably a might bit harder to crack, too.

Not when they limit you to 8 characters. :)

You use a deterministic system for generating passwords based on site? That seems only marginally better than just using the same password everwhere...unless you're doing something like using a consistent secret key to encrypt some function of the site name with AES, and using the result as your password.

I disagree. Just using a tiny variation, like adding the length of the website's name at the end, will be enough to defeat any automated system. Even for a human, figuring it out would require cracking several websites and a lot of brain cycles to spend on his particular account.

Well, if he used the same strong password everywhere, it would still defeat any automated system. The reason you don't use the same password everywhere is in case someone decides to try it with your email address in a bunch of different places.

If I found his password for this site was hunter2HN, I'm pretty sure I could guess his Facebook password...

I don't know what's scarier, their security practices, or the fact that they call the person responsible for the system a "webmaster".

It seems like whoever answered this e-mail isn't a native English speaker, and so probably doesn't use the word "webmaster" the same way as you would.

I'm not Bruce Schneier, but to me this sounds like an incredibly lame security policy. If someone asked me to write a piece of software implementing this policy, I think I would just laugh.

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.

I suppose what they mean is that keyloggers / keylogger log analyzers can spot passwords by detecting unusual sequences of special characters or improbably long non-dictionary words. I'm far from being an expert at security but sounds like a reasonable concern to me.

It would be very interesting to hear the thoughts of some of the security expert HN-readers on this matter.

Not to me. You shouldn't compromise the security of your entire system just to safeguard against certain keylogger scenarios.

Agreed, if you really want to prevent keyloggers simply stop online banking. That's never going to happen, so decreasing the security of your entire system is stupid.

A secure password can be a correctly-capitalized and punctuated sentence. There is nothing reasonable about their concern.

Well on the face of it it is a reasonable concern. But if the system has a keylogger there is very little you can do to protect your user. It is a very poor attempt at security through obscurity.

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).

Well, to be pedantic, the best defence to a keylogger attack is a two-factor system. (RSA Fob, Smart Cards, and the like)

Well yes you would generate the number those ways. The keylogger defence is actually in the random subset of numbers asked for. It completely destroys any attack it could make by never giving it a single complete picture :-)

It's quite laughable really, if I'm logging into my bank I type HSBC.co.uk first, anything following that is my International Banking number, following that is my password (which is the best defence you state) and date of birth. If I was required to enter all 8 numbers my password would be the easiest thing to catch.

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.

which is what my bank does. (Lloyds).

I wish hsbc gave you the numbers it wanted you to enter as images too. Makes it a little more difficult to parse.

Some banks in South Africa used to bring up a little image keyboard and you click the letters (ie no keyboard) in my mind this is still one of the best ways to protect against keylogging.

Storing the password in a truecrypted file and copy pasting also works. Though, for someone going to those lengths, a keylogger is a very unlikely to be a problem for someone paying that much attention.

A software key-logger can also typically snoop the contents of the clipboard.

To log in to my bank online I need a browser certificate, my login, my 4-digit pin-code, and a 6-digit one-time random number from a little card my bank sent me. To get the browser certificate you need my login, my 4-digit pin-code, and another code the bank sends by SMS to my cell-phone.

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.

Care to share the name of the bank?

http://skandiabanken.se

I think I hurt my palm when it hit my face.

I don't think The Onion could have come up with that email... Definitely facepalm material.

There is a problem with the special characters for international users.

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/ )

Zipcar does the same thing: only numbers and letters. Also, try putting '<' or '>' in your password -- they'll complain about how you're putting HTML tags in your password.

Now why would they worry about that?

Ooh, that's scary. Being so worried about XSSing themselves when they look at your password and so uncertain of their HTML sanitisation that they reduce the keyspace... that's a special kind of special.

There are a number of prominent financial sites with similar policies, check out this cringe-inducing rundown: http://weakpasswords.org/list/

screams

...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.

Wow, that's pretty bad, but it's got nothing on one 'security' measure I ran into on an online college application site.

To enumerate, the password had to:

- have exactly 8 characters

- contain characters from 3 of the following 4 groups

-- lowercase letters

-- uppercase letters

-- numbers

-- ? . , _ - + = $ ! –

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.

When I first started school we were required to have 7-8 characters as well and the reasoning was in the faq: certain systems had not been upgraded to handle more than 8 characters which was interesting, I'm assuming it was certain computer terminals that hand't been upgraded as the restriction is now at 20 or 30 characters.

But they had a similar way to increase security as your online application:

Must contain 3 groups:

- uppercase

- lowercase

- numbers inserted in between normal characters

Special characters were optional but welcome.

As long as their hashing method is sufficiently slow that's not too bad a set of requirement. It at least null and voids the easiest sort of attacks.

Which is not to say it is good.

Apart from requiring exactly 8 characters, the other constraints will genuinely increase security.

Except, of course, that half the students will end up carrying their password on a piece of paper in their wallet.

My biggest issue with it, and other constraints like this though is that it just feels rather contrived.

That and it took far too long to some up with a password passing the description...

There is nothing wrong with carrying your password around on a piece of paper in your wallet. This is the Bruce-Schneier-approved method.

http://www.schneier.com/blog/archives/2005/06/write_down_you...

Or, just have a half-decent password management tool which keeps an encrypted file of your passwords on your phone, and remember just one password.

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.

Not really too surprising - tech support staff on the front line rarely are trained to actually have a clue what they're talking about. Just ask for a supervisor next time.

Come on! It's a website, and I'm sure it's not using Cobol Server Pages (CSP), so why now just put some simple logic between the web controllers and the COBOL logic?

Almost as bad as the IRS: http://zaid.posterous.com/irs-is-not-dot-com-friendly

A common issue of banking websites is that they force weak passwords, but I rarely hear about banking websites being "hacked". Why?

They force weak passwords for the users, not for the admin, so you could hack an account but not the website itself.

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.

the fact that it is minimum 6 chars and max 8 limits the size of the search field as well for brute forcing

Fake, right?

You'd hope so.

There was a guy by that name working for American Express though:

http://in.linkedin.com/in/gauravsharma14

But the timestamp on the screenshot is recent.

The same message is here in early December

http://lists.eclug.net/pipermail/eclug/2009-December/008208....

This suggests it was copy-and-pasted either inside or outside AMEX.

Reply on news.ycombinator.com