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?"

Several options

[gweihir]

One-time passwords are the best, since they require a man-in-the-middle ralt-time attack to be broken. This is very unlikely on a public terminal. As to implementation, carrying around a printout is propbably enough for the avaliable remote-login solutions for Unix.

For Web-Stuff, and other servers you do not control, you are screwed, unless you can reboot the machine with your own system. There is basically no way around a keylogger without that. If the attacker invests a bit more, thay can also directly listen to the keyboard via hardware-device.

The best option is still to have your own reasonably secure device (PDA, Laptop or the like) and use wireless Internet. With the eee PC this just got a lot more affordable.

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

[Anonymous Coward]

There are modules for PAM for this. It works.

Re:Simple solution

[gnick]

Can you buy a wifi USB dongle?

Yes. But I'd be risking my career if I plugged it into my work laptop...

Re:Phone?

[1729]

What kind of place doesn't allow phones and also has publicly available computers to use?

The point is that people who work in classified environments can't bring camera phones/smartphones to work (even to leave in their car) and usually have to leave even basic cell phones outside the gates. If you can't carry an iPhone with you then it won't be very useful. Maybe you could bring it when traveling (provided you aren't leaving directly from work or traveling directly to a classified site), but then you're paying $400 for a phone and $50+/month for service on a phone you can rarely use.

In-room internet access

[neBelcnU]

Having set up several, and helped a company to standardize their installation of many, I gotta tell you that with rare exceptions* in-room internet access is the most dangerous network imagineable.

The "lowest bidder" effect will apply all through the chain of decisions with the end result of that little wire (or wifi) linking you to every possible attack vector known to man. Even in the hotels with firewalls (mostly to save address-space costs with the ISP, not for your safety) the inside will almost always feature some knucklehead with something on their laptop.

And all the above refers to the innocent sources. The malicious types, well, they have free reign for the most part.

For What It's Worth.

*the exceptions would be those hotels that employ some rudiments of network security, usually segregating sections of the hotel. Only one that I know of had per-room VLANs, which was certainly a good start.

OpenID seems to be a potential winner..

[unrealmp3]

OpenID was mainly done to protect user's credential and to implement a global Single Sign-On process. VeriSign is an OpenID provider (https://pip.verisignlabs.com/), and they provide increased security by adding a two-factor sign-on (https://idprotect.verisign.com/learnmore.v). This way if someone get your long-term password on the VeriSign website, your account is still secured by the single-use key generated by the device.

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 [freebsd.org]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 [freebsd.org] 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:Phone?

[gnick]

If I'm staying in a hotel at nights, then I'm bringing my own laptop and thus, STILL don't need to use a public terminal.

I hate to keep harping on the same note, but privately owned laptops are not permitted on the sites banning cell phones, imposing restrictions on company laptops, etc. And leaving cell phones/private laptops/etc in hotel rooms is only practical if you can persuade your company to pay for extra hotel nights so that you can swing by between work & the airport to drop off/pick up your stuff.

Re:S/KEY

[LazyBoy]

Java Cell Phone impl. [tanso.net]
Python impl. [sourceforge.net]

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.

Use Microsofts On Screen Accessibility Keyboard.

[kiwioddBall]

A standard part of Windows. I don't know about other OS'es.
On Windows 2000 (prob same on XP etc) Start / Programs / Accessories / Accessibility / On Screen Keyboard.
Click in your Password field. Enter your password using the mouse on the on screen keyboard. Good enough.

Ummm, buy a laptop...

[multimediavt]

I'm sure someone must have said this already, but if you are that worried about keyloggers and such on public terminals, DON'T USE THEM!

I'd strongly recommend that you buy a laptop to take with you on vacation so you can check email, etc. from the road. If you're that paranoid about it then the simplest solution is to not use public terminals at all for tasks that require you to enter private data and make the investment in a cheap laptop.