christian.einfeldt writes "Washington Post Security Fix columnist Brian Krebs recommends that banking customers consider using a Linux LiveCD, rather than Microsoft Windows, to access their on-line banking. He tells a story of two businesses that lost $100K and $447K, respectively, when thieves — armed with malware on the company controller's PC — were able to intercept one of the controller's log-in codes, and then delay the controller from logging in. Krebs notes that he is not alone in recommending the use of non-Windows machines for banking; The Financial Services Information Sharing and Analysis Center, an industry group supported by some of the world's largest banks, recently issued guidelines urging businesses to carry out all online banking activities from 'a stand-alone, hardened, and completely locked down computer system from where regular e-mail and Web browsing [are] not possible.' Krebs concludes his article with a link to an earlier column in which he steps readers through the process of booting a Linux LiveCD to do their on-line banking."Police in Australia offer similar advice, according to an item sent in by reader The Mad Hatterz: "Detective Inspector Bruce van der Graaf from the Computer Crime Investigation Unit told the hearing that he uses two rules to protect himself from cybercriminals when banking online. The first rule, he said, was to never click on hyperlinks to the banking site and the second was to avoid Microsoft Windows."
And asking me for my Mother's maiden name is really that much better? Or how about showing me an image that I picked out but will soon ignore after seeing that it never changes?
I like the security token [wikipedia.org] concept myself. It doesn't rely on easy to figure out (Mother's maiden name, hospital you were born at, etc.) information and is easy enough that most lusers can figure it out quickly. I don't understand why more financial institutions haven't adopted them.
Security tokens are the second factor in two-factor authentication. The banks are just convinced that another-password is good enough, mostly because it's cheaper than doing it right.
Of course it's cheaper than doing it right. They've managed to twist bank robbery do to their lack of adequate security into identity theft that they blame on the costumer and force the costumer to suffer all the financial consequences. It's the perfect scam. If you walk into the bank with a fake id and steal money it's never been blamed on the costumer.
What in the holy hell do people who make costumes have to do with any of this? I would be more concerned about the banks blaming things on their customers.
What in the holy hell do people who make costumes have to do with any of this?
If you are going to rob a bank anonymously you absolutely need a costumer. The costumer is the person who dresses up the bank robber in his archetypal stripped shirt and handkerchief mask. Costumers are typically blond with big... ideas.
As a victim of Identity Theft, I can tell you that banks and credit agencies just don't care. The bank writes off the loss due to fraud. The credit agency shrugs their shoulders at bad information in your credit file and tells *you* to fix it (while they happily go on reporting the bad information). In the case of stolen credit card numbers, the credit card company simply issues a new card and reverses the fraudulent charges. Meanwhile, the thief has their new television and the store is out a few thousand dollars.
In my case, the credit card company opened a line of credit for "me" even though the online application contained the wrong Mother's Maiden Name. I only found out about it because the thieves put in for a rush delivery of the card and *then* changed the address on the account. The card wound up at my house instead of their house/drop box/whatever. The incorrect maiden name and quick address change didn't set off any fraud alerts. Neither did "me" trying to get a $5,000 cash advance on the card prior to activating it. And when I called them about it, they refused to give me any information because "I might run out and kill the thief and then they're liable." They even gave the police department the runaround.
As I said, they just don't care. They'll do everything in their power to protect themselves. Even if protecting themselves in the short term means the identity thief gets away and commits more fraud against their business in the long term. In the end, you are only important to them insofar as how much green they can make off of you.
True, but it doens't have to be that expensive to do right. My bank offers two different solutions for the second-factor. One is s crypto-key tokenthing that they send you to hang on your keychain. (so you log in with a password + a 5-digit security token from the gadget)
The other is, quite simply your mobile phone. You enter your username and password, if correct, they send you a SMS with a 5-char one-time-password, you enter this and are in.
Yes, it adds 10 seconds to the login-procedure, but it's a very efficient way of stopping keyloggers and malware from learning how to access your account. Even if they successfully snoop your password, that doesn't help them aslong as they can't ALSO intercept SMS-traffic to your cellphone. This isn't IMPOSSIBLE offcourse, but it sure as hell raises the bar.
And asking me for my Mother's maiden name is really that much better? Or how about showing me an image that I picked out but will soon ignore after seeing that it never changes?
Those are both the same factor, just like a user's password.
Security factors are
something you know
something you have
something you are
In order to qualify as "two factor", you must have two of those (no, having two of the same factor doesn't count.)
So passwords, personal question, and favourite image are all examples of "something you know", and don't represent two-factor authentication.
The Security-token would be an example of "something you have", and thus combining them with a password would be two-factor authentication.
Security tokens store internally a crytographic key or a one time pad. It is mathematically impossible to find out what the secret key/OTP is on these devices from readouts on the display. You have to steal the device and read the bits using an electron microscope. Even if you could do that, it would be very difficult to create a cloned copy of the device and return it to the owner's possession in any length of time.
Thus, the inherent security is obvious : in order to break into an account protected by a keyfob, one absolutely HAS to steal the actual keyfob. That vastly limits the vulnerability : if the user still possesses the card, they KNOW they haven't been hacked to 99.9999999% certainty. Furthermore, only individuals who come in direct contact with the user have a chance to steal the card, and they cannot do so secretly - you could freely give your credit card to a waiter at a restraunt and have him use the keyfob with the secret code displayed, and know that the card could not have been skimmed.
And, of course, the moment the user of the card notices that it is missing, he can call the bank and cancel it and ask for a replacement, eliminating any further losses. If your account information had been compromised, you might not realize for month(s).
I will agree with you on "something you are" authentication. Even if you owned some kind of biometric reader and used it to log on to your bank, it is not any more secure than a password because a fingerprint or DNA sequence is a static piece of authentication. Well, ALMOST....
Theoretically, using technology not yet available, you could give the bank a sample of your genetic material and essentially have security whereby the bank asks your home DNA scanner "give me n->Z portion of the user's genome". This would only be a practical security measure if whole genome sequencing were still very expensive.
So in the case of a properly designed security token, it ISN'T just data on the Internet. The reason is that it isn't as though the "something you have" is a card with a number on it or the like. If that were the case then yes, discover the data and you are good. However they don't work like that. There are two related systems that I've seen:
1) A card that gives you a number. What happens is when you want to log in, you push a button on the card/device and it hands you a number. However the number isn't fixed, it changes with time. You need the right number for the right time. The way it works is a crypto system. It uses the time and a key in the device to provide the output. The other end then can calculate the correct number needed. The only want to get the number is to have the device, or find out what the key is on the particular device.
2) A challenge/response system. Here you plug in a USB key or smart chip. The device you are connecting to then sends a challenge to your device, usually something in the form of "Sign/encrypt this message." Then again, public key crypto comes in to play. Your device encrypts the challenge or signs it or whatever and sends it back. The server checks that result against what it ought to get. If the answer is right, in you go.
In either case, the only way to get the data is to either find out the key, or to get your hands on the device. A simple intercept won't do it.
As for your "gun to the head" thing, well of course that gets around it. There is NO SUCH THING as perfect, unbreakable security. I think some geeks delude themselves in to thinking there is because you can build a computer that is at least seemingly perfectly secure. However in the real world there is no such thing as perfect security. There is only security that is better than what anyone is going to try.
I mean I can secure against your gun to my head thing: I hire armed, trained, guards. You try to come at me with a gun, they take you out. So you can counter that, you get trained snipers to kill them at long range. So I counter by traveling only in secure armored vehicles, so you counter by kidnapping my family, so I counter by securing the too, and so on. However at some point, I got past what you could reasonably do, and more importantly what you'd reasonably do. In fact, with good two factor authentication, I am already past it. You will not come and put a gun to my head to get at my bank account. The money isn't worth the risk. So I don't need to worry about that kind of attack. My security is good enough.
That's all it is ever about. That's even what it is in the case of extreme security. The government does not delude itself in to thinking that having tons of armed guys around, say, the CIA headquarters makes it impervious to attack. There are always ways to attack it. So why bother? Because it makes it impervious to any attack that anyone might actually be able to try to pull off. Yes, in theory you could find a way to kill all the guards, take the right people hostage, etc, etc. In reality, you couldn't even come close, you know this, and thus you won't even try.
It is secure against REAL threats, and that is what matters. Same deal applies to your bank account, however since you are protecting a small amount of money and not national secrets, two factor authentication and some vigilance on your part will suffice, armed guards are not necessary.
That's not two factor, it's one factor. It's something you know, in two parts. A key fob introduces something you have.
A big problem with what you described is that 40 images to choose from is like adding one more character to your password, allowing lowercase, numbers, and 4 other punctuation marks only.
It doesn't add much to security at all, in other words.
A little two factor authentication would be nice to see in American banks. Passwords just aren't adequate any more.
And how would an n-factor authentication scheme help when software on your computer is logging keystrokes, mouse gestures, and capturing images of your screen and then sending them near realtime to the bad guys?
If your computer has been compromised in this fashion, you've already lost. For you car enthusiasts, it's like adding additional locks to the car doors -- it doesn't help if the windows (haha) are already broken.
If your computer has been compromised in this fashion, you've already lost. For you car enthusiasts, it's like adding additional locks to the car doors -- it doesn't help if the windows (haha) are already broken.
What's the computer equivalent of the "This car protected by Smith & Wesson" bumper sticker?
What's the computer equivalent of the "This car protected by Smith & Wesson" bumper sticker?
This computer is protected by retaliatory DoS attacks? I guess that is the best we can hope for until we work out a better implementation of PoIP (Punched over Internet Protocol).
You realize that the way two factor security is supposed to work is that is requires you to know something and have something right? The way that two factor security is usually done from what I've seen is requiring a password that the client knows and a rolling code from a small device the client has. As long as a bank does not allow that same rolling code to be used twice it doesn't matter what kind of keystroke logging, mouse gesture capturing, or screen recording is used nor how fast it is sent to the bad guys.
For you car enthusiasts, it's like taking the engine with you when you leave the car. Even if the car is hot-wired, it's not going anywhere without that thing you still have.
Though I agree two factor authentication is useful, the 'taking the engine' analogy overestimates the difficulty of breaking through it.
All the scammers have to do is instead of recording your keystrokes, gesturing, etc., they display a 'fake' copy of the bank to you through whatever software they have installed on your computer. They take the information you think you are sending to your bank (but are sending to them instead) and instantly have their scripts login to the site from their own systems (or some other bot on the net).
If they prevent your initial login to the site from happening, they can use your username + password + rolling code themselves if their software auto logs in.
This of course requires a user to go to a phishing site (miscellaneous.scammersite.com or something more complex), or requires the phisher to own the user's computer enough that they can intercept their connections & deal with the SSL certificate issues) while the phisher's automated software automatically goes to the real miscellaneousbank.com site.
The Commonwealth bank in Australia (and probably many others) sends you a random code via SMS to your phone that you have to type back in to the site in order to transfer money to an account you've never transfered to before.
And how would an n-factor authentication scheme help when software on your computer is logging keystrokes, mouse gestures, and capturing images of your screen and then sending them near realtime to the bad guys?
The way it works here with some banks in Australia is they send you a code via SMS when you try to issue a transfer from Internet banking. You need to enter the code into the website to continue the transaction. So the extra factor here of having the phone offers a pretty useful extra layer.
And how would an n-factor authentication scheme help when software on your computer is logging keystrokes, mouse gestures, and capturing images of your screen and then sending them near realtime to the bad guys?
Because a 2 factor authentication token like an RSA key changes every 10 or so seconds so by the time Bad Guy #1 has finished parsing that log the 2nd authentication factor is out of date. The far cheaper way of doing this which most banks in Australia have started using is a one time password sent to you via SMS. This password works one time only (hence we call it a one time password, geddit) so if the Bad Guys(TM) get the entire password in real time and are reading their logs in real time then they still cant use it as the password has already been used.
Yes it's a band aid solution but at least it's a decent kind of band aid. The alternative is complaining that it doesn't work and then having nothing happen because no one has a better practicable idea.
Also, it's trivial to redirect the POST to login.cgi or add an entry to/etc/hosts for bank.com to a different site that just presents a 'failed to login' instead of logging in. Meanwhile your password, security code etc has been sent off to the bad guys machine which does an automated "transfer *.* funds to x" script using these credentials.
Because a 2 factor authentication token like an RSA key changes every 10 or so seconds so by the time Bad Guy #1 has finished parsing that log the 2nd authentication factor is out of date. The far cheaper way of doing this which most banks in Australia have started using is a one time password sent to you via SMS. This password works one time only (hence we call it a one time password, geddit) so if the Bad Guys(TM) get the entire password in real time and are reading their logs in real time then they still cant use it as the password has already been used.
None of this will work with the problems described in the article, if someone has control of your computer then you're screwed no matter what kind of authentication you have. In one of the examples they specifically stated that crackers used the token code and delayed the customer's request:
Johnston's bank requires customers to enter the code from a Vasco security token. But the thieves - armed with malware on the company controller's PC - were able to intercept one of those codes when the controller tried to log in, and then delay the controller from logging in. Indeed, Johnston said the company's computer logs show that the controller logged into the system while the series of thefts was already in progress.
So, instead of the cracker getting blocked the customer would have been blocked because the "malware" made the customer's request come in AFTER the cracker's. If you were really clever you'd program the thing to intercept all the communication before it gets encrypted to go out to the bank and then fake the returned data so the user doesn't know that you're toying with them (yes, you can intercept the crypto library calls - I toyed with this some to get the Red Alert 3 Beta working on Wine). I don't know about you, but I can't think of a solid way around this interception (except having the bank only allow logins from a special custom browser that they load on a Live CD).
A little two factor authentication would be nice to see in American banks. Passwords just aren't adequate any more.
Per TFA, the banks in the two cases mentioned in the summary used two factor authentication. The hackers' malware delayed their access, and the hackers used a VPN tunnel to access the bank through the compromised computer.
Its not just "linux vs Windows" but "trusted boot": All you need to rely on is that the live CD is OK and your BIOS is not corrupted and you can effectively safely connect to your bank.
I use it myself for my Schwab account, with the added bonus of there is enough math to show active traders lose big, so don't trade active, which goes into play here.
"Washington Post Urges Thieves To Distribute Linux LiveCDs"
A few racks full of CDs in a highly visible place, or even cheap preloaded USB drives delivered right to the mark's front door along with a friendly letter explaining how running Linux would help improve security and thwart The Bad Guys could make your job of stealing from the clueless even easier than before.
Exactly. The problem is that many users click on any thing that is bright and shiny. While some problems are caused without user interactions, other clearly come from users navigating towards "carefully constructed web pages". There is really no way to stop this. One CD with 'naked women version of secure linux' on it, and it would be open season for the office bank accounts.
The only real solution is to make banks liable for online bank fraud, just like credit cards are liable for credit fraud. The c
Well, don't do online banking. Or, use a totally separate computer to do online banking. Only use the web browser to access one's bank account. Or look for those "freeze" type software, which makes the harddrive essentially read only. Also, it doesn't hurt to check which processes you are running, and whether any of those are unusual.
The browser on a LiveCD may be out of date. How about a USB flash drive that can save your ISP settings and can update the browser? Banks could distribute them for the price of the flash drive as a safer option for online banking.
Of course, a diskless system running Linux would reduce the chance of malware on clients, but perhaps if a company is dependent on Windows, almost as good security (and I state almost) would be obtained from denying admin access and using something like DeepFreeze, Windows SteadyState, or similar?
Combine DeepFreeze with AppLocker, some decent enterprise antivirus utilities, BitLocker, and the usual physical and BIOS protection on a machine, and one can make a decently locked down terminal that can cleanly run Windows apps. Should additional software be needed, no need to install it, just use something like VMWare ThinApp and have it runnable from a central location.
There is nothing wrong with a diskless system and booting from a CD-ROM. However, unless one creates a custom image with reliable enterprise level auditing tools, it becomes difficult to extract data from a group of PCs (and this is important for larger businesses come tax season, or regulatory compliance), and it is definitely an issue to add or update software without a reboot, unless it is a precompiled binary on a central server that people run.
Also, instead of running live CDs, why not consider going to a vendor like Wyse and going with truly thin technology? This way, there is little to no fiddling with the client side. If a thin terminal has a problem, just swap it out for another one, chuck the old one in the RMA box and be done with it. This is arguably a lot easier than the cost for maintaining standard PCs [1].
[1]: I'm primarily intending enterprise level here. For some SMBs, it is a lot cheaper to go with a boot CD and a generic PC, but for larger companies, it may mean more futzing around with stuff for their IT staff, especially on the scale of thousands of endpoints. If I had a startup with a call center of 5 people, PCs are a lot more economical. However, 500 to 1000 people in a non-technical call center, then I'd take a serious look at thin terminals and a beefy internal network fabric.
...it's more a matter of a read-only medium. If people start doing this is greater numbers, all the evil people will do is start distributing hacked ISOs pretending they're legitimate. This also doesn't do much for machines which have been hacked at a BIOS/bootloader level. In fact, if the PC is set to boot to the hard drive and the trojan supervisor is smart and puts up a boot menu that looks bios-ish (ie, allowing you to select the boot device), 95% of users would never notice. So unless Linux LiveCDs start running checks to see if they're being virtualized, this isn't a very good safety net.
Also, honestly, how many people do you think check the MD5 sum on an ISO? Hell, I've never had a RedHat/Fedora disc that passed its self-check. I gave up on that ages ago.
A bank with any technical savvy would be immediately preparing a LiveCD/USB distro that boots as quickly as possible into a browser pre-configured with the bank's portal page set as the home page. The distro would contain nothing extraneous -- just enough for fast, safe banking. It would, of course, be thoroughly branded, but completely legit vis a vis source code and license notices. Give them away in the mail, or even sell USB drives.
Sorry to break it to you, but doing this would be marketing-suicide for any bank that does this.
All of its competitors, and 99.9% of its non-tech-savy client base (so 99.5% of its clients including the tech-savy ones) would interpreat it as:
"This bank is SO insecure that they push me to use some kind of complicated pc configuration everytime before I go to their website. What a pain in the ass. Why can't they pay for their security problems themselves? I'm switching to another bank."
A good bank should educate their clients about being responsible online, not make their online banking even more inconvenient. A great bank should protect their client bank accounts even if their PCs and their accounts have been compromised. An horrible bank is one that expects its users to go through a long and complicated process for their "safety", disreguarding the negative user experience in the process, like you're suggesting.
I realize you're suggesting it as an option, not a forced policy, but the mere existence of the option will make average joe panic about its security and take for granted it's almost mandatory or he's fucked.
"Sir, there are some gentlemen here who say they are from an organization called the BSA. They want to see the license certificates for those Windows CDs we've been handing out..."
Because as the author explains in the comments, key loggers can run at the low level device driver level. At this level, it can hook key presses in a VM just as well as the host OS.
It's a pain, because nobody wants to go to the trouble of rebooting twice for the sake of paying a few bills. But it's the only way to be sure of a clean environment, unless your BIOS has been hacked. It's at least one good argument for the trusted platform, TPM, or whatever it is. In theory you could be sure that you are running only un-altered digitally signed executables and nothing else.
Presumably, if one is handling enough money that 100K or 450K could be stolen, one could afford a second computer and a 2 way KVM switch.
That doesn't solve the "but joe user doesn't want to reboot just to get to his overdrawn checking account" problem; but with real computers routinely showing up for $300 and lower, it isn't exactly an extremist position to suggest banking from dedicated hardware for any nontrivial amount of money.
Unless your browser is listening for incoming connections, or your bank is running third party banner ads(in which case, switch right the fuck yesterday), does a browser vulnerability really matter?
If you are using the LiveCD as a dedicated banking only environment, the only input your browser will see is your bank's website. If you can't trust user behavior, and want to really be sure, you could have it set to reject anything that doesn't have the bank's SSL cert. If your bank wants to 0wn you, you are already doomed. If no other site can reach your browser, your browser cannot be owned, no matter how buggy.
sigh. Just off the top of my head I can think of about a dozen attacks one could direct against a bank user who thinks they're bulletproof because they're using a Linux LiveCD. For example, booting off a LiveCD won't save you from the truncated SSL cert attack that was demonstrated in the direction of PayPal the other day.. only having an up-to-date browser will do that. Encouraging people to use unpatched known-vulnerable software to do their banking just so they can avoid malware on their regularly patched machines makes no sense at all. Of course, that's the extreme case.. suggesting people use a LiveCD of Linux instead of an unpatched copy of Windows XP SP1 is a different kettle of fish.
Yes, because everyone else has patched the bug.. Microsoft hasn't. But if you're using a LiveCD from before they patched the bug, then you are no more protected than the bozos using IE5.
In the immediate term, that seems like a terrible plan. Akamai are a reputable outfit; but they carry stuff for all sorts of people. Any domain-level trust/validation mechanism isn't going to tell you very much about something from them. Barring a fix, the financial site should host their own javascript.
In the broader term, it might be worth looking into further cryptographic mechanisms. For instance, with debian packages, you can safely download from an untrusted mirror or an http mirror that might be s
Yeah, it is great, because a huge part of on-line fraud is from keyloggers. Modern ones even record 'screencast' movies of you using your computer.
but it aint going to do much for your browser security unless you keep your LiveCD up to date
Between booting up and getting a DNS record for your bank how are they going to exploit a browser security problem? You could safely use unpatched IE5 to do online-banking. There might be some null-prefix type problems, but in reality going directly to your bank's site is pretty hard to get in between.
who says your CD burning software isn't infected - implications on trusting trust and all.
There are lots of different CD burning software, lots of di
Browser security is only an issue if you're visiting other sites, in the same session, on the same boot, on your LiveCD. Browsers on LiveCDs don't magically download malware from the internet by themselves - you have to direct them to. And most conventional malware must install itself - which won't happen on a LiveCD. There are a very few flash/js based attacks that work live in the same session - but really, if your either (a) your bank has third-party inline flash ads or (b) you don't trust java content from your bank's own website, then why are you banking with them online?
And going as far as questioning whether your CD burning software is infected is ridiculous. You can't be any more certain that your mouse doesn't have imbedded circuitry tracing your movement pattens, or your keyboard doesn't have a keylogger built directly into it, or the aliens aren't tapping directly into your cablings electromagnetic intereference patterns to directly access your bank account as you do. You're going to extremes purely for the point of argument, but although it may have passed you by, it was established several thousands years ago that "nothing is certain".
If you can imagine up scenarios like malware built into your cd-burning software specifically to target LiveCDs being used for online banking, I can't fathom how you trust a banks own employees enough to actually keep your money with them instead of under the mattress.
hey, who says your CD burning software isn't infected - implications on trusting trust and all.
I understand there's only a fine line between safety and paranoia, but the idea of a CD burning software having been compromised to detect Linux LiveCD ISOs and add a software keylogger to the system included therein is so far up in 'paranoia' territory it already got full citizenship and is considering running for president against "Elvis is hidden in Area 51" and "9/11 was planned by Israel to draw the US into the middle east".
Not Linux. Randomness comes from the time (hardware, persistent), but also from the randomness of network traffic and other driver miscellanea such as HDD head seek times, mouse movements, keystrokes, CPU temperature data, electrical noise on the power supply (with the right hardware)...
I can't say for sure, but I think Linux actually has the most secure random-number generator of any OS - excluding dedicated hardware. Enough that it can probably be fairly called true RNG instead for PRNG, as long as you use/dev/random instead of urandom.
Every single time you reboot your system clock has changed.
My battery is dead, you ignorant clod!
Actually, something like that happened at the Montreal Casino. The machines were shut down every day, so they would end up generating the same sequence of numbers. A guy named Daniel Corriveau noticed, played the numbers, won $600,000.
He initially claimed that he used chaos theory, and the casino claimed it was a bad random number generator. The reality was that the cmos batteries had been removed during development to make testing easier, and nobody put them back in, so every day, they started with the same seed. Simple incompetence. They paid the money after 2 weeks.
What about the banks? (Score:5, Insightful)
A little two factor authentication would be nice to see in American banks. Passwords just aren't adequate any more.
Re: (Score:3, Interesting)
And asking me for my Mother's maiden name is really that much better? Or how about showing me an image that I picked out but will soon ignore after seeing that it never changes?
I like the security token [wikipedia.org] concept myself. It doesn't rely on easy to figure out (Mother's maiden name, hospital you were born at, etc.) information and is easy enough that most lusers can figure it out quickly. I don't understand why more financial institutions haven't adopted them.
Re:What about the banks? (Score:5, Insightful)
Parent
Re:What about the banks? (Score:4, Insightful)
mostly because it's cheaper than doing it right.
Of course it's cheaper than doing it right. They've managed to twist bank robbery do to their lack of adequate security into identity theft that they blame on the costumer and force the costumer to suffer all the financial consequences. It's the perfect scam. If you walk into the bank with a fake id and steal money it's never been blamed on the costumer.
Parent
Re:What about the banks? (Score:4, Funny)
Parent
I'll tell you what... (Score:5, Funny)
What in the holy hell do people who make costumes have to do with any of this?
If you are going to rob a bank anonymously you absolutely need a costumer. The costumer is the person who dresses up the bank robber in his archetypal stripped shirt and handkerchief mask. Costumers are typically blond with big... ideas.
Parent
Re:What about the banks? (Score:5, Informative)
As a victim of Identity Theft, I can tell you that banks and credit agencies just don't care. The bank writes off the loss due to fraud. The credit agency shrugs their shoulders at bad information in your credit file and tells *you* to fix it (while they happily go on reporting the bad information). In the case of stolen credit card numbers, the credit card company simply issues a new card and reverses the fraudulent charges. Meanwhile, the thief has their new television and the store is out a few thousand dollars.
In my case, the credit card company opened a line of credit for "me" even though the online application contained the wrong Mother's Maiden Name. I only found out about it because the thieves put in for a rush delivery of the card and *then* changed the address on the account. The card wound up at my house instead of their house/drop box/whatever. The incorrect maiden name and quick address change didn't set off any fraud alerts. Neither did "me" trying to get a $5,000 cash advance on the card prior to activating it. And when I called them about it, they refused to give me any information because "I might run out and kill the thief and then they're liable." They even gave the police department the runaround.
As I said, they just don't care. They'll do everything in their power to protect themselves. Even if protecting themselves in the short term means the identity thief gets away and commits more fraud against their business in the long term. In the end, you are only important to them insofar as how much green they can make off of you.
Parent
Re:What about the banks? (Score:5, Funny)
Mitchell & Webb put this pretty well:
http://www.youtube.com/watch?v=CS9ptA3Ya9E [youtube.com]
Parent
Re:What about the banks? (Score:5, Interesting)
True, but it doens't have to be that expensive to do right. My bank offers two different solutions for the second-factor. One is s crypto-key tokenthing that they send you to hang on your keychain. (so you log in with a password + a 5-digit security token from the gadget)
The other is, quite simply your mobile phone. You enter your username and password, if correct, they send you a SMS with a 5-char one-time-password, you enter this and are in.
Yes, it adds 10 seconds to the login-procedure, but it's a very efficient way of stopping keyloggers and malware from learning how to access your account. Even if they successfully snoop your password, that doesn't help them aslong as they can't ALSO intercept SMS-traffic to your cellphone. This isn't IMPOSSIBLE offcourse, but it sure as hell raises the bar.
Parent
Re:What about the banks? (Score:5, Informative)
And asking me for my Mother's maiden name is really that much better? Or how about showing me an image that I picked out but will soon ignore after seeing that it never changes?
Those are both the same factor, just like a user's password.
Security factors are
In order to qualify as "two factor", you must have two of those (no, having two of the same factor doesn't count.)
So passwords, personal question, and favourite image are all examples of "something you know", and don't represent two-factor authentication.
The Security-token would be an example of "something you have", and thus combining them with a password would be two-factor authentication.
Parent
Re:What about the banks? (Score:4, Interesting)
Wrong.
Security tokens store internally a crytographic key or a one time pad. It is mathematically impossible to find out what the secret key/OTP is on these devices from readouts on the display. You have to steal the device and read the bits using an electron microscope. Even if you could do that, it would be very difficult to create a cloned copy of the device and return it to the owner's possession in any length of time.
Thus, the inherent security is obvious : in order to break into an account protected by a keyfob, one absolutely HAS to steal the actual keyfob. That vastly limits the vulnerability : if the user still possesses the card, they KNOW they haven't been hacked to 99.9999999% certainty. Furthermore, only individuals who come in direct contact with the user have a chance to steal the card, and they cannot do so secretly - you could freely give your credit card to a waiter at a restraunt and have him use the keyfob with the secret code displayed, and know that the card could not have been skimmed.
And, of course, the moment the user of the card notices that it is missing, he can call the bank and cancel it and ask for a replacement, eliminating any further losses. If your account information had been compromised, you might not realize for month(s).
I will agree with you on "something you are" authentication. Even if you owned some kind of biometric reader and used it to log on to your bank, it is not any more secure than a password because a fingerprint or DNA sequence is a static piece of authentication. Well, ALMOST....
Theoretically, using technology not yet available, you could give the bank a sample of your genetic material and essentially have security whereby the bank asks your home DNA scanner "give me n->Z portion of the user's genome". This would only be a practical security measure if whole genome sequencing were still very expensive.
Parent
No it isn't (Score:4, Insightful)
So in the case of a properly designed security token, it ISN'T just data on the Internet. The reason is that it isn't as though the "something you have" is a card with a number on it or the like. If that were the case then yes, discover the data and you are good. However they don't work like that. There are two related systems that I've seen:
1) A card that gives you a number. What happens is when you want to log in, you push a button on the card/device and it hands you a number. However the number isn't fixed, it changes with time. You need the right number for the right time. The way it works is a crypto system. It uses the time and a key in the device to provide the output. The other end then can calculate the correct number needed. The only want to get the number is to have the device, or find out what the key is on the particular device.
2) A challenge/response system. Here you plug in a USB key or smart chip. The device you are connecting to then sends a challenge to your device, usually something in the form of "Sign/encrypt this message." Then again, public key crypto comes in to play. Your device encrypts the challenge or signs it or whatever and sends it back. The server checks that result against what it ought to get. If the answer is right, in you go.
In either case, the only way to get the data is to either find out the key, or to get your hands on the device. A simple intercept won't do it.
As for your "gun to the head" thing, well of course that gets around it. There is NO SUCH THING as perfect, unbreakable security. I think some geeks delude themselves in to thinking there is because you can build a computer that is at least seemingly perfectly secure. However in the real world there is no such thing as perfect security. There is only security that is better than what anyone is going to try.
I mean I can secure against your gun to my head thing: I hire armed, trained, guards. You try to come at me with a gun, they take you out. So you can counter that, you get trained snipers to kill them at long range. So I counter by traveling only in secure armored vehicles, so you counter by kidnapping my family, so I counter by securing the too, and so on. However at some point, I got past what you could reasonably do, and more importantly what you'd reasonably do. In fact, with good two factor authentication, I am already past it. You will not come and put a gun to my head to get at my bank account. The money isn't worth the risk. So I don't need to worry about that kind of attack. My security is good enough.
That's all it is ever about. That's even what it is in the case of extreme security. The government does not delude itself in to thinking that having tons of armed guys around, say, the CIA headquarters makes it impervious to attack. There are always ways to attack it. So why bother? Because it makes it impervious to any attack that anyone might actually be able to try to pull off. Yes, in theory you could find a way to kill all the guards, take the right people hostage, etc, etc. In reality, you couldn't even come close, you know this, and thus you won't even try.
It is secure against REAL threats, and that is what matters. Same deal applies to your bank account, however since you are protecting a small amount of money and not national secrets, two factor authentication and some vigilance on your part will suffice, armed guards are not necessary.
Parent
Re:What about the banks? (Score:5, Informative)
That's not two factor, it's one factor. It's something you know, in two parts. A key fob introduces something you have.
A big problem with what you described is that 40 images to choose from is like adding one more character to your password, allowing lowercase, numbers, and 4 other punctuation marks only.
It doesn't add much to security at all, in other words.
Parent
Re:What about the banks? (Score:5, Insightful)
A little two factor authentication would be nice to see in American banks. Passwords just aren't adequate any more.
And how would an n-factor authentication scheme help when software on your computer is logging keystrokes, mouse gestures, and capturing images of your screen and then sending them near realtime to the bad guys?
If your computer has been compromised in this fashion, you've already lost. For you car enthusiasts, it's like adding additional locks to the car doors -- it doesn't help if the windows (haha) are already broken.
Parent
Re: (Score:3, Funny)
If your computer has been compromised in this fashion, you've already lost. For you car enthusiasts, it's like adding additional locks to the car doors -- it doesn't help if the windows (haha) are already broken.
What's the computer equivalent of the "This car protected by Smith & Wesson" bumper sticker?
Re:What about the banks? (Score:4, Funny)
What's the computer equivalent of the "This car protected by Smith & Wesson" bumper sticker?
This computer is protected by retaliatory DoS attacks? I guess that is the best we can hope for until we work out a better implementation of PoIP (Punched over Internet Protocol).
Parent
Re:What about the banks? (Score:5, Interesting)
For you car enthusiasts, it's like taking the engine with you when you leave the car. Even if the car is hot-wired, it's not going anywhere without that thing you still have.
Parent
Re:What about the banks? (Score:5, Insightful)
Though I agree two factor authentication is useful, the 'taking the engine' analogy overestimates the difficulty of breaking through it.
All the scammers have to do is instead of recording your keystrokes, gesturing, etc., they display a 'fake' copy of the bank to you through whatever software they have installed on your computer. They take the information you think you are sending to your bank (but are sending to them instead) and instantly have their scripts login to the site from their own systems (or some other bot on the net).
If they prevent your initial login to the site from happening, they can use your username + password + rolling code themselves if their software auto logs in.
This of course requires a user to go to a phishing site (miscellaneous.scammersite.com or something more complex), or requires the phisher to own the user's computer enough that they can intercept their connections & deal with the SSL certificate issues) while the phisher's automated software automatically goes to the real miscellaneousbank.com site.
Parent
Re:What about the banks? (Score:5, Insightful)
And do you realise this authentication scheme has also been broken?
The crooks these days are breaking into your account in real-time by using your security token code as you login, and preventing you from logging in.
Read the article, he mentions this.
Parent
Re:What about the banks? (Score:5, Informative)
The Commonwealth bank in Australia (and probably many others) sends you a random code via SMS to your phone that you have to type back in to the site in order to transfer money to an account you've never transfered to before.
Parent
Re:What about the banks? (Score:5, Interesting)
And how would an n-factor authentication scheme help when software on your computer is logging keystrokes, mouse gestures, and capturing images of your screen and then sending them near realtime to the bad guys?
The way it works here with some banks in Australia is they send you a code via SMS when you try to issue a transfer from Internet banking. You need to enter the code into the website to continue the transaction. So the extra factor here of having the phone offers a pretty useful extra layer.
My bank doesn't offer it; I wish it did.
Parent
Re:What about the banks? (Score:5, Insightful)
Because a 2 factor authentication token like an RSA key changes every 10 or so seconds so by the time Bad Guy #1 has finished parsing that log the 2nd authentication factor is out of date. The far cheaper way of doing this which most banks in Australia have started using is a one time password sent to you via SMS. This password works one time only (hence we call it a one time password, geddit) so if the Bad Guys(TM) get the entire password in real time and are reading their logs in real time then they still cant use it as the password has already been used.
Yes it's a band aid solution but at least it's a decent kind of band aid. The alternative is complaining that it doesn't work and then having nothing happen because no one has a better practicable idea.
Parent
Re:What about the banks? (Score:5, Interesting)
This can be automated easily enough.
Also, it's trivial to redirect the POST to login.cgi or add an entry to /etc/hosts for bank.com to a different site that just presents a 'failed to login' instead of logging in. Meanwhile your password, security code etc has been sent off to the bad guys machine which does an automated "transfer *.* funds to x" script using these credentials.
It's been done.
Parent
Re:What about the banks? (Score:5, Insightful)
None of this will work with the problems described in the article, if someone has control of your computer then you're screwed no matter what kind of authentication you have. In one of the examples they specifically stated that crackers used the token code and delayed the customer's request:
So, instead of the cracker getting blocked the customer would have been blocked because the "malware" made the customer's request come in AFTER the cracker's. If you were really clever you'd program the thing to intercept all the communication before it gets encrypted to go out to the bank and then fake the returned data so the user doesn't know that you're toying with them (yes, you can intercept the crypto library calls - I toyed with this some to get the Red Alert 3 Beta working on Wine). I don't know about you, but I can't think of a solid way around this interception (except having the bank only allow logins from a special custom browser that they load on a Live CD).
Parent
Re:What about the banks? (Score:5, Interesting)
Per TFA, the banks in the two cases mentioned in the summary used two factor authentication. The hackers' malware delayed their access, and the hackers used a VPN tunnel to access the bank through the compromised computer.
Parent
Its not just Linux, its trusted boot... (Score:4, Interesting)
Its not just "linux vs Windows" but "trusted boot": All you need to rely on is that the live CD is OK and your BIOS is not corrupted and you can effectively safely connect to your bank.
I use it myself for my Schwab account, with the added bonus of there is enough math to show active traders lose big, so don't trade active, which goes into play here.
Alternate Headline (Score:5, Insightful)
"Washington Post Urges Thieves To Distribute Linux LiveCDs"
A few racks full of CDs in a highly visible place, or even cheap preloaded USB drives delivered right to the mark's front door along with a friendly letter explaining how running Linux would help improve security and thwart The Bad Guys could make your job of stealing from the clueless even easier than before.
Re: (Score:3, Insightful)
The only real solution is to make banks liable for online bank fraud, just like credit cards are liable for credit fraud. The c
To be safe... (Score:4, Informative)
Well, don't do online banking.
Or, use a totally separate computer to do online banking. Only use the web browser to access one's bank account.
Or look for those "freeze" type software, which makes the harddrive essentially read only.
Also, it doesn't hurt to check which processes you are running, and whether any of those are unusual.
The browser may be out of date (Score:3, Insightful)
Devil's advocate: Deepfreeze? (Score:5, Insightful)
Devil's advocate here:
Of course, a diskless system running Linux would reduce the chance of malware on clients, but perhaps if a company is dependent on Windows, almost as good security (and I state almost) would be obtained from denying admin access and using something like DeepFreeze, Windows SteadyState, or similar?
Combine DeepFreeze with AppLocker, some decent enterprise antivirus utilities, BitLocker, and the usual physical and BIOS protection on a machine, and one can make a decently locked down terminal that can cleanly run Windows apps. Should additional software be needed, no need to install it, just use something like VMWare ThinApp and have it runnable from a central location.
There is nothing wrong with a diskless system and booting from a CD-ROM. However, unless one creates a custom image with reliable enterprise level auditing tools, it becomes difficult to extract data from a group of PCs (and this is important for larger businesses come tax season, or regulatory compliance), and it is definitely an issue to add or update software without a reboot, unless it is a precompiled binary on a central server that people run.
Also, instead of running live CDs, why not consider going to a vendor like Wyse and going with truly thin technology? This way, there is little to no fiddling with the client side. If a thin terminal has a problem, just swap it out for another one, chuck the old one in the RMA box and be done with it. This is arguably a lot easier than the cost for maintaining standard PCs [1].
[1]: I'm primarily intending enterprise level here. For some SMBs, it is a lot cheaper to go with a boot CD and a generic PC, but for larger companies, it may mean more futzing around with stuff for their IT staff, especially on the scale of thousands of endpoints. If I had a startup with a call center of 5 people, PCs are a lot more economical. However, 500 to 1000 people in a non-technical call center, then I'd take a serious look at thin terminals and a beefy internal network fabric.
it's not a matter of Linux vs. Windows... (Score:3, Insightful)
Also, honestly, how many people do you think check the MD5 sum on an ISO? Hell, I've never had a RedHat/Fedora disc that passed its self-check. I gave up on that ages ago.
A smart bank would be ALL over this... (Score:5, Interesting)
A bank with any technical savvy would be immediately preparing a LiveCD/USB distro that boots as quickly as possible into a browser pre-configured with the bank's portal page set as the home page. The distro would contain nothing extraneous -- just enough for fast, safe banking. It would, of course, be thoroughly branded, but completely legit vis a vis source code and license notices. Give them away in the mail, or even sell USB drives.
Re:A smart bank would be ALL over this... (Score:4, Insightful)
Sorry to break it to you, but doing this would be marketing-suicide for any bank that does this.
All of its competitors, and 99.9% of its non-tech-savy client base (so 99.5% of its clients including the tech-savy ones) would interpreat it as:
"This bank is SO insecure that they push me to use some kind of complicated pc configuration everytime before I go to their website. What a pain in the ass. Why can't they pay for their security problems themselves? I'm switching to another bank."
A good bank should educate their clients about being responsible online, not make their online banking even more inconvenient.
A great bank should protect their client bank accounts even if their PCs and their accounts have been compromised.
An horrible bank is one that expects its users to go through a long and complicated process for their "safety", disreguarding the negative user experience in the process, like you're suggesting.
I realize you're suggesting it as an option, not a forced policy, but the mere existence of the option will make average joe panic about its security and take for granted it's almost mandatory or he's fucked.
Parent
Re:VM? (Score:4, Informative)
Parent
Re:VM? (Score:5, Insightful)
What about a Windows XP Live CD?
"Sir, there are some gentlemen here who say they are from an organization called the BSA. They want to see the license certificates for those Windows CDs we've been handing out..."
Parent
Re:VM? (Score:5, Insightful)
Because as the author explains in the comments, key loggers can run at the low level device driver level. At this level, it can hook key presses in a VM just as well as the host OS.
It's a pain, because nobody wants to go to the trouble of rebooting twice for the sake of paying a few bills. But it's the only way to be sure of a clean environment, unless your BIOS has been hacked. It's at least one good argument for the trusted platform, TPM, or whatever it is. In theory you could be sure that you are running only un-altered digitally signed executables and nothing else.
Parent
Re:VM? (Score:5, Insightful)
That doesn't solve the "but joe user doesn't want to reboot just to get to his overdrawn checking account" problem; but with real computers routinely showing up for $300 and lower, it isn't exactly an extremist position to suggest banking from dedicated hardware for any nontrivial amount of money.
Parent
Re:Just Linux? (Score:5, Funny)
We're trying to SAVE money here
Parent
Re:Just Linux? (Score:5, Insightful)
I think the point is Boot CD, not Linux.
This would preclude any with an intelligent GUI (actually I am quite fond of Gnome at this point, but that wasn't what you meant).
If I am correct, using a Linux boot CD would make sense for Linux users too.
Parent
Re:terrible advice (Score:5, Interesting)
If you are using the LiveCD as a dedicated banking only environment, the only input your browser will see is your bank's website. If you can't trust user behavior, and want to really be sure, you could have it set to reject anything that doesn't have the bank's SSL cert. If your bank wants to 0wn you, you are already doomed. If no other site can reach your browser, your browser cannot be owned, no matter how buggy.
Parent
Re:terrible advice (Score:4, Interesting)
sigh. Just off the top of my head I can think of about a dozen attacks one could direct against a bank user who thinks they're bulletproof because they're using a Linux LiveCD. For example, booting off a LiveCD won't save you from the truncated SSL cert attack that was demonstrated in the direction of PayPal the other day.. only having an up-to-date browser will do that. Encouraging people to use unpatched known-vulnerable software to do their banking just so they can avoid malware on their regularly patched machines makes no sense at all. Of course, that's the extreme case.. suggesting people use a LiveCD of Linux instead of an unpatched copy of Windows XP SP1 is a different kettle of fish.
Parent
Re:terrible advice (Score:4, Informative)
Yes, because everyone else has patched the bug.. Microsoft hasn't. But if you're using a LiveCD from before they patched the bug, then you are no more protected than the bozos using IE5.
Parent
Re: (Score:3, Interesting)
In the broader term, it might be worth looking into further cryptographic mechanisms. For instance, with debian packages, you can safely download from an untrusted mirror or an http mirror that might be s
Re: (Score:3, Insightful)
Ya, it stops key loggers, and that's great
Yeah, it is great, because a huge part of on-line fraud is from keyloggers. Modern ones even record 'screencast' movies of you using your computer.
but it aint going to do much for your browser security unless you keep your LiveCD up to date
Between booting up and getting a DNS record for your bank how are they going to exploit a browser security problem? You could safely use unpatched IE5 to do online-banking. There might be some null-prefix type problems, but in reality going directly to your bank's site is pretty hard to get in between.
who says your CD burning software isn't infected - implications on trusting trust and all.
There are lots of different CD burning software, lots of di
Re:terrible advice (Score:5, Insightful)
Browser security is only an issue if you're visiting other sites, in the same session, on the same boot, on your LiveCD. Browsers on LiveCDs don't magically download malware from the internet by themselves - you have to direct them to. And most conventional malware must install itself - which won't happen on a LiveCD. There are a very few flash/js based attacks that work live in the same session - but really, if your either (a) your bank has third-party inline flash ads or (b) you don't trust java content from your bank's own website, then why are you banking with them online?
And going as far as questioning whether your CD burning software is infected is ridiculous. You can't be any more certain that your mouse doesn't have imbedded circuitry tracing your movement pattens, or your keyboard doesn't have a keylogger built directly into it, or the aliens aren't tapping directly into your cablings electromagnetic intereference patterns to directly access your bank account as you do. You're going to extremes purely for the point of argument, but although it may have passed you by, it was established several thousands years ago that "nothing is certain".
If you can imagine up scenarios like malware built into your cd-burning software specifically to target LiveCDs being used for online banking, I can't fathom how you trust a banks own employees enough to actually keep your money with them instead of under the mattress.
Parent
Re:terrible advice (Score:5, Funny)
hey, who says your CD burning software isn't infected - implications on trusting trust and all.
I understand there's only a fine line between safety and paranoia, but the idea of a CD burning software having been compromised to detect Linux LiveCD ISOs and add a software keylogger to the system included therein is so far up in 'paranoia' territory it already got full citizenship and is considering running for president against "Elvis is hidden in Area 51" and "9/11 was planned by Israel to draw the US into the middle east".
Parent
Re: (Score:3, Insightful)
How does those malware affect live Linuxes?
Re:Non-random bits on LiveCD can compromise securi (Score:5, Insightful)
Not Linux. Randomness comes from the time (hardware, persistent), but also from the randomness of network traffic and other driver miscellanea such as HDD head seek times, mouse movements, keystrokes, CPU temperature data, electrical noise on the power supply (with the right hardware)...
I can't say for sure, but I think Linux actually has the most secure random-number generator of any OS - excluding dedicated hardware. Enough that it can probably be fairly called true RNG instead for PRNG, as long as you use /dev/random instead of urandom.
Parent
Re:Non-random bits on LiveCD can compromise securi (Score:4, Interesting)
My battery is dead, you ignorant clod!
Actually, something like that happened at the Montreal Casino. The machines were shut down every day, so they would end up generating the same sequence of numbers. A guy named Daniel Corriveau noticed, played the numbers, won $600,000.
He initially claimed that he used chaos theory, and the casino claimed it was a bad random number generator. The reality was that the cmos batteries had been removed during development to make testing easier, and nobody put them back in, so every day, they started with the same seed. Simple incompetence. They paid the money after 2 weeks.
Parent