Welcome and thank you for your interest in privacyIDEA.
One Time Password authentication is an authentication method that is based on a symmetric secret key. The authentication device (yubikey, smartphone app, keyfob) and the server backend both have the same (symmetric) key to calculate the OTP value and to verify the OTP value.
And here starts the problem with offline authentication.
To take the short cut:
Offline authentication in privacyIDEA is not ment to be used, for some moment when the privacyIDEA server is down. (For this you set up a redundant privacyIDEA system). But it is ment for the situation where your notebook is not connected to the network.
So if you really want to use SSH (which means systems have a network connection!) do not use offline authentication!
This is the long story - in case you want to use a desktop login with your notebook, which in certain moments have no network connection:
The bigger picture
As mentioned, the OTP algorithm (HOTP, RFC 4226) is based on a symmetric key. Usual authentication works this way, that your authentication device calculates the OTP value based on HOTP(secretKey, counter), an HMAC function based on the secret key and the counter.
The OTP value is sent to the authentication server, which knows the last counter and also calculates the OTP value in the same manner and compares, if they are matching. If not, it tries the next counter, and the next and the next (up to 10 times, configurable).
So if your authentication system is not available - or better: if the notebook is offline, someone or something has to calculate the OTP value, to check if the OTP value, that the user entered (from his authentication device or his smartphone app) is correct.
This is what the privacyIDEA PAM module can do, without contacting privacyIDEA.
Which death do you want to die?
Now there are basically two possibilities:
- the authentication server can distribute the secret key to the notebook into the PAM module, so that the PAM module can use this secret key, to verify the OTP values. If your notebook is stolen or lost, consider the secret key to not be secret anymore.
2.the authentication server can precalculate a list of OTP values and pass this list to the notebook. The secret key is contained in the authentication server. If the notebook gest stolen, only a certain amount of OTP values are compromised. But if you are offline longer, than the OTP-list, then you will not be able to authenticate anymore.
In both cases there are other challenges:
Imagine only your notebook is offline. You are authenticating with OTP value 37. An attacker observes the OTP value 37 and uses this OTP value to login to your company VPN, which authenticates against the authentication server. I.e. with offline you need to assure, that the token or OTP values, that are used for offline authentication can not be used online - because the online authentication server can not know, if this OTP value is used or compromized.
Imagine you have an account, that you can use on many different company notebooks, which can go offline. Do you want to distribute the secret key to all notebooks? Or a list to all notebooks? Then you again have the same problem. The attacker can observe OTP value A on notebook A to use this valid OTP value to login to notebook B.
You see there are a lot of issues to deal with when trying to do offline authentication. (Honestly, if you really need offline authentication, because your notebook has no network connection, I recommend using smartcards, which do assymmetric cryptography an do not bear the problem of compromizing a secret key.)
How privacyIDEA does it
Anyways, privacyIDEA implemented it this way, that you need to define, which OTP token can be used by which user on which machine. If a user authenticates from this machine with this very OTP token, privacyIDEA will precalculate an OTP list and pass this list to the notebook. At the same time, privacyIDEA will “mark” the token as being offline, assuring that the OTP values, that were passed to the notebook can not be used for online authentication.
This way we have avoided:
- online replay attacks with already offline used OTP values
- compromizing of secret keys, which might otherwise be cumbersome with preseeded hardware tokens.
Still a user with an assigned notebook can use this very notebook with this very token to also login in the tunnel or at Mount Baker, where you absolutely have no cell coverage.
I hope this helped to understand the idea of offline authentication.
Please ask any question, if there is anything left unclear.
We might use this one day to improve our documentation (http://privacyidea.readthedocs.io/en/latest/machines/index.html?highlight=offline#offline) which honestly is shorter than my post