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.

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?

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.

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.

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.