Best Way To Avoid Keyloggers On Public Terminals?

goombah99 writes "While on vacation, I occasionally need to check my e-mail on a public terminal. What are some good techniques for avoiding keyloggers? Most of my ideas seem to have major drawbacks. Linux LiveCD can probably avoid software keyloggers, but it requires an invasive takeover of the public terminal, and is generally not possible. Kyps.net offers a free reverse proxy that will decode your password from a one-time pad you carry around, then enter it remotely. But, of course, you are giving them your passwords when you do this. You can run Firefox off a USB stick with various plugins (e.g. RoboForm) that will automatically fill the page in some manner they claim to be invulnerable to keyloggers. If that's true, (and I can't evaluate its security) it's getting close to a solution. Unfortunately, keeping the password file up-to-date is a mild nuisance. Moreover, since it will need to be a Windows executable, it's not possible for people without a Windows machine available to fill in their passwords ahead of time. For my business, I have SecureID, which makes one-time passwords. It's a good solution for businesses, but not for personal accounts on things like Gmail, etc. So, what solutions do you use, or how do you mitigate the defects of the above processes? In particular, how do people with Mac or Linux home computers deal with this?"

Comments

A LiveCD will not save you from a hardware based..

[Joe The Dragon]

A LiveCD will not save you from a hardware based key logger

Re:Phone?

[1729]

What kind of place doesn't allow phones, even left in the car? Pretty much every business and organization uses cel phones these days; what kind of company is paranoid enough to ban them that completely? Any site doing classified work will restrict cell phones. Camera phones are prohibited, and most privately owned phones without cameras still can't be taken into restricted areas (which sometimes will include the parking lot).

Re:How about this...

[timeOday]

What you just described is almost exactly what a password generator is (CryptoCard, SecureID). If you don't use them for long enough the clocks can drift apart and it won't work anymore. They have two advantages over your password table however: they require a PIN, and each generated password can only be used once.

Re:S/KEY

[Ernesto Alvarez]

You won't get a more robust worked out solution than a IETF standard......

I don't have a mac, and I'm not experienced enough with *BSD to know exactly what to tell you, my explanation on Debian GNU/Linux will have to do.

First, let me tell you that this is not my first line of defense, I also use ssh pubkeys and I definitely do not log on public terminals. OPIE is just there in case someone pwns one supposedly trusted terminal.

What I do is I creatively use PAM. I installed PAM-OPIE on my system. It comes with a few userland apps (a password changing program and a one time password calculator) and an authentication module.

The next thing to do is to modify the pam configuration so it calls pam_opie.so as an authentication. I set it up so that inputting the correct one time password grants access, while leaving the regular password system as a fallback only when used on the local terminal.



# Sets up user limits, please uncomment and read /etc/security/limits.conf
# to enable this functionality.
# (Replaces the use of /etc/limits in old login)
# session required pam_limits.so

#Sistema hibrido opie-password

auth sufficient pam_opie.so
auth required pam_securetty.so
auth required pam_unix.so


The text above is part of my pam configuration for su. Basically, I tell pam that answering correctly to pam_opie grants access, no matter what. If I fail S/KEY (opie), the system checks whether I'm on the terminal or remotely. If I'm not on the terminal, no matter what password I use, it'll never grant access.

On the userland, OPIE has a program, called opiekey, that calculates the next set of one time passwords you will need. That's what you should use to generate your set of 100 passwords. I don't use it since I have a calculator with me (the PDA). In order to set your long time password, you use another program, called opiepasswd, pretty much like the normal passwd program.

I don't know what you're planning to use to access your system (I hope ssh or something secure), but you should change pam's configuration for that program so it does something like the example above.

Let's say you use SSH. You change /etc/pam.d/sshd (or your OSX equivalent) to something like the example above. Then you set sshd to ALLOW keyboard-interactive logon and nothing else (or better, keyboard-interactive AND pubkey at the same time). When you connect the ssh client should open a secure connection and the server should issue the challenge, and you send the correct response.

No need to use perl or anything, PAM is part of the basic authentication system (I think it is on BSDs except OpenBSD). You might need to download a copy of pam_opie, though (thanks to APT, that's trivial in debian, check with your package manager).

That's pretty much it. I've put pointers to the freebsd docs, and it can't be that different from linux. I guess it should be pretty similar in mac too (would have pointed you to the mac docs, but I don't know where to find them).

If you have any doubts, don't hesitate to ask.

BTW, while on vacation the only thing I concentrate on is getting a nice sun tan. The other posters are right telling you not to log on a public terminal and not logging in while on vacation. That's my advice.

Re:Simple solution

[Hunter-Killer]

Many areas are accurately classified as "secure." Rent-a-cop manning a checkpoint at a facility surrounded by a scalable fence? Secure. Unguarded arms room? Secure. Building with armed guards, roving K9 patrols, and access controlled by multifactor authentication? (Probably) secure. The restrictions in effect depend on the nature of what is being safeguarded; comparing two situations is like apples and oranges. What I can tell you is how data/equipment of different classifications are treated.

FOUO/Unclassified-Pretty much the catch-all for government owned IT-equipment. Could have just a OEM copy of WinXP (standalone systems), or our enterprise's standard image. IT BBP applies: no end-user admin rights, but no restrictions on networking, only "approved" hardware/software. If lost/stolen/compromised, investigation is launched to determine possible risk (in aggregate, even unclassified data can yield vital information on operations) as well as verify that data was in fact only FOUO. Standard WPA/WPA2 is not considered acceptable for work-related activities, but there are approved solutions for official wireless use out there (AirFortress being the most popular).

Sensitive but Unclassified(SBU)-generally anything with SSNs or personnel data warrants this classification. Not approved for travel/remote use unless there's encryption in place. Aside from that, same as FOUO.

Confidential-Never encountered it applied to data. Should never be on a Unclassified system.

Secret-Computers, CDs/floppies, printers/copiers: everything Secret must be accounted for. Efforts are made to ensure only Secret devices touch the secret network (for me, SIPR). Secret devices are secured when not in use (otherwise they're hand-carried; oh yes, I was a COMSEC courier), and should never touch unclassified networks. Treated very similar to individually-issued firearms: nobody carries a device home for the night. Wireless is definitely out of the question.

I don't have experience with anything higher than Secret.

Re:Phone?

[Curien]

We had an Internet Cafe (through a commercial ISP) at two locations inside the fence. It served two purposes -- first, we had a lot of folks visiting us who might need to access blocked sites. Second, it could be used by visiting foreign nationals who weren't cleared to use NIPRNet (we also had a classified LAN for them to use). We periodically re-imaged the cafe, but we didn't really care enough to do it frequently.