An open letter to Bank of America

One of my pet peeves is seemingly poor programming practices, especially when it comes to something that I perceive as easily worked around or corrected.

Well, the Bank of America online banking website just earned my ire in this realm.

I'm trying to reset my password to use an algorithm that I've developled for myself. My algorithm generates very secure passwords that are easy for me to remember, and different for each place I use it, using letters, numbers, and symbols. Well, the online banking site has some specific rules for creating passwords:

- It cannot contain special character $ < > & ^ ! [ ]

Now, these are probably metacharacters for whatever language is running the site on the back end. The problem is that, from what I can assess, they don't FRAKING QUOTE the password that you supply them that would prevent whatever language they're using on the back end from interpreting the symbols as metacharacters. Either that, or they don't trust the front-end (the part that we enter our username and password into) to pass the symbols to the backend properly, which should also be solved by quoting the string.

Now, unless someone from Bank of America calls me on this, I'm going to assume that someone in the web development team is a moron, and didn't do enough homework when he/she got their Computer Engineering degree.

I'm not studied in this field, but I know enough to talk to professionals about this on a reasonably intelligent level, having done web development in PERL. If anyone can give me a reasonable explanation, I will post it here, and issue an apology if needed.


Unknown said...

I large number of programs or sites that require passwords exclude special characters, they want alpha and/or numberic. They may even be case sensitive, but many of them just exclue special characters. I'm guessing that (like the Microsoft product keys, only in reverse) they generate some kind of algorhythm based on the characters, or converts it to a different numerical system, or something. Some means of encrypting it that doesn't allow for special characters. Something new with their SiteKey system?

Just a thought, as I'm no coder. I know that special characters make for an even stronger password...

CaptSlaq said...

You're getting into encryption at that point. There's some great stuff on ciphers on wikipedia if you're really interested in them. Most of them are nearly over my head.

The Microsoft key generating algorithm is set up intentionally to not include metacharacters. I speculate it's by design to make key input easier for the user.

However, the problem with your assessment is that it doesn't address my beef: If the encryption won't accept the characters, YOU'RE DOING IT WRONG. RSA, AES, DES, and a host of other encryption schemes have no problem with anything that you pass them that are all very secure. SSL certificates are generated using one of the major ciphers currently.

At any rate, I don't believe that the problem is with the cipher: the characters listed have a high probability of being actual metacharacters in some language. Examples below are all explained in the vein of PERL:

$: this is a variable.

<>: with a filehandle in between (eg, < README >), can be used in place of "read README".

&: &SUBROUTINE tells the script to execute the subroutine SUBROUTINE

^: used in regular expressions. Tells the regular expression to match whatever is between this and the next delimter at the beginning of the searched string only

!: In regular expressions means "not" as in "look for !foo" (not actual code) would return everything that is not "foo".

[]: In regular expressions, used to group search items, as in "look for ['foo', 'bar', 'bat']" (not actual code) would return any of foo, bar, or bat.