Slashdot Mirror
Phishers Defeat Citibank's 2-Factor Authentication
An anonymous reader writes "Crypto experts and U.S. Government regulations (FFIEC) have been pushing the need for financial Web sites to move beyond mere passwords and implement so-called "two-factor authentication" — the second factor being something the user has in their physical possession like a token — as the answer to protecting customers from phishing attacks that use phony e-mails and bogus Web sites to trick users into forking over their personal and financial data. According to a Washington Post Blog, 'SecurityFix,' phishers have now started phishing for the two-factor token ID from the user as well. The most interesting part is that these tokens only give you one minute to log in to the bank until that key will expire. The phishers employ a man-in-the-middle attack against the victim and Citibank to log in via php and conduct money transfers immediately when logged in." (An update to the blog entry notes that the phishing site mentioned has since been shut down.)
(Posting anonymously because *I* did that in 2003).
My bank has had this for ages. How's about protecting you from the man in the middle attack by a little extra procedure, though ? Immediately after you've done the transactions through the web and you log out, the bank sends you an encrypted email with all your transactions in it. Those emails can be parseable for your own financial package as well. And it should give you some time to cancel all the transactions that are bogus. There can be no forgery involved, since the bank _always_ sends those mails. Just an idea, I know there's no cure for utter stupidity.
Religion is what happens when nature strikes and groupthink goes wrong.
My bank (Rabobank, netherlands) uses a key-generating hardware device, based on account, PIN number, optional numbers generated by the site (which are to be entered into the keygen) and an internal clock. With sending any transfer, the site requires a new key to be generated. If the amount to be transferred is sufficiently large, one of the numbers used to generated the key is the exact amount, thus requiring the user to validate the amount as well.
Phishers may be able to coordinate up to the point of this validation, but if one suddenly had to enter an additional verification number of, e.g. "2000.00" (minus the decimal point), it'd be very hard to use phishing for large amounts of money.
Then again, I also have other accounts at two other banks, both of which require only a one-time, 5/6-digit, non-changing, numeric password.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
This isn't at all a shocker. The authentication problem is only one piece of a very complex puzzle. But in this case simple and common SSL certificate verification would work to stop such a man-in-the-middle attack.
... So when you enter your token into the browser, first the browser checks the web-site is the "owner" of that token and if it is not then it warns the user, after verification the browser then sends the token and the user is verified to the site.
Further down the road though, this is why technology leaders need to standardise authentication tokens to include some kind of two way verification
Something like this:
mybankcom - 9 -
The browser implements a "token box," when a post is attempted with said box the domain gets stripped of all special characters (up to the path) and then compared to the first part of the token. If they are case insensitively identical then the browser will submit the rest of the token (the pseudo random number) to the web-site.
The token box would have to look unique and be very difficult to clone... Which might require it to jump out from the main content window, but that is a problem for browser UI developers and beyond the scope of the problem.
The target authorities and security developers should be aiming for, in my opinion, is not the people who do the wrong-doing, but the users themselves. The major difference that phishing has from hacking or physical robbery is that the attack is forceful against either the bank's online front or the customer whereas phishing preys on not physical or technological weakness but on intellectual weakness: ignorant users are conned into giving up personal details, going to a particular site or running a program because they are unaware of the risks. In phishing cases there really should be a bigger push for educating customers through more than just 20-pixel-high signatures on electronic correspondance. There should be in-bank brochures, tv spots/advertisements (or at least addendums to current tv spots) and users should clearly know never to click a link in an email from anyone, especially if it's pertaining to a bank or paypal-like site or in a personal mail from someone unfamiliar. There's a reason many geeks have clean-as-whistle computers (I virus and spyware scan every now-and-then -- about every 6 months -- and they both always come up clean) whereas the "common user" has problems with viruses and scumware seemingly constantly, and that reason is education and not-so-common sense. The answer then is obviously to educate, and make that sense common.
A man in the middle attack will breach just about any security you have. Unless you can recognize it, or teach others to, this sort of attack will always work. The trick is that it is sophisticated and you have to educate people to know when they are connecting to the correct site or not; that is, check the URL and the SSL certificate when connected. And, never use self-signed SSL certificates.
Quality Hosting e3 Servers
could the banks not create a usb card reader which you could put your debit/credit card into as part of the authentication, or even better an "authentication" card, it could have say 5 billion numbers on it and the system could ask for 5 digits randomly out of all of them, if the box was set to never send more than 5 digits then even if you fell for a phishing attack or got hacked those numbers would almost never be asked for again. This seems like such a good idea... I feel I must be missing something.
*''I can't believe it's not a hyperlink.''
Reduce, reuse, cycle
The phishers can also mimic the error path if the token is disallowed or mis-typed.
This is not an easy problem to solve!
[% slash_sig_val.text %]
People might just be able to determine if they were valid or phishing attempts.
Almost all email clients support s/mime these days, all you and the banks have to do is sign up to a certificate authority and install a certificate. They can be acquired for free.
Deleted
How about the other side of authetication - anonymity. There are cases when the service provider doesn't need to know personal or professional details about the customers, but nevertheless this kind of data is collected widely. The Shibboleth technology developed in the Internet 2 project in principle makes it possible for a customer to limit the access to personal data by service providers. This kind of solutions should be made widely available. Now there are all too many authentication systems collecting data which may be used (at some point) for nefarious purposes.
Website Controls
Additional "next PIN" for each transaction
Challenge response
Enter a PIN challenge based on dollar amounts to transfer
The usual web security stuff - see OWASP for more
Signing transactions with certificates and tokens
Security Awareness
Workstation security is paramount, firewalls, anti-spam, anti-malware, running as non-admin all assist in this process
Some trojans imbedded into IE and pop-up boxes that sift the credentials upon the user typing in their banking website
As you can there is so much you can do.
Have fun!
Nearly all US and UK Internet banking systems are susceptible to this.
There is an easy fix for this as well - client side certificates. I have an account with a bank in an ex-eastern European country and they use it. Many scandinavian banks use that as well (with the certificate on a token or a smartcard).
In order to authenticate the SSL handshake has to use both client side and server side certificates. After that the actual user id has to match the certificate one. A man in the middle cannot break through that because it will not have the private key from the user machine. From there on even if it can fake the bank interface to the user it cannot fake the user towards the bank. Game, set and match.
The only reason for US and UK banks not to use it is outright incompetence. I remember trying to explain the concept of client side SSL certificates to one of the cretins who have implemented a well known UK bank Internet banking security subsystem. He could not grasp the concept. By the way - he now works in the "risk" (that is the way they like calling this now) department of another well known UK bank.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Let's see
1) the website is simply at another address, well-educated users will spot the lack of https and the different URL
2) I have an account at postbank(.nl) which uses a password for logging in, and then additional codes for transactions. The password will only give you read only access.
3) At this same bank, the transactions are verified by sending you a text-message; not the most secured channel, but the message doesn't just include a "transaction acceptance code", but also the amount of money being transferred. If something is amiss it's spotted easily through this second channel, beyong the phishers' control.
4) Another bank, abnamro.nl, lists the IP number you were last logged in from on the welcome page.
I feel that 1) could be attacked by phishers using malware, so that's no guarantee.
Using the amount of money to be transferred as part of the challenge is trivial and should simply be implemented at first opportunity. One of citibank's problems is that they're using a token that simply displays a code, rather than a challenge response system; no way to enhance the challenge..
Number 3) is also pretty neat. Reall, I don't care so much about my bankstatements per se that they need to be protected with two-factor authentication (though of course in the US, identity theft might make this more prudent). The ability to check my account without too much rigmarole is very user friendly.
Number 4) would be neat, but also confusing to many users, especially those behind DHCP.
Sum conclusion;
use challenge response, with the amount to be transferred firmly embedded in the challenge, or communicated to the user out-of-bounds.
SCO employee? Check out the bounty
Customer number + pin, then new code for every transaction. Been using it for years. Can't even login to the Sampo web-bank without these 3 things. They may grab my account number and pincode as much as they want cause, they're doing shit with those codes without my every-time-changing code. Welcome to Finland.
-m10
Just what is the whole big deal with online banking anyway? I've never seen the attraction.
There are exactly two reasons, and two reasons alone, why I ever visit a bank. One, the rare one, is to pay in some money or a cheque through the hole-in-the-wall machine. The other one, the common one, is to draw out money through the hole-in-the-wall machine. The HITW can also tell my balance; but I generally know how much is in there, give or take a ton. Between transactions, I hardly care how much is in the bank as long as it's more than nothing. I know how much my wages are, I know how much my regular outgoings are and I know how much extra I've been putting in or taking out.
Unless and until they come out with some software that allows me to scan pound notes with my own scanner and have my bank account credited, and print out pound notes from my own printer and have my account debited, I will have reason to visit the bank. And if said software is not Open Source, then I will still continue to visit the bank.
Je fume. Tu fumes. Nous fûmes!
This would be a good time...and application for live Linux CD's or (insert OS here). The OS itself would run live from a CD-ROM, and include a set of auth controls between itself and the bank all on its own, well before the browser or web certs are needed.
Citibank just recently starting offering Digipass tokens to its business customers and I believe may have extended the program to all of its online banking customers to meet 2006 compliance. 2 factor authentication seems to be more prevalent in Europe as US banks have been slow to add this measure of security, which is why the FFIEC issued a mandatory compliance. Now with a deadline looming, US banks, especially those using tokens as their 2 factor method like E*Trade and Citibank, may be sent back to the drawing board. Although no method is foolproof, bad publicity alone may make these banks add further measures to ensure online security.
Of course psichers can use real men in the middle to read the captcha's, but that would make their job lot's more difficult.
Why is online banking allowing you to create new billing accounts online? Why can you make a transfer to a new, unlisted, account online? Answer: Banks want to save money.
Most people almost never create new billing and transfer "destinations". We could afford to go in person once or twice a year to do this. The very few who need these options are usually kwolegeable about security issues. Even if they are not, the fact that there is so few of them is a protection in itself. Remove these options from online banking and even a "phished" account will be of limited use to the phisher since the only thing he can do with it is pay your bills.
This solution was actually implemented in the beginning of online baking. The idea of pushing "new" features with no regards to their actual impact is almost like a disease in the current corporate world.
Actually quite a few people use this for personal transfers in the UK. For example if I go for a weekend trip with some old college friends who now live in different parts of the country, I may book all the flights or hotel rooms. Setting up a transfer direct to their personal accounts is quite useful and quick, compared to cash or cheques. My online banking used to take a couple of days to set up these arrangements, and now its immediate. I think this is rather dangerous.
I suspect that we're only going to see some serious efforts to fix/curb this problem once the banks become 100% liable for monetary losses due to fraud. For the moment, their attempts to "fix" things are more of a PR exercise (for consumer's benefit and regulator's benefit) than an actual solution to the problem.
At some point, the naughty people have to pick up the money. There needs to be more international coordination for prevention of bank fraud so that these criminals can't hang out in countries with corrupt banking/regulatory/political systems and siphon accounts of citizens from around the world.
Companies can easily increase the diffculty of a successful man-in-the-middle attack with a single One Time Password, by simply asking for 2. Some places already do this. Basically, you are requried to use a single generated one time password to login into the site, and then when you are ready to complete a transaction, it requires you to enter a second complete different one time password generated from the same device. This is the total fix, but it is an easy way to make this type of attack much harder, asking for a single password, ok human error, asking for 2...that should raise some flags.
You can change your mobile phone easily enough, just change it in the settings but that also requires a sms message with a code. So as long as you got your phone you are safe.
If you lose your phone you will have to disable your account and you will be send by mail a new set of login details.
It seems fairly secure, it would be hard to imagine how to phis it. The only thing that could possibly be done is that they try to get you to change your mobile phone number to one they control.
But this attack and that suphisticated. It still requires people not to check the bloody url. First rule of online banking. ALWAYS handtype the url. Second rule of online banking, see the first rule.
For the postbank that is mijn.postbank.nl not that hard to type and unless someone hacked the mainsite likely to be secure (provided your browser/os/isp ain't been hacked.
Fuck this, I am going to keep my fortune in an old sock.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Bollocks.
- certificates/s /free-email-certificate.html
The problem with email at the moment is that forging From: fields is trivial, anyone who knows the first thing about SMTP can do it in 5 seconds and this means that an email can appear to come from any source the actual sender wants. I can send an email to anyone and make it appear as if it's from any bank in the world.
With a signed email, if the sender(bank) email address in the From: field doesn't match the certificate then you know it's not from the real sender(bank). It's perfectly possible and indeed simple for the client to automatically check that a signed email is from who it says it's from. That's the whole point of digital signatures. It could then display a nice happy face for valid emails and an unhappy one for invalid or neutral for unsigned ones.
And certificates should be easy to obtain. Everyone should have one. Go get one now, they're free! It isn't whether you have a certificate or not that matters it's that you are who you say you are that matters and that's what certificate authorities do for you. It's then up to users check that the From address shows user@barclays.co.uk rather than user@barlcays.co.uk but at least they'll now be able to check.
You can get free certificates which can be installed in your s/mime compliant email client.
http://www.thawte.com/secure-email/personal-email
http://www.cacert.org/
http://www.instantssl.com/ssl-certificate-product
More info here.
http://en.wikipedia.org/wiki/S/MIME
Deleted
My bank uses a two-factor authentication system, the second factor being a card with a 10x10 matrix of double-digit numbers. When you login, the website asks you for your username, PIN and the number which appears in certain coordinates in the matrix card.
It used to ask you for it in the login page itself. Nowadays you need to have a mobile phone number associated with your account; when you try to login, the coordinates are sent to you by SMS. In that way, even if a phisher gets your username, PIN and full matrix, they cannot login because they don't know what coordinate is asked to you (and you receive the unsolicited SMS, so you can alert the bank). They would have to steal your cellphone too.
Ah, and you have to enter those numbers using an on-screen keypad which moves around randomly anter you click on each number, so keyloggers are now useless too.
What is needed is for one of the tokens to be "active" in the negotiation. Anything that can perform a unique challenge-response will fix the MITM attack.
As others have stated, client side ssl certificates, hardware tokens with key-pads, smart cards, trusted-computing would suffice.
I know this won't fix all problems with phishing emails, but it should fix one factor of it. Could those who contribute their programming skills to Firefox make it so the actual domain of the site you are at is highlighted? This means that if you are at a site
http://citibusinessonline.da.us.citibank.com.tufel -club.ru/sahdlhasal
Firefox would display it as:
http://citibusinessonline.da.us.citibank.com. tufel-club.ru /sahdlhasal
I know some victims refuse to think about it at all and refuse to even look at the URL but this would give them one more tool to use to possibly see it is a scam.
But why is the rum gone?
I think many users would want a system that would work from most any computer. For example, home, work, parents' house, etc. Couldn't the bank check the path of the packets it receives for suspect routing paths or maybe even unusual delays? It also could require you to confirm by email any unusual request.
I have a fantastic idea for a phising attack. Use an IE hole to overwrite a target computers hosts file. Then when they visit their bank, IE will go to your phishing site instead and the user wont even know they are not at their bank. Your computer is of course performing a man in the middle attack. To top it off the original IE hole that was used to overwrite the hosts file could also be used to install the fake security certificates on the victims computer. No phony emails ... just sit back and wait for them to log into their internet banking!
-c
"If you are an idealist it doesn't matter what you do or what goes on around you, because it isn't real anyway."-R.P.W.
but I already have a physical token from my bank. We call it a debit card. Mine was recently compromised and had a $600 charge on it. As long as there is money, there will be thieves. People are stupid/lazy/complacent and thieves will always overcome those minor hurdles.
Check out my lame java blog at www.javachopshop.com
...and I'll keep on saying it.
If email encryption and certificates were a *STANDARD* feature by the major email clients (desktop and web based), then institutions could set a blanket policy that any email communication from them to their clients/customers must be encrypted and/or contain a digital certificate. Even better, these certificates could contain usage policies so that email clients could automatically filter/delete messages w/o the proper certificate or that don't follow stated policies.
The trick is that the user needs to be abstracted away from the encryption/signing process so that they understand the basics of what encryption/certificates are but can use them with with just a click or two.
A good example of taking security technologies and providing them to the user in a well abstracted form is TLS under HTTPS. IMHO, phishing would be drastically reduced if email encryption/certificates, along with usage policies, were as common and supported as TLS under HTTPS is today.
[Pre-rebuttle]I am not saying that this will solve ALL phishing scams. I'm just saying that there are technologies out there that, if commonly supported and intergreted into email clients/services, would greatly increase the difficulty of pulling off a phising scam.[/Pre-rebuttle]
Faith is a willingness to accept something w/o complete proof and to act on it. Reason allows you to correct that faith.
The thing about Phishing scams and such is that, for me atleast, you can't transfer money out of my bank account via the internet. You can go from one account to another that's in my name and attached to the others, but you have to actually go to the bank or write a check,both of which they can't do, to take large amounts out.
... The bank's customers should pass a spelling and grammar test before their account is opened. Then they wouldn't get spoofed by people using words like "unsuccessfull" and "att empt" and "Ip address". :-P
My bank requires you to install some java software + some keys in your C:\ or /home/ before you can use online banking (and it's protected by a password).
It's a bit complicated to set up (especially in Linux, although the instructions were good enough to figure it out), but I don't see how phishing would work with this system. An attacker would have to trick the user into sending the 3 files with keys + entering his password.
You could get what you need easily with a trojan and keylogger, ofcourse (well, good luck tricking me into installing a trojan on Ubuntu), but sending e-mails with 'please enter your password' won't do a lot for a phisher. Besides, I don't even think my bank has my e-mail address, and I would find it very suspicious if I ever received an e-mail from them.
Phishing works because some banks apparently set up their online banking systems in the same way as slashdot, with just an username and password. That's fine for unimportant stuff, but when handling money, a login/password just won't cut it.
How about if you get an email from your bank asking you to log in and supply personal information (or whatever the case may be) you just open up Firefox yourself and actually go to your banks official website?
I'd rather put the extra 5 seconds to securing my funds than just trust that my emails are from safe sources and lose it all.
But that seems too simple, doesn't it?
A primary reason for the difference between US security standards and European security standards is the compute environment, and hence, the assumption of trust given to the terminal.
In the US, most users are accessing their accounts from their work or home computers. Although keyloggers may be present on these machines, it isn't very common yet. In northern europe, the use of internet terminals in cafes or kiosks is much more common. On these machines, it is likely that keyloggers will be present, so it is conservative to assume that everything the user does will be logged someone.
This assumption (everything the user does is logged) drives the need to require access to some thing (PIN grid, token generator, etc) that is needed in addition to the normal username and password. The higher level of justified paranoia drives a higher perception of security requirements.
One tremendous downside to this: loss of one of the best features of online banking - ease of use and portability. I personally have about ten online accounts with different banks, and I use all those accounts frequently. Everything I need to know to manage my personaly finances is carried in my head, and I can access my accounts from any computer anywhere in the world with nothing more than the knowledge I possess. Having to carry any sort of physical object to access my accounts would be a tremendous loss, one that would probably drive me to seek another bank, or a bank in another country, to avoid.
is use pictures. You login to the site using a username which takes you to another page. They then present you with a picture you chose when you opened up the account, you can even upload a picture I believe. If you recgonize the picture you chose then you know you are on the correct site and can put in your password safely. If you go to a malicious site they are not going to be able to present the correct picture. There is no way a man in the middle attack can succeed unless the user just forgets to check for the picture and puts in their username/password anyway. It is the first thing I look for though, yep there is the picture I know I am on a Bank of America server.
- Jeremy
I resist writing paper checks as much as possible and I seem to create a new billing destination for online bill pay, probably one per month, sometimes more, sometimes less, but easily 12 per year. Some are changes -- our pediatrician changed billing systems and changed the billing account and address -- but some are new, almost single use payments for magazine subscriptions and other stuff.
Seems to me that the bank should detect multiple logins + bank transfers from the same ip address. They need some of that pattern detection software! Opps that might uncover illegal activities and we don't want that now !)
MK
I'm in the same boat, I have to specifically call the bank and request that other accounts be added, and even then I can only transfer money within their organization.
However, I'd love to have the ability to do transfers and intl wires from my account like some of my friends in europe can. The fact that many internet banking systems in the US are crippled isn't exactly security.
If you require client-side certificates, you can't bank from any machine you want, only from a particular machine. Because in order to prevent man-in-the-middle attacks, your client certificate has to have the IP address of your machine in it.
Actually, if your provider doesn't even assign static IPs, you can't really use client certificates at all.
For me, the major takeaway from this is that a fool and his money are soon parted, no matter how much technology you try to use to prevent it. Or, another way, nothing is fool-proof because fools are so ingenious.
http://lkml.org/lkml/2005/8/20/95
Why don't the banks use their own DNS servers to automatically check for new domains registered with "citibank" etc. in their name? That way you can detect many possible phishing schemes that try to look "authentic" even before they are necessarily active? It'd at the very least narrow the window of time for phishers to populate a DNS record, let it propagate, then release their attack...
I like how the Postbank does it here in the Netherlands. For every transaction (which may include multiple transfers) they SMS you a random number which you have to enter in the site to validate the transaction. They send the SMS to a phone which they previously determined belongs to you (you don't enter the number on the spot or something like that). A phisher might hack your Postbank account, but they won't be able to impersonate you since the security number (and the total amount of money involved in the transaction) is sent to your cell phone which they can't get at (and which alerts you to the fact that your account has been hacked).
In the past (actually it's still possible for people who don't have a cell phone or don't want to use this system) the number wasn't sent as an SMS, but was on a long list of numbers they would mail you (the list was printed and sealed by a machine, no humans would see it before you). This was a nuisance because I kept losing the list and it was a hassle to use, but this new system is quite convenient in my opinion. I always have my cell phone with me, so I can do my banking from any location.
You can change your email address, only IF you confirm the change sending an authentification code to the old email address, if this one is disabled nor longer valid, then you may need to visit your bank executive.
BofA has a version of this thats MUCH less savy. Their site respods with a picture and you confirm the picture is your "key" by entering your password. Just as hackable or perhaps even more so. Its not really a pain but it was really annoying when it was first rolled out.
I thought it was a good idea
I can't help but notice that all the authentication schemes being discussed are basically way that the bank verifies the customer is who they say they are. But the issue isn't that; it's that the customer is being tricked into thinking that they're talking to the bank when they are actually talking to someone else (who may be talking to the bank). There is nothing that I see that helps the customer verify that it's actually their bank on the other end.
The whole "phishing" thing is based on the fact that the bank's end can be spoofed, and customers have no reliable way to verify that they are really talking to their bank. A Man-in-the-Middle is simply a variant of this, in which the customer thinks they're talking to the bank, when they're actually talking to the MitM, who is talking to the bank.
Adding extra stuff to better authenticate the customer is not going to help here. Confusing the issue by just talking about "authentication" doesn't help either, since it conflates the two directions of authentication into one, and people don't notice that the customer may not have authenticated the bank.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
I thought I looked at the source code though and could not find a way to pull that picture but maybe I am wrong. Good point though, always open a new window and go to the sight yourself.
- Jeremy
But this won't work for the "masses" until prices come way down for SMS.
Microsoft still wants like US$1,219 for SMS 2003 with 10 Client Management Licenses!
Users of 1 minute token ID's can always just wait until there are 2 or 3 seconds left on their
current # before logging in.
TFA states that phishers have 1 minute. That's not really true, unless the user logs in as soon
as a new # appears. Giving phishers less time is just a matter of when you choose to log in.
Wait until your # is about to change.
------ The best brain training is now totally free : )
No security system in impregnable, its just a matter of staying one step ahead. Instead of looking at their software and saying "oo..this is really secure, I would love to see someone break this!" they should start working on the next security sytem once that system is cracked, the new one can be implemented. Otherwise you have a Titanic situation. "Look, are security, no one will ever be able to break it"
Klingon Software is not released, it escapes, inflicting terrible damage onto the enemy as it does
I've long been a proponent of forcing banks to do some sort of two factor auth, and it's good that some of them are finally doing it. I wrote an internal memo about this *exact* attack a few months ago, but I also mentioned that even if this attack were performed, the percentage of actual account compromises will still drop. This attack is more difficult to perform, and requires real-time interaction with the client, which isn't currently need for just simple password phishing.
:)
Regardless, there are some methods that can be employed now to thwart this particular attack. I just need some moola to get it off the ground.
Need Free Juniper/NetScreen Support? JuniperForum
How about just using challenge-response authentication? The user gets a fob with a keypad and small display screen. When they attempt to login to the bank's website, it displays some numbers that the user keys into their device. The user then reads the display on the device and enters the response into the bank's login form.
...that we need not only technical solutions, but solutions that target social engineering. Most 'hackers' are not technical wizards -- they simply know how to play a good game of poker and read people. The general population needs to be inculcated and trained on this concept: * Legitimate businesses will not email you asking for your username and password - they have trivial means to get your account information since they HOST it! This to me is common sense, but I guess most people find it rather an epiphany.
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman
Current popular browsers don't allow users to easily know that they are not connecting to the correct "citibank" site.
They just show that stupid padlock icon. And when I last checked, by default there are tons of CA certs installed by default in most browsers. And the users get the same padlock for all certs issued by those CAs.
Whereas if you had say an orange padlock = encrypted but untrusted/unknown site, and blue padlock = user's favourite encrypted financial transaction site then that helps a lot, and the browser also could easily do what ssh has been doing for years.
The browsers should also render the fingerprint of the site's keys in a coloured pattern next to the "padlock" or something. Could be each nybble of the fingerprint = a different colour out of 16 colours. After a while people would hopefully associate the colour pattern with the site. Requiring users to click on the stupid padlock in order to check the CA chains etc is ridiculous. Even savvy users will find that annoying.
It would be hard to save users who are oblivious to all that, but I claim that currently not enough has been done.
But from my experience web browser makers (like most people) aren't really interested in security at all. Because they could mitigate many browser security problems by allowing a special install mode where much of the browser code runs under a different UID/user, one that has very little permissions, while at the same time allow downloads to be saved to the user's directory etc. example: javascript/java/activex/plugin crap and renderers all run as _www_<username>, and the parts in charge of bookmarks and downloads run as <username>, and the parts in charge of "execute the url" are disabled by default. If anyone says that is too difficult, I'd like to point out that many browsers already have a "download manager".
Then it doesn't authenticate who you are. It's just another secret piece of info that you have.
And as such, there's no reason someone can't socially engineer it out of you. It's actually less secure than the secure IDs you speak of being a problem because the expiration period is much longer. If you weasel it out of them, not only is it good for more than a minute, but it is good until they figure out they have been duped. Whereas a secure ID sequence number is only good for 1 minute or until it is used, whichever comes first.
Only if the certificate has your IP address in it, and is useless to anyone who weasels it out of you does it provide any additional protection for users (in this case, from themselves).
http://lkml.org/lkml/2005/8/20/95
"Run this program, please."
You can write a program to get these keys out. Yes, it will have to prompt the user for the password, but it can be done. That's what social engineering is about.
Three factor authentication (the tokens you complain about) actually moves beyond just having some secret, but also to having a token. Client certificates doesn't do this. And your saying you must have a crypto module is a dodge, not an answer. You said client certs are the solution. Crypto modules are a three-factor system, you can't run to them as validation of your argument for client certs over three-factor.
Also, I'm not going to argue that modern DRM isn't certificate-based. It usually is. But the DRM makers know the certificates are a point of attack and so they don't just store the certs in the regular keybag on the system. They are hidden, under Windows, they actually scatter the access method into system calls all across the system, not just those that relate to security.
So saying that since DRM isn't cracked, system keybags must be safe too doesn't really follow.
In short, the system you speak of is subsceptible to the same social engineering as a simple password system. It's even largely subsceptible to keylogging, unlike three factor systems.
I'd love to protect people from their own mistakes. But it's very difficult to do so when users can be convinced to fork over what should be their most protected information.
http://lkml.org/lkml/2005/8/20/95
"ex-eastern European country". Hmmm...
Did the country move out of eastern Europe? to where, one wonders.
Or is it no longer a country? Haven't heard of any new communist regimes absorbing anyone lately.
Most people don't even think inside the box.
Anyone know who Citi uses for 2 factor as described in this article?