Best Way To Avoid Keyloggers On Public Terminals? 701
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 don't type (Score:5, Interesting)
Re:I don't type (Score:5, Funny)
Re:I don't type (Score:4, Funny)
That's still too complicated! Passwords have to be stored in mydomain.com/index.html for easy access!
Re:I don't type (Score:5, Funny)
Re:I don't type (Score:5, Funny)
Re: (Score:3, Interesting)
http://www.mydomain.com/robots.txt [mydomain.com]
More info here:
http://en.wikipedia.org/wiki/Robots_Exclusion_Standard [wikipedia.org]
Re:I don't type (Score:5, Interesting)
Re:I don't type (Score:5, Funny)
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
Re:I don't type (Score:5, Insightful)
The only caveat with s/key is that you can't run the generator program (which takes your secret passphrase and tosses out a bunch of new one-time passwords) on an untrusted system. If you do, you've just blown the whole business.
So if you're going to be traveling and won't have access to any computer that you can trust, even a disconnected one, you need to generate a lot of passwords and write them down, and then cross each one off the list as you use it. (But hey, I think this lends a very nice cloak-and-dagger feel to computing that you just don't get very often.) Although I see that now somebody has whipped up a Java version of the s/key generator that will run on your cellphone, so it's not terribly likely that you wouldn't be able to run it.
I think SSH+skey is probably the most secure way of working from untrusted systems. The only downside is that it restricts you to working in a text shell, and you still have issues with websites, but at least you can do email and IM without worrying too much.
Re: (Score:3, Interesting)
My bank in NZ has a different policy. You are not permitted to use a public terminal with giving up liability protection.
But secure IM... please
Re: (Score:3, Funny)
Re: (Score:2)
I think the kyps.net solution is best, albeit cumbersome, and if you want true security, you'll need to implement the service yourself.
Re: (Score:3, Insightful)
-b
Re:I don't type (Score:5, Interesting)
Every bit of security helps, but I don't think we should be under the illusion that keylog-writers haven't caught on to these kind of tactics.
*This is based upon a talk I was recently at where a Symantec security analyst was asked about keyloggers.
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
https://www.paypal.com/us/cgi-bin/webscr?cmd=xpt/cps/securitycenter/general/PPSecurityKey-outside [paypal.com]
is an ideal solution to keyloggers.
~Dan
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
all the good keyloggers
This type of attack might also include a packet sniffer on the machine, rendering any clever input techniques useless. The only real way to avoid loggers/sniffers
Re:I don't type (Score:5, Interesting)
Re:I don't type (Score:5, Interesting)
Many methods can be imagined to add to the difficulty, including moving the window around, selecting other objects intermittently and entering keystrokes while they are active, and so on and so forth.
Remember, no single method is perfect, assuming there is a keylogger. Hopefully the keylogger owner is after the low-hanging fruit, which you won't be if you do any of these things. If he's actually targeting you specifically, you have bigger things to worry about.
Re: (Score:3, Interesting)
Re:I don't type (Score:5, Interesting)
tm
Re:I don't type (Score:5, Interesting)
You take that horrible security abomination of a webpage that gives you your passwords to cut'n'paste and you sprinkle it with freshly randomized obfuscation characters every reload (or once an hour so someone who DID find your secret webpage wouldn't be able to constantly refresh to ascertain your passwords). Then you can copy the whole line and then just select-delete the bits that don't belong. Since the garbage parts are different each time (or nearly each time) even a mouse grabber won't be able to reproduce the password string by reproducing the technique.
None of this solves the problem of a logger grabbing the POST data.
My best guess at a platform-independent solution is to VPN using secure authentication to a network you trust and proxy-browse from there. Get your keys all set up nicely at the trusted computer, and you shouldn't even have to type in any passwords, right?
Simple Answer -- (Score:5, Insightful)
Re: (Score:3, Insightful)
Seriously, when a terminal is not trusted everything you do on it can be watched. The attacker could plug into any application in the same way your debugger do and watch the bit directly from within the application, even if the executable is pristine and in you read-only USB dongle.
Don't put your password in a public computer. That's a way to be safe. The only possible solution for this
Context menu is your friend (Score:2, Interesting)
Simple idea (Score:4, Interesting)
Don't use public terminals (Score:5, Insightful)
Once you suspect a terminal is owned, that's it, game over, don't trust it. Probably not what you want to hear, and definitely not convenient for you, but every other solution is a compromise in security.
The ONLY alternative I could think of that I can stomach is to have a separate email address that you use only from public terminals. Change the password often and consider anything you say via that account to be as public as if it were announced over a PA system at an airport.
someone mod parent up please (Score:5, Insightful)
Re:someone mod parent up please (Score:5, Funny)
Re:someone mod parent up please (Score:5, Funny)
Re:someone mod parent up please (Score:5, Funny)
Re: (Score:3, Funny)
Re:Don't use public terminals (Score:4, Interesting)
I'll usually do some "click obfuscation" as I type in the password as well but I have a feeling that's mostly a placebo feature.
Re: (Score:3)
Now you'r making me really paranoid. Will that public terminal blow up? Was the last person to use it infected with ebola? Are a bunch of pervs scanning me with millimetre waves and publishing it on youTube? Is this terminal used by terrorists, and the police mistake me for one, so that I will be shot as I try to get on a train?
You're right, keyloggers aren't that bad. I hope that I only get my identity stolen and my bank accounts cleared out.
I don't think you truely can (Score:5, Insightful)
Obfuscate password entering process (Score:5, Insightful)
I'm using this when I absolutelly need to use web cafe/etc....should fool most keyloggers, I guess. I still change my password afterwards as soon as possible.
Re: (Score:3, Interesting)
This does not necessarily work. Complacency that once upon a time it fooled keyloggers does not make it a sound tactic for evading them.
The strategy is well-known, and you can expect an advanced keylogger to detect it.
The keylogger can pick up on the keystroke and identify the active window handle. The text boxes that have password masking turned on stick out like a sore thumb.
Identifying the cursor position is not hard.
The mouse coordinates you click on will be within the text box and wi
use a temp account (Score:2, Insightful)
S/KEY (Score:5, Interesting)
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).
Re: (Score:3, Interesting)
What I'd really like to skip the PDA. Instead just take a page of say 100 one-time passwords. But how might one set this up? I'm handy with perl but I'd prefer a robust worked out solution.
Re:S/KEY (Score:5, Informative)
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
# to enable this functionality.
# (Replaces the use of
# 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
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: (Score:3, Informative)
Python impl. [sourceforge.net]
Two things... (Score:2, Offtopic)
Why bother keeping it up to date? (Score:3, Insightful)
Several options (Score:3, Informative)
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.
How about this... (Score:4, Interesting)
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!
Re:How about this... (Score:4, Informative)
Auto Password Send? (Score:5, Interesting)
Now the system requires something you know (your password) and something you have (your phone).
If you're that worried... (Score:5, Insightful)
I'm really not being flippant here. The posters above have listed some ways around a basic keylogger, but there are other ways a system can be compromised. You could be dealing with a program that takes screenshots and/or reads the clipboard at random intervals. Hell, there could be a program on there that silently redirects you to bogus lookalike sites that steal your info. Not that this is likely, but it's possible.
My policy on using public access computers is that I only use them when I have no other choice, and the more valuable the data I need to protect, the less likely I am to use one.
There are so many more attack vectors than a keylogger that, if I were you, I wouldn't just focus on that one thing. If your data really needs to be secure and accessed remotely, get yourself a laptop and a data card from one of the cell carriers. At least that way, you can keep physical control over your machine and avoid the risks of using a hotspot. Of course, if you think that someone will be able to tap into your wireless connection through a cell phone carrier, than you likely have more issues than we can address here.
Re:If you're that worried... (Score:4, Insightful)
That would be dead easy to do on the part of the public terminal provider... Figure out the top (say) 10 banks that visitors normally use. Set up local DNS records that point to your phishing site, or just use IP DNAT to redirect them. Install certificates for each of your phishing sites on the public terminal so that they are trusted.
Unless you knew the fingerprint for your banks certificate you'd never know the difference, and even that could be spoofed if they had complete control. If they were using IP DNAT then even the IP address would appear correct.
In short, there is no solution if you don't have complete control over your terminal!
In the above example, if the phishing site was acting as a 'man in the middle' then even 2 factor authentication on logon wouldn't help you. Once you'd logged on the phishing site could just report 'Connection error - please try again later' and then go off and do stuff on its own. If you had it set up so that any funds transfers required another authentication with your 2nd factor device then that simple hack wouldn't work but it wouldn't be too hard to come up with something that did.
If you have control of the host... (Score:2)
A LiveCD will not save you from a hardware based.. (Score:5, Informative)
KeyScrambler (Score:4, Interesting)
Re: (Score:3, Insightful)
Think about it for a minute (Score:5, Insightful)
If you've got to stay in touch on the road then take your own machine along - either a laptop or a portable device like an iPhone. You can find wireless access almost anywhere and while that wireless may be hacked, at least the machine you're using won't be.
The suggestions to use a Linux CD or Firefox from a USB memory stick aren't going to give you the safety you're looking for. Even if you boot from a CD, the system will still read the MBR from every drive connected to the system when it boots. If that MBR is "adjusted" then that machine is compromised no matter what you do.
Remember: do NOT enter any information into a public terminal that you wouldn't want to publish in the newspaper.
Synchronized Random Code List (Score:5, Interesting)
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.
Texting 1 time password (Score:5, Interesting)
AFAIK it's still in use and have never been cracked.
Re: (Score:3, Funny)
damnit, why didn't i think of that one you bastard =)
If I NEED access to the internet... (Score:5, Insightful)
IMO, the use of a public terminal for private purposes is the height of stupidity.
"In particular, how do people with Mac..." (Score:5, Funny)
I bring it with me - I have a macbookPro and I don't use public terminals. You can get cooties that way.
RS
Use VNC with temporary passwords (Score:5, Interesting)
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
Simple answer, don't bother (Score:5, Insightful)
I was once friends with a guy that carried around a PS/2 keylogger that he would plug into university terminals for a day or two then pick it up later. He just wanted to see what he could find. He found everything from people doing homework, cybersex, and even bank info. Now if he was actually out to do harm, he could have really made things bad for hundreds of people.
If it's not yours then just assume that it has a loudspeaker on it broadcasting everything you do to everyone around you.
And for those that think cut&paste, screen keyboards, etc will protect them. I personally installed a keylogger on a friend's PC to catch her then, 12 year old son, looking at porn. The log files had a play button which would replay every mouse movement, screen change, and keyboard input for up to 96 hours. This was about 7 years ago so I'm sure they've gotten better.
Use Microsofts On Screen Accessibility Keyboard. (Score:3, Informative)
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.
Changing password list. (Score:3, Interesting)
Keep a copy of the list with you, SSH in (or whatever), and run the script immediately.
Assuming no-one tries to log in from the time you enter your password in the Internet cafe to when you run the script, and change it, it's a perfectly safe method.
Anybody tried a Blackdog? (Score:3, Interesting)
Don't use an open source browser! (Score:3, Interesting)
Comment removed (Score:3, Interesting)
Ummm, buy a laptop... (Score:3, Informative)
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.
Re:Anonymous Coward (Score:5, Interesting)
Not all keyloggers are software.
Re:Anonymous Coward (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Re:Phone? (Score:4, Interesting)
Frankly, you ARE better off with some form of wireless PDA or PDA Phone... but if you want to be cheap, it will still cost you time.
Re:Phone? (Score:4, Insightful)
All the sites I patronize have, thus far, operated perfectly fine without flash. Once they begin to demand flash or other such crap, I'll find alternatives or do without. Flash has FAR too much risk of being abused (and has been) in the past. Same with javascript and especially Java. I surf for information, not flashy buttons and popups.
Speaking of funny, I checked out "classmates.com" recently, and I must say DEAR GOD... (my personal profile is full of bullshit per my specification) ye gods those people have put up everything but their online banking password on those entries. But that isn't the worst part. The worst part is loading that website, and receiving twenty different batches of advertising tracking cookies, three batches of tracking cookies from the site, and watching it load and move around slower than mollases.
Is that truly necessary? Hell, they charge these people for memberships. I actually test drove a membership some years back just to see, and even then, even for "paying members" they still didn't remove the adverts and other sluggish bloat on their site.
I restate my question. Is that kind of bloat TRULY necessary?
Re:Phone? (Score:5, Funny)
>Is that truly necessary?
The LAST thing I want is contact with anybody from my High School.
So
Re: (Score:3, Interesting)
However, given that they SELL most of this info (I'm fairly sure they do, judging some rumors that I've seen propagate to other databases.) By the same token, they're a lovely
Re: (Score:3, Insightful)
But anyway: Hardware-based keyloggers. Even if you check the keyboard cable, it could still be installed inside the case - a lot of USB ports aren't soldered to mainboard. Or it could even be inst
Re: (Score:3, Funny)
Re: (Score:3, Interesting)
For the most die-hard paranoid, one-time passwords are the only real security you can offer against capture (such that even if they're captured, they're useless), presuming you have a way to look up the one-time password without exposing subsequent passwords (ie, you can't just have them written all on the same sheet of paper, or the pinhole camera could capture the next ones).
Even R
Re: (Score:3, Insightful)
Depending on how much random stuff you're willin
Re: (Score:3, Interesting)
You have to assume you're going to be keylogged and design a system that is resilient to it.
I hide SSH keys (encrypted with passwords) around the internet on various web servers. Then i only need to download (and run) portaPUTTY and vnc viewer before i can see a desktop with a web browser with all my passwords se
Re: (Score:2)
Re:Phone? (Score:5, Informative)
Re:Phone? (Score:4, Insightful)
Re: (Score:3, Informative)
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.
Re:Phone? (Score:4, Informative)
Re:Phone? (Score:4, Funny)
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
The risk to my company of losing it's List-X status (and hence 40% of our work) if there's a breach is too high to be flexible in this regard.
Re:Phone? (Score:5, Interesting)
Re: (Score:2)
Can you buy a wifi USB dongle? As far as trusting hotel room Ethernet... well, it's better than a public terminal.
Re: (Score:3, Informative)
Re:Simple solution (Score:4, Insightful)
The point isn't whether you think that what you're doing is OK. The point is that you aren't authorized to make that decision.
Re:Simple solution (Score:5, Informative)
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:Simple solution (Score:5, Interesting)
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
Re:Hardware encrypted USB key with preinstalled ap (Score:5, Insightful)
I'm aghast at all the people suggesting nonsense like copying and pasting or making silly efforts to run trusted copies of applications. If the OS is compromised, absolutely nothing you can do at higher layers that will not be compromised.
As (terrifyingly few) people have already said, the answer to the original question is that you can't. If the machine itself is untrusted, any attempts to add security atop that is just building castles on quicksand.