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 don't type

[dmomo (256005)]

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.

Re:I don't type

[Anonymous Coward]

I store my password at mydomain.com/password.txt so I can just copy/paste when I'm remote.

Re:I don't type

[JayAEU (33022)]

I store my password at mydomain.com/password.txt so I can just copy/paste when I'm remote.

That's still too complicated! Passwords have to be stored in mydomain.com/index.html for easy access!

Re:I don't type

[mikesd81 (518581)]

That's still too complicated! Passwords have to be stored in mydomain.com/index.html for easy access!

Complicated how? And why index.html? Browsers show txt files too.. I don't think it's a great solution if someone is looking over your shoulder or knows your domain name (like a shady acquaintance).

Re:I don't type

[yo303 (558777)]

http://mydomain.com/woooosh.html [mydomain.com]

Re:I don't type

[complete loony (663508)]

Start > Programs > Accessories > System Tools > Character Map. But a software clipboard hook will still get you.

Re:I don't type

[electrosoccertux (874415)]

Start > Programs > Accessories > System Tools > Character Map. But a software clipboard hook will still get you.

Score: -1, Microsoft User

Re:I don't type

[Kadin2048 (468275)]

Ah yes, under that assumption, what did he do about the password needed to log on to ssh?

This is a solved problem. You use a one-time password system, like s/key [wikipedia.org], or one of its many variants.

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:I don't type

[JustinOpinion (1246824)]

Apparently* many modern keyloggers also capture the clip-board and record mouse movements (so as to defeat those "visual keypads" that some banking sites have implemented to thwart keyloggers). I guess the additional steps of assembling your password from pieces will prevent some attacks (e.g. where the attacker just uses the logged keystrokes, in order, for a dictionary attack on your account)... but a determined attacker may still be able to reconstruct your password from the combined key/mouse/clipboard history.

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:I don't type

[dietlein (191439)]

Yes, and forms that don't allow pasting (certain Flash forms, etc)???

Easy. If your password is "secret", type "s", then something random, like "jd#'2;Knfn>", then highlight those last characters (except for the "s"), and type "e". Continue until done. Takes a while but is fairly safe.

Re:I don't type

[dietlein (191439)]

Your points are correct to some extent. My method is indeed invalid if the following are simultaneously true: (1) the password field is using a fixed-width font, (2) all keystrokes and mouse activity are timestamped, (3) the password field coordinates on the screen are known.

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:I don't type

[Tmack (593755)]

Or setup a webpage that generates a random screen of characters including all characters you might use. If they logged mouse location, and even know the url to the page you used, it wont be the same, and unless they took screen shots or also timestamp and save the copy buffer, wont know what was actually used.

tm

Re:I don't type

[neomunk (913773)]

How about a webpage like the one you're talking about bred with the horrible horrible idea of a webpage containing your passwords.

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

[barbam (1134455)]

Umm -- simple answer, don't access trusted information from an untrusted terminal? You can have no expectation of privacy while using that machine.

Simple idea

[Mieckowski (741243)]

You could type the letters out-of-order, then rearrange them using drag+drop. Someone with a keylogger probably wouldn't bother using the mouse input to figure it out.

Don't use public terminals

[syousef (465911)]

I'm not trolling here. If you're being keylogged, then even if your password isn't stolen, every single thing you do on that computer must be treated as public. Emails would be keylogged too.

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

[Travoltus (110240)]

When it comes to security, the best answer usually becomes the most unpopular and hard to swallow.

Re:someone mod parent up please

[Strange Ranger (454494)]

I thought the best answer would be using a powerful electromagnet or maybe a defibrillator on the offending machine.

Re:someone mod parent up please

[eison (56778)]

No, nuke it from orbit, it's the only way to be sure.

Re:someone mod parent up please

[Cruciform (42896)]

When it comes to security, the best answer usually becomes the most unpopular and hard to swallow.

Hard to swallow? Then you don't want to know where I hide the thumb drive with my SSH keys.

Re:Don't use public terminals

[faust2097 (137829)]

I make one address on gmail for each trip I take and have my other important messages forward on to that and tell my friends and family to use it. The most important part is that the password to this temp account is 100% unique.

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.

I don't think you truely can

[JazzXP (770338)]

Any smart keylogger will look at the raw text behind any password field on a website. Cut and Paste etc would be useless.

Obfuscate password entering process

[sznupi (719324)]

Enter your password in a different order than it is spelled? Simplest example: given your pass is "password", first write "pasrd", click between 3rd and 4th asterisk, complete it by entering "swo". The more complicated, the better.

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.

S/KEY

[Ernesto Alvarez (750678)]

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).

Re:S/KEY

[Ernesto Alvarez (750678)]

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.

How about this...

[stwf (108002)]

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!

Re:How about this...

[timeOday (582209)]

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.

Auto Password Send?

[cgenman (325138)]

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).

If you're that worried...

[ISurfTooMuch (1010305)]

...then don't use a public terminal.

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...

[jamesh (87723)]

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.

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.

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

[Joe The Dragon (967727)]

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

KeyScrambler

[techMech (1278336)]

You could try running Portable Firefox with KeyScrambler from a thumb drive. https://addons.mozilla.org/en-US/firefox/addon/3383 [mozilla.org]

Think about it for a minute

[Whuffo (1043790)]

When you're talking about a public terminal - a machine that everyone and his dog has had access to - then you have to assume that it's totally compromised. You can't take countermeasures against exploits that you don't know and can't identify.

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

[MrSteveSD (801820)]

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.

Texting 1 time password

[Knightman (142928)]

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.

If I NEED access to the internet...

[riprjak (158717)]

...I carry my own means to do so. Wether that be a smartphone, iPod touch, PSP, laptop with wifi, wireless broadband or (a consideration when I am travelling in developing nations) a satellite modem...

IMO, the use of a public terminal for private purposes is the height of stupidity.

"In particular, how do people with Mac..."

[Ralph Spoilsport (673134)]

"In particular, how do people with Mac or Linux home computers deal with this?"

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

[Shazow (263582)]

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

Simple answer, don't bother

[AsmordeanX (615669)]

It blows my mind when I see someone logged into their bank/email/etc from a public terminal.

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.

Re:Anonymous Coward

[corsec67 (627446)]

What protection does that afford against a physical [thinkgeek.com] keylogger?

Not all keyloggers are software.

Re:Anonymous Coward

[TerranFury (726743)]

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.

Re:Phone?

[DaedalusHKX (660194)]

Setup a Knoppix or other (Ubuntu?) livecd using the available tools. Don't worry about anything except setting up an IPSEC tunnel, with preset keys to a machine at home. Presumably this machine should be pulling down your email and other data that you need to access. Since the boot is fresh from a trusted CD it defeats software keyloggers, and using the secure keys also sets it up so you don't have to worry about hardware keyloggers getting your passwords.

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?

[fishbowl (7759)]

>Is that truly necessary?

The LAST thing I want is contact with anybody from my High School.
So ... no.

Re:Phone?

[1729 (581437)]

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:Phone?

[maglor_83 (856254)]

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

Re:Phone?

[Hal_Porter (817932)]

Identity Theft International bans phones but offers free internet access in most cities. Don't worry about that funny message about site certificates not matching, it's just our https proxy. Click OK! Click OK!

Re:Phone?

[PyroMosh (287149)]

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.

Re:Hardware encrypted USB key with preinstalled ap

[Onan (25162)]

Which does you what good, exactly, when malicious software already has control of the OS and can see (and alter) everything that passes through memory?

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.

Re:Simple solution

[Hunter-Killer (144296)]

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:Simple solution

[Anonymous Coward]

"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 :)