Desigining an authentication system

I ran into this a while ago, and thought it was a wonderful discussion of how to go about designing a high quality authentication system.

As I’ve mentioned in the past, authentication is one of the hardest problems in security – authorization (AccessCheck) is relatively simple, but authentication is a nightmare.

This dialog, from MIT, discusses the issues that need to be considered while designing an authentication system, and the ramifications of not considering them.  All-in-all, an excellent read.


On a personal note: Work’s getting very hectic, so the blog’s likely to go dark until sometime next week, sorry about that :(.


Comments (9)

  1. Anonymous says:

    And that’s just the _design_. Sure, design of authentication systems is a nightmare. Correct implementation of the design once you’ve got a good design is nigh impossible.

    There have been three "highly critical" flaws found in the MIT implementation of Kerberos in the last two years alone.

    Note that this pretty much thoroughly discounts the specious "many eyes make all bugs shallow" claim so often bandied about by OSS zealots. That Kerberos implementation had bugs in it for YEARS that were missed by some of the finest security minds in the business. Some bugs really are still deep.

  2. Anonymous says:

    Wow that is really cool. A billiant explanation.

    I guess a good way of teaching students about this system is to make them act out the different parts of the system and pass bits of paper back and forth.

    I love it when something so seemingly indecipherable can be but broken down and explained like that.

    Maybe someone ought to create a similar description for the new WS-* standards. Its all very well to say you just need an [Authenticated] attribute in Indigo, but it would be nice to understand whats going on underneath.

  3. Anonymous says:


    You’re absolutely right. I didn’t want to go into the "Open Source Security/Many eyes makes shallow bugs" issue because I don’t have the bandwidth to respond, but it’s true – Many eyes has been disproven time and time again. Any paradigm that pretends to take the place of solid engineering and dillegent code reviews is just a panacea.

  4. Anonymous says:

    > Any paradigm that pretends to take the place

    > of solid engineering and dillegent code

    > reviews is just a panacea.

    I don’t think "panacea" is the right word to use here. Here’s what the dictionary says:

    panacea (noun)

    A remedy for all diseases, evils, or difficulties; a cure-all.

  5. Anonymous says:


    Actually panacea IS the right word. Because a panacea sounds good, but in fact doesn’t work. It may be different for you, but I’ve not yet found anything that works as "A remedy for all diseases, evils or difficulties".

    And if someone tried to sell you something that promised to be a panacea, would you buy it?

  6. Anonymous says:

    I’ll side with Pavel. You want an antonym of panacea, I think. Or "not a panacea". Or maybe "snake oil" or something similar would be more fitting in that it falsely promises a panacea.

  7. Anonymous says:

    After about 5 readings, I think you’re right Drew (and Pavel :))

  8. Anonymous says:

    The MIT page is useful and a great intro.

    Personally, I read "Authentication: From Passwords to Public Keys" by Richard E Smith on a holiday to France a couple of years ago and found it to be an excellent introduction to the issues and pitfalls of authentication in general (though the chapter on Kerberos is excellent).

Skip to main content