I wrote not long ago about the HSBC Canada banking site, and its odd and frightening ways of dealing with access control.  Their fanciful notions of authentication proved to me that passwords were being stored in a retrievable format rather than in a format where the password can be verified as matching but not retrieved and examined.

This exact same issue has come up on the OSIS list with respect to privatepersonalidentifiers – some have argued that it is perfectly safe to store raw ppid and modulus information at the RP,  and I cannot tell you how STRONGLY I disagree with that idea.

Luckily, Gunnar has pointed me to the perfect example:  apparently the HSBC France banking site has been hacked,  and guess what?  They are storing their customer’s passwords in clear text too (surprise surprise).  And a handy little SQL injection attack gives the hacker everything he needs to log in as anyone he can think to query for.

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.