Hot on the heels of the OpenID phishing demonstration comes a proof of concept entitled "On the Insecurity of Microsoft’s Identity Metasystem Cardspace".

Setting aside the valid concerns of DNS poisoning the proof of concept makes use of SSL certificates; the proof of concept requires a user to install and trust a new root certificate. The assumption is that a user will blindly do this, I am not so sure; especially as both IE7 and Firefox will throw full screen certificate errors before allowing a browser to proceed. The user would have to choose to proceed, install a new root certificate, place it in the correct certificate store then restart their browser and try again.

It may well be possible for an attacker to request and acquire an SSL certificate for the attacked host from a trusted root authority however in practice I wonder how doable this would be; part of the process for inclusion in a browser is an examination of their issuing processes and how they validate requests.

The attack also relies on the browser hitting the false web server first; this is acknowledged as a problem with DNS pinning in the technical report.

Managed cards do not address the issue either; the request for the security token is coming from the legitimate web site and does not change; an auditing STS would see no difference and the correct SSL details would be sent with the endpoint information.

However even with all these problems the proof of concept illustrates a problem with the relying party code on .netfx3 rather than with Information Cards. The SAML token sent to a relying party includes an assertion identifier;

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
    MajorVersion="1" 
    MinorVersion="1" 
    AssertionID="uuid-cfd7dc59-420a-4df6-a968-c0e84e096f01" 
    Issuer="http://www.woodgrovebank.com/" 
    IssueInstant="2008-05-19T11:54:40.882Z">

A relying party should log these and check they are not reused to prevent reply attacks such as this. Obviously the Microsoft demonstration site does not do this nor, unfortunately, does the Microsoft provided token parsing sample code. Implementation of this check removes all vulnerabilities to replay attacks; remember if you change the AssertionID then the entire token will fail signature checking.

It does highlight an IE problem though; with SSL sites IE should do some more checking of the SSL certificates, matching the certificates and if that fails not allowing cross frame access within the browser; this is the part of the  "Strong Locked Same Original" solution suggested, however this requires SSL certificates on relying parties.

The suggested solutions however abandon one of the core information card principles, minimal disclosure. By requiring an SSL certificate on the browser a user may be identified and tracked, something we are trying to avoid. It’s certainly interesting though.

Update: Just to underscore how fragile DNS can be Comcast.net’s DNS entries for its own home web server were hacked today.

Update: (31-May) Kim has published his response which highlight’s the unlikeliness of both a DNS and certificate store attack in better language than I can manage.