Financial Sector Fail

The fail keeps rolling in. I'm not really sure what the story is behind this screenshot, but I'm pretty sure I can guess: A user notices that American Express's password policy forces weak passwords, then emails them to get more information. Amex responds with the following bit of creative writing:

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.

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

Therefore, lesser keys punched in a given frame of time lessen the possibility of the password being cracked.

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.

This response may not make much sense to a non-security person, but to a security person, well... it still doesn't make much sense. 128 bit encryption makes passwords with just alphanumerics stronger than ones with a larger character set? Hacking software recognizes special characters easily? Deciphering passwords based on the most common letters? They wouldn't dare... is American Express really just using substitution ciphers to "encrypt" passwords? That is the only thing that vaguely makes sense.

This is absolutely unbelievable.

At least it would be, if I didn't have more of the same kind of stories. Fortunately mine deals with a local mortgage company, and not a $15 billion global financial services company. I sent them an email in early 2009 detailing about half a dozen issues with their website (an ancient payment and account tracking application), all of which I would rate as critical in any penetration test, and all of which could be tested unintrusively, on the client side. Things like predictable Session IDs (a timestamp, with a granularity of only seconds), password retrieval features (all you need to do is guess a username and the answer to the secret question and it echoes the password back), cross-site scripting, publicly available statements (a directory full of pdfs. Guess my loan ID (sequentially assigned), get my statements. If it's tax season, you get my SSN with it). Lack of two-factor authentication.

Bad stuff. Of course, you'd expect them to be happy to recieve a free assessment from somebody as distinguished as myself (okay Mikey, hold back the ego). My rates aren't cheap, after all. You'd expect them to at least fix things by now, but they haven't. Instead, I got an email detailing why the issues (which I had not only described, but also demonstrated to myself) would not work. The usual lies:

our #1 priority is the protection of personal information and we appreciate feedback we receive from our customers to continually improve and/or test that protection.

No, it isn't. Your #1 priority is making money from loans. You are a mortgage company, after all. If your #1 priority was security, you would be a security company.

we look at the user-id and question as the two-factor authentication. the system has been re-written (and will be implemented soon) to add a 3rd factor (ssn) and then the password will be sent to the email address on file or the user can have the option of setting themselves up again.

Oh that's good. Keep my SSN on file in the database with it. It's bad enough you're putting that data in the publicly-accessible reports.

[On XSS:] This is an area that is like a moving target. It is a high priority with us. You can also include xss cookie theft, hijacking sessions, etc. etc. we have several safeguards in place. i am not at liberty to discuss them since they are a major key to the security of our site

How comforting, you're one of those people who thinks "secret filter" is a solution for XSS. And yet, my XSS still executes. Every time. Even now, almost a year later.

[On Session ID Generation] This algorithm is extremely secure. Of course i’m not going to explain how it’s programmed. We also use hacker and virus proof servers. Once again, the algorithm in place will not allow this to happen. As i stated in my previous email the only place SSNs were visible were on the January 2009 statements, which we have removed even though we feel they were secure.

I'm tearing my hair out at this point. What algorithm is "extremely secure"? The one that takes a timestamp, and turns it into a Session ID? Remember, this was not conjecture, I actually demonstrated it for my initial email. The SSNs were only visible in the January statements, but they were never removed from the server. The links to the PDF files sure were, but all I have to do is take the link to the February statement and change a "2" to a "1". That's epic hax right there.

This shit pisses me off, and what's more, I don't have any reasonable recourse. My mortgage was sold to this company by the group I originally financed my house through. At the time, I did some research but never came up with a good answer of who to report the issue to (I'm no lawyer, but I believe this is a pretty clear violation of the GLBA). Even when I no longer have that mortgage, they're required by law to hang onto my personal data for several more years.

They aren't the first people to act negligently with my personal data, and they won't be the last. While writing this piece, I was registering a domain name on another screen, and while making the payment, I ran across more of the same stupidity, this time from my credit card company.

At that point, I couldn't help laughing.