Safe way to authenticate (multi-factor authentication?) while being monitored?

Question

(I'm trying for a bit more precise answer, particularly with regard to multi-factor authentication, than I received for "Safe way to use a computer that has spyware/keylogger installed?" on SU.)

Let's suppose that I am using a computer that is, for contractual/legal/policy reasons, extensively monitored. For argument's sake, let's assume that anything visible on screen and anything typed are captured (so on-screen keyboards are not secure). The policy allows me to make some personal use of the monitored computer, but not to disable or circumvent the monitoring (so I can't boot the computer into an unmonitored environment), nor to use my own personal computer. Can I use multi-factor authentication or some other method to safely authenticate to a remote service (e.g., to an OpenID provider, an email account, ssh, etc.)? By "safely," I mean in a way that will not permit someone who has access to the monitoring logs to authenticate to the remote service as me.

Answer 1

Assumptions. As I understand it, you are only concerned about eavesdropping: e.g., that the folks who are monitoring you might record everything you do, and fail to adequately secure those records. You are not worried that they will be actively malicious. For instance, they won't mount a man-in-the-middle attack on you.

Advice. Given this threat model, I think any external authenticator would likely work. For instance, here are three options, any of which should address your needs:

• Authenticating with a RSA SecurID card would address your concerns, because the SecurID card generates a time-dependent single-use authenticator that is not useful to an attacker if it is subsequently exposed.

• Another reasonable option would be a smartcard that stores a client cert and private key, and then authenticate using SSL client certs; this is secure, because your private key never leaves the smartcard, and even if the monitors capture the challenge-response values sent over SSL, they won't do any good to an attacker after they are used.

• You could also use a one-time passwords. The one-time password will be recorded, but even if those records later leak, the password will already have been used and will no longer be valid, so it won't be of any use to an attacker.

• Another possibility would be to use OpenID to authenticate to the website. That still leaves the question of how to authenticate to your OpenID provider, but if you can find an OpenID provider who will allow users to authenticate themselves by any of the three methods above, then you'd be in great shape -- this would let you log in securely to any website that supports OpenID.

• Beyond the web, if you want to log in to another computer remotely, you could log in via SSH with public-key authentication, with your private key stored on a smartcard. SSH lets you store your private key on a smartcard, so the folks monitoring you never learn your private key (see also here, here, and here).

Basically, the common theme here is to use crypto (e.g., public-key crypto) instead of passwords for authentication.

The primary challenge is that all of these methods require some kind of support from the site you are logging into. If the site doesn't support one-time passwords, SecurID, client certs, OpenID, or SSH -- if it only supports ordinary password authentication -- you're hosed.

Answer 2

One-time passwords would seem to fit the bill.

Assuming you aren't being filmed, you could have a list printed out.

Answer 3

What a question!

Ok, so, does multi-factor authentication help? Yes. You can't intercept what's produced on your average bank card-reader without some serious technological wizardry (or a particularly well placed camera). So that login information can only be intercepted; the next time you come to authenticate, the token should be different.

However, and this is a big one. We are assuming (I think) that every communication with this remote service is monitored and that you do not re-authenticate for every given action. In which case, if it is possible to intercept and hijack that session, you will be able to do whatever the service allows.

That might include altering authentication credentials such as the password component. That will certainly lock you out of your remote service next time you come to log in to said remote service, but for repeated access the attacker requires that physical token or the algorithm it uses. We can safely assume they can acquire an appropriate card-reader, but unless they can acquire the card and the PIN, they won't be able to re-authenticate.

So, when the first factor is compromised security then falls on the second factor, the physical number generator or whatever that is, and the security of the session in progress. Your bank probably has this covered too in all likelihood; if I want to make a payment, I also now have to authorise that with my card-reader, because whilst anyone could hijack my session, they won't have access to my physical card (in theory). The same, on my bank, goes for making credential changes. However, it is a different matter for your email account, say.

Let's consider other possible ideas too: the problem with biometric data is that it doesn't change over time. This means, like a password, once it is intercepted, it's valid forever. It's absolutely fine to use in place of a password; in fact, stored appropriately it might even be better, I'm not really sufficiently well read on the topic to say, but it has the same constantness that a password is likely to have.

So, basically, Douglass gets there. One time passwords are a very good choice; in this case, what appear to be one time passwords generated by a card reader based on input from a card protected by a PIN.

It is worth noting, however, that credit card security is an often-discussed topic on Light Blue Touchpaper, the Cambridge University Computer Security Lab, where the implementation security of Chip and PIN frequently comes under fire.

All in all, it's a balance game. To what extent do you think the controllers of this computer are likely to perform such an attack on you? To what extent is their ability to access your email or whatever a concern? There's an equation that says something like severity = likelihood x risk - evaluate concerns in that way and decide whether or not, for your particular circumstances, the risk is one you are willing to take.

Answer 4

Out-of-band authentication may fit your situation. Phone authentication is one type (disclaimer: I do this for a living at PhoneFactor). OpenID can be paired with phone authentication to achieve a similar effect; myopenid.com includes phone verification as an option.

Answer 5

Google Authenticator. Make sure you set it up out of band (not on your work comp) and have it on your smart phone. This way someone would need access to your smartphone in order to auth as you to whatever service accepts it.

http://support.google.com/a/bin/answer.py?hl=en&answer=1037451

However, if they have full control of the computer, they have access to the cookies used to authenticate your session. You must make sure that the application invalidates the cookies when you logout, or they could be used until they expire.