Patrick Petit discusses Information Card support in OpenSSO – note that for those of you wondering about Information Card projects using Java, the OpenSSO project is a prime example.
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.
We’ve been having a great discussion on the OSIS-general mailing list, and I wanted to save a bookmark to the thread so that I could come back later.
The thread discusses what exactly an RP should use to uniquely identify a card from a managed card provider. The current methodology that I’ve been using with the PamelaProject RP’s was to take the isuer certificate signerkeymodulus provided in the SAML 1.1 token and the PPID and hash it together to get a card hash that is pretty tough to replicate without the original inputs.
The problem started when I encountered a managed card that did not explicitly provide a signerkeymodulus in the token. It turns out that I could still extract the value, but the point was made that by using the signerkeymodulus of a managed card, I guaranteed that on issuer certificate rotation, the card identifier would become invalid, and the user would have to reassociate their card. Obviously, this is not an optimal solution.
The solution that was recommended was to generate an identifier for the issuer using the same algorithm IdPs use in section 7.6.1 of the IMI specification, so I will give that a try right away. I would say that this is the closest thing to a best practice out there for Relying Parties, and I would recommend that any other RP writers out there that they review whatever policy they are using; if they are depending on signerkeymodulus, there is at least one IdP out there who does not supply the signerkeymodulus as a separate element in the token, so you’ll be having interoperability issues. If you are storing the PPID directly, I’d also like to strongly discourage you from doing so, I would consider it just as much of a no-no as if you were storing clear-text passwords.
The thread is worth reading, if you get excited about such things ;) You can also subscribe to the osis-general list here.