This session was based on the idea that the many common problems, protocols and implementations of distributed authentication and identity systems also lead to a common set of flaws, pitfalls and shortcomings. The goal was to propose a set of “most common mistakes”, in the spirit of the OWASP Top 10 Most Common Web Application Flaws, (http://www.owasp.org) to inform designers, implementers and deployers of these technologies on the informal security history and academic literature of similar technologies.

The discussion started with the following outline, supplied by Brad Hill:

7 Deadly Sins of Distributed Authentication:

1. Unconstrained Delegation

Passwords

Give them to somebody, they can use them to authenticate as you to anyone else.

Bearer Tokens

Message level security needs to have a target scope: Who was this artifact intended for?

Just make it random unless you have a good reason why it shouldn’t be.

Only need to seed and occasionally update PRNG with good randomness.

Minute possibility of a collision in a 128 bit random space is exactly the guarantee you’re hanging your hat on.

Old IETF draft of GUIDS not really that random – don’t use it.

HMAC Verification Timing

Don’t use a standard string or array comparison function to verify HMACs.

They all short-circuit as soon as they find a mismatched character.

Timing difference between good validation and bad validation.

Brute force correct HMAC one character at a time.

C and machine language comparisons that look like constant time may be OK, but test. Java and .Net are subject to optimizations that make code that looks like it should produce constant time results not. Adding a randomized delay was suggested. Suggestions from the group for better algorithms included double-hashing the HMAC before comparing, or starting the comparison at a random location in the HMAC string.

Other proposed additions to the list of common sins included:

Key Distribution

Administration

Rollover

Key Lifetime

“Heavy” Keys

Failure to Manage the Ecosystem and Dependencies

Verifying the implementation and policy of relying parties / consumers

Failure to Explicitly Distinguish Implementation vs. Policy

Acceptance policy

Issuance policy

“Writing Your Own”

Developers have learned in the last 10 years they shouldn’t write their own crypto algorithms. Need to learn now that they shouldn’t write their own distributed authentication and identity protocols.

IdPs and protocol implementers should provide and consumers should use standard libraries.

Usability should focus on providing good APIs and libraries. Making a protocol that anyone can implement in Perl overnight should be a non-goal, or at least subordinate to making a protocol that gives participants strong security guarantees.

Significant interest was expressed, at least among the attendees at the session, in formalizing the discussion into a paper, including a good bibliography.

Google Group created to facilitate discussion around creation of such a paper, at: