Updated: 10/8/2003; 1:53:08 PM.
Brian Maso's Tecno-Geek Weblog
The musings of a mild-mannered tecno-geek.
        

Wednesday, October 08, 2003

Sharing a few thoughts on security credential management that occurred to me this week...

This issue is credential security: When a credential is presented to a system for authentication, how "assurred" is the system that the credential has not been compromised? That the entity presenting the credential is actually an agent of the identity assocaited with the credential?

To assess "assurrance", you must first consider the type of credential. Token credentials, such as HTTP Session cookies or SAML tokens, are the simplest tyep of credential. The token has been assocaited with an identity known to the system. The simplicity of this credential, however, means that the credential is easy to steal and re-use. Any time the credential is used it can be copied and immediately used by an attacker - use of the credential opens it to compromise relatively easily.

Username/password is really just another version of a token, from the receiving system's point of view. It is a chunk of data that has been associated with a user identity. But use of the username/password immediately opens it up to attack. Anyone who can "see" the username/password pair  can immediately use it to make false requests.

The very first time it is used a token credential provides a high degree of assurance. However, each time it is used thereafter its assurrance is "degraded" because of the repeated exposure. Each time it is used it may be copied by an attacker, and so every time after the first there is a cumulative risk that the token has been compromised.

Good management of token-type credentials must therefore include limiting the "lifetime" of the credential. That is, if each time it is used there is some cumulative degredation of "assurance", then assurance approaches 0 as utility approaches infinity. So yhou must limit the uses of the token-type credential to prevent a statistically certain compromise, which would happen eventually.

There are 2 techniques commonly used to limit the utility of a credential:

  • Lifetime
  • Max usage count

The "lifetime" technique places a maximum absolute duration on the lifetime of the credential. The credential is considered no longer usable after this lifetime duration has run out. Assuming there are only a finit number of times the credential can be used within a finite time duration, then this technique adequately protects against statisticaly compromise; set the lifetime duration based on the risk each cumulative use adds to compromize, multiplied by the max number of time the credential may be used during its lifetime.

The max usage count technique cuts right to the point: the real crux of the problem is that each time the credential is used, it is potentially compromized. So just limit the total number of times it may be used. This should allow you to manage the risk of compromize.

Another important feature of credential management is revocation. Once a system detects that a credential has been compromised, or is likely to have been compromised, then the system must be able to revoke the credential. Otherwise an attacker may continue to use a compromized credential with impunity, even though the system administrators may even know that the credential has been stolen.

Now note that more complicated credentials, such as hash values built from tokens as well as PK certificates, really have all the same problems are simple tokens. Each exposure means an attacker may copy the credential. Once an attacker has a copy, with correctly applied technique it is only a matter of time before the credential is compromised: hash algorithms can be reversed to obtain the original token; PK private keys can be derived from PK public keys with enough brute-force calculation.

So use of the alternative techniques really only reduce the culumative risk of compromise associated with each exposure of these alternative credentials. The risk is not reduced to zero, but it is reduced exponentially, by potentially thousands of orders of magnitude. However, the need still remains for minimizing utility, and for revocation.

When designing identity credential management, analysis must include what type of credential is being used, with a special eye towards how much risk of compromise is added whenever the credential is used. Lifetime or usage count techniques, as well as a revocation mechanism, must be employed to provide a minimum level of identity assurance to the system.


1:53:04 PM    comment []

© Copyright 2003 Brian Maso.
 
October 2003
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Sep   Nov


Click here to visit the Radio UserLand website.

Subscribe to "Brian Maso's Tecno-Geek Weblog" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.