What is a reasonable expiry for user authentication certificates?

Question

This question is about a nearly decentralized P2P system with a centralized certificate authority where users can authenticate and receive a certificate on their public key and then can authenticate with peers using that certificate - independently from the certificate authority. In short, this is about morally equal to a "keep me logged in" checkbox that uses a cookie.

If the certificate gets stolen the user can be impersionated until the certificate expires, especially in a P2P system where certificates are nearly impossible to retract. This is an argument to make the expiry quite short, say an hour.

On the other hand we have the argument of dependency and performance. If the expiry is very long it reduces stress on the certificate authority, and it also reduces the impact when it is unavailable.

What is a reasonable expiry for such "logged in" certificates?

Answer 1

Real-life certificates have a neat concept called revocation. It is a way to propagate (in a secure way) the information that a given certificate, though apparently legit and kosher and with all the correct signatures, should not be trusted anymore. That's a kind of "oops" functionality. In X.509, this uses Certificate Revocation Lists and OCSP.

The underlying idea is that mishaps do happen occasionally, in particular stolen keys. Revocation is then a damage containment procedure, which is triggered when a problem of that kind is detected. The important property is that it is a manual procedure: it happens when humans decide it. So it has an inherent, unavoidable latency. Therefore, there is no need for revocation information to be "extremely fresh": CRL which are published, say, twice per day, will be enough, because it is illusory to expect a better reaction time to stolen keys.

Expiration can replace revocation if it is short enough. If certificates are short-lived, then revocation is not needed. How short is "short" ? By the reasoning above, revocation is not needed if the expiration time is shorter than the CRL publication interval that we would choose, if we had to publish CRL. By the reasoning above, 12 hours are short enough.

Therefore you may expire your authentication certificates after 12 hours. Since humans sleep at night, you cannot really expect key theft to be, on average, detected faster than that.

Answer 2

I think the reason this question is difficult to answer is because it is the wrong question. You cannot evaluate appropriate expiration times in isolation from the 'thing' being protected. There are no absolutes here. What you really need to determine is what is the maximum expiration time we can accept as being long enough to achieve maximum convenience for the client, but short enough to ensure acceptable protection. You can never achieve absolute security - the best you can do is find the right balance between making something secure enough while ensuring it is still usable.

Start by considering what would be the damage caused if the session data/cookie was compromised. Then consider how easily and likely this might be. The ease will largely depend on the technology and environment. The likelihood will depend more on the perceived value to someone else.

Once you have some measure for value, ease and likelihood, you can then consider firstly whether additional effort is required to secure communications further and where to focus efforts. For example, if the data has a very high value to others and the likelihood that it will be desired by others is very high, you may decide that the convenience of a "Remember Me" tpe session state cannot be justified, so you decide to just not provide that feature. Alternatively, you might decide that given the environment, value and level of likelihood, adding some additional information to the session may be sufficient or you may just decide on an expiration period which is within acceptable limits for the time/ease at which someone could obtain and use the session data and the likelihood someone would want to do it.

I realise this doesn't really answer the general question of what is the best expiration time, but that is because that question cannot be answered as it will depend on the application. Matters are made a lot harder because some of the measures used, such as 'value' and desire/likelihood have larely subjective components. That is why this stuff is hard. It is much easier to debate technical strengths/weaknesses because they usually have some degree of objective measurement. The more subjective dimensions are harder to assess because they require in-depth knowledge of the business processes, experience and even a bit of psychology!

Answer 3

Expiry time for user authentication certificates is not related to stealing certifications and forging identity. If an attacker can steal your authentication certificate it means that he already owns your pc so he doesn't need to steal your certificate anymore because he can use your pc to launch any activity and forge your identity.

Usually a hacker will sniff your encrypted traffic and doesn't have access to your pc thus he can't steal your data. He will launch a brute force attack on your encrypted data in order to retrieve original data in real time.

Validity time of your certificate should be less than the attack time or else it is useless. for example:

• session keys have validity time = one login
• symmetric keys, it is better to generate random keys for each session
• RSA keys have validity time = years