Difference between revisions of "Vulnerabilities in ID tech"

From IIW
Jump to: navigation, search
(Undo revision 3072 by Igiwydijok (Talk))
 
Line 1: Line 1:
=[http://ipelasuq.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=
 
 
'''Vulnerabilities and Weaknesses in Identity Protocols'''  
 
'''Vulnerabilities and Weaknesses in Identity Protocols'''  
  

Latest revision as of 14:32, 7 February 2011

Vulnerabilities and Weaknesses in Identity Protocols

Convener: Rick Smith

Notes-taker: Rick Smith

Tags: Information Cards, CardSpace

Discussion notes:

A little bit of the blind following the blind.

Cardspace:

User clicks on card selector – transmit to relying party the information.

If it’s a self-issued card, then the client sends it directly.

If it’s a managed card, the data is still sent by the client, but the client sends a token signed by the “manager,” or ID provider.

Cards run in a protected space so that the contents can’t be sniffed by other unprivileged processes.

Four risk areas:

Native code running on client systems, and/or plug-ins on a browser. Attackers can substitute subverted code and intercept personal memorized secrets that secure the cards, or that are used with IDPs to authenticate a managed identity.

Network based attacks – forged transactions or modified transactions used to spoof identity. Most implementations rely on SSL to protect on these. Not all protocols require SSL in all circumstances where it is needed.

Subverted or malicious relying party – can the RP turn around and exploit the user’s identity to masquerade to another RP?

Spoofed IDP – a variant of the network based attack – can an attacker trick the RP into authenticating a user by intercepting IDP transactions and providing a bogus response

TPM modules – there are 300 million machines with TPMs today – we have a way to install secure software and safely manage crypto keys.