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?"
I click around on icons until I can copy and paste a lot of letters into a single file. Then, with my Alpha-pallette, I cut and paste each letter as needed.
To get root access on my server, I use a one time password system(rfc 2289). I use a S/KEY calculator on a palm pilot, and PAM Opie on the server. The public terminal never sees a long term password, it never leaves the PDA.
Not much else to be said. Maybe you could also use a crypto token and asymetric crypto, but considering that you need drivers, I'd say it's not practical. You might still use some sort of somewhat disposable private/public key. That should defeat keyloggers, but you risk getting your key compromised (that's why it's disposable).
GPG 0x1B479C78
What protection does that afford against a physical keylogger?
Not all keyloggers are software.
If I have nothing to hide, don't search me
He uses only the mouse, so it is invulnerable to that method, actually. You need to capture the mouse actions and the screen simultaneously. This is something not easily done in separate hardware.
So, thinking about this a bit...the point is you need a password that can't be used later. The digital services are fine, but do we really need more than a 1-5 minute resolution here?
So a clever IT department could make passwords dependant on the time and date. Print out a code sheet, different for each employee, with words substituted for the date and time, a short word for the date and a short word for the ten minute time period you're in, something like that.
This way the password would be useless to a logger, you'd need a code sheet to log in, but it doesn't seem like it would be THAT much trouble (if your info is so important you're this paranoid...)...
I call the patent!
You could try running Portable Firefox with KeyScrambler from a thumb drive. https://addons.mozilla.org/en-US/firefox/addon/3383
I once had to remote support a customer in another country and they sent us a little card-sized gadget that displayed a random code that changed every few minutes. It was synchronised (by the clock being pretty accurate I suppose, or possibly by radio signal) to an identical random code list at their site. So whenever we wanted to log in we just looked at the current code on the card, typed it in and at their end the code was checked against the current code.
This sort of set-up could be very useful for people who frequently use public terminals. Your code can still be compromised but the crooks would only have a few minutes to retrieve and use it. Maybe you could even have it so that when you use a code once, the central code verification server invalidates it, so no-one else can log in, even if they do get the code quickly.
I don't believe anything like this exists for the average person wanting to use normal email accounts though. Anyway, none of this changes the possibility that there are screenshots being taken every few seconds so that all of your private emails will be viewed later anyway.
Certain sectors of the defense industry, for one. Mostly it stems from fear of camera phones, so they ban all phones from the facility period, camera or not. But there are also other concerns that they have, rightly or not.
Touch everywhere, even when inappropriate.
I built a system in the late 90's where you had a web-page where you entered an account-name. That name was tied to a cellphone number which was sent a generated password as a text-message. The password was only valid for 5 minutes.
AFAIK it's still in use and have never been cracked.
--- Reality doesn't care about your opinions, it happens anyway and if you are in the way you'll get squished.
This would require server-side scripting, but what if each account kept a phone number on file? If the person uses the correct password, keep them out but text message them a single-use password. They can now log-in with the single-use password.
Now the system requires something you know (your password) and something you have (your phone).
The ______ Agenda
Setup VNC or something similar on your home desktop. Create a list of passwords you'll use for the duration of your trip.
Every time you stop by at a cybercafe, connect to your VNC, do your business with all your passwords pre-saved safely on your home desktop. Once done, execute a script which will change the password to the next password on the list, log out, and move on.
I haven't done this myself, but last time I went to Italy and had to use some really shady cybercafes, I really wished I had a system like this in place...
- shazow
"The restrictions in effect depend on the nature of what is being safeguarded; comparing two situations is like apples and oranges."
:)
Very true and *must* be remembered when at a govt installation - especially ones that had ever done nuke stuff at some point. There are MANY reasons for a "secure" rating and it may be more to protect you than the what is inside the compound.
There was an incident shortly after 9/11 where some reporter showed how "insecure" a sight at LANL was by scaling a fence, cutting a lock off a building, and taking many photos. It also included a rant about why spend security on those empty buildings. After some posting across the internet he finally found out why (and anyone who has worked in such installations immediately knew the answer) - the building was contaminated with highly radioactive dust that is nearly impossible to clean up so just lock it off. Yep, that guy sure showed them by breathing in some gamma emitting particles.
I have been in facilities where real weapons research was going on and it had fully manned machine gun turrets and was (maybe) mined outside of the official walkway (the mines were according to lore at the area - hard to know if true though the machine guns were quite visible and would have been sufficient. I know much of the lore about the area I worked in wasn't true and the machines guns should have been sufficient). Never knew what they did there more than "weapons research" - I ate lunch a time or two with one of the principle designers of our Neutron Bomb and that was where his office was and that is far as I knew anything (and wanted to know - you don't ask about those areas).
"FOUO/Unclassified-Pretty much the catch-all for government owned IT-equipment."
I would add that much of what you post is on machines that the IT guys managed. I worked in the research division and because our research was on scalable system administration we did pretty much what we wanted with them. I know a number of other researchers mostly administered their own system as they sometimes required some software that IT wouldn't support.
The security of those systems ranges from good to horrid, shortly before my contract ran out we had an incident where well over 50 systems were compromised due to those peoples computers using a symmetric SSH key system from their office in a university (in this case the person didn't log out of a public terminal telnetted - yes telnetted - to their university desktop) to *all* the machines they had access too. Amusingly enough the hacker had access to the Big Iron machine (an IBM sp2) and didn't know what it was so he went for more desktops. It was an amusing meeting - after two hours of listening to a guy drone on about ssh keys, telnet, encrypted and unencrypted connections, keyloggers on public terminals, etc he asked any questions. First one: "What's SSH?" (note this included the chemists, physicists, biologist, and a few more "..ists" that had no real reason to know, we were all were giggling at this point).
Unfortunately some of the researchers were not very good at watching what systems they ran on. I know of at least once where someone was having trouble running on our stuff and I (being root) logged into their account and debugged their software. Found out later the reason they freaked when I told them what was wrong was that they were in the "sensitive unclassified" category. They had no idea root could do that and figured we normally ran a tighter ship security wise than the official systems did (which in some ways was true, in others not and they found out the latter the hard way).
*note - anonymous because even though it has been a number of years still not sure what I am allowed to talk about. So feel free to write me off