Recent Findings in Bank Security

Recent findings:

1. Identity samurai Pamela Dingle notices disturbing practices on a website, just so happens to be a bank website

Don’t get me wrong,  HSBC is very worried about the appearance of security, in fact I was forced to positively acknowledge a big long page of statements about how firewalls are used, and how they require me to use 128-bit encryption. In spite off all the assurances, it seems to me that I’m at risk in a number of ways now, and all so that the password interface can be turned into a primitive and easily overcome turing test.

Wow! Firewalls *AND* SSL, where have I heard that before?

2. Turns out, its not just the consumer facing front end that got it wrong, following the practices of "data breaches are good for you" school we learn they also store their customer's passwords in cleartext. 

If you made a maturity continuum of security practices, where would "Store in passwords in cleartext" fall? Somewhere between chmod 777 and running your entire bank on anonymous ftp? 

I mean I just double checked my calendar, and it definitely says it is 2009. Often I am advocating for sites to move away from username/password and towards things like SAML and Information Cards, but I guess there is an incremental maturity step called - "encrypt passwords", this from a major player in the financial services industry which some people would have us believe is a leading light in security.

3. For those interested in improvement, Pamela identifies some useful lessons that the security industry can apply going forward

Had the HSBC stored their passwords in some kind of encrypted format,  the same attack would have netted the hacker a fraction of the value,  because there would still be a significant and likely cost-ineffective amount of time and work necessary to turn the data into a set of credentials that could be used for actual authentication.  This is why encryption of passwords is an industry best practice, and why you will and should be laughed out of this community if you can’t get such a simple mitigation right.

If an RP stores the ppid and modulus of a self-issued information card in clear text, and that RP becomes the victim of a SQL injection attack,  a hacker has everything they need to get in the front door too.   The data must be stored in a way that mitigates this danger,  period.  I consider this to be identity 101 for information cards, and anyone who writes an RP should consider this to be a best practice.

On my Enterprise Security To Do List for 2009, number 3 was Learn about Identity

One of the most frightening things of the last couple of years is that when I speak at security conferences and ask for hands on who knows about SAML or Cardspace only a few hands go up. Then when I speak at identity conferences, and ask who has heard of OWASP its like "Huh, wha?" Man that is scary. Identity is the basis of access control, if you don't understand identity then you don't understand your access control model. Rolling out security architectures on username and password in 2009 is lame. Pick a technology or two like SAML or Cardspace and drill down.

Comments

[Account Deleted]

In Singapore, the monetary authority clearly states that SSL is sufficient. Hence, end-to-end application level encryption is required :) But that's just part of the *fun* implementing the guidelines...