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.

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

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.

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