Sorry if this has been covered, search feature isn’t working.
My bank’s website has an apparently anti-phishing feature called a sitekey where when I set up the account they give me a picture, and ask me to describe the picture in words.
After that, after entering my account name/number in it’ll display the picture and how I described it and prompt me for a password (along with notices to not enter your password if that’s not the right sitekey, etc).
Presumably the intent behind this is so that you can tell it’s a genuine site and not a phish forgery because they know what image to display to me and the phishing site wouldn’t.
But it strikes me that this would be trivially easy to defeat - the phishing site merely uses the standard login screen where you enter your account name which has no user-specific information like the sitekey image. Then, behind the scenes, the phishing site tries to log into your account on the legitimate site, at which point the legit site displays the sitekey to the phishing site. Then, the phishing site merely has to display that sitekey to the user, and it looks identical to a genuine login screen - bypassing the apparent purpose of the feature.
The idea is that you’d get so used to seeing your personalized photo that you’d instantly know something was up if a site asked you for your login without that photo.
ETA: Nevermind, I see that you realized this and were asking a more sophisticated question.
But the procedure, as I understand it, requires you to enter some personally identifying information with no sitekey. They use that information to figure out who you are in order to display the personalized sitekey. So the first bit of information (in this case, account name) is required to be entered on the generic, non-sitekey-specific main page. So the normal procedure has you entering all the information it a phishing site acting by proxy would need without ever seeing a sitekey.
What you describe is called a ‘man in the middle’ attack. The first line of defense to prevent mitm attacks is to practice safe browsing. Only go to your bank’s site from a saved bookmark or my hand typing the URL. Never follow a link as these can be misleading.
The second line of defense is the SSL connection. The mitm won’t be able to present a valid certificate and your browser should flag this.
The sitekey software is doing a lot more than just presenting you with a picture. I can’t go into the details (I work for the company that makes it) but there are ways for it to detect when requests are coming from a mitm and not from a valid customer.
No security systems are uncrackable, but sitekey and things like it help the banks that use it to keep fraud down to managable levels.
Why can’t a phishing site get a cert? It won’t say they’re Bank of America, but then, you don’t see BoA’s cert when you connect to their site, either. (I used to work for VeriSign, but not the security part of the business, so I know only rudimentary information on SSL technology.)
I’ll take your word for it on detecting MITM requests, that is intriguing to me though. Had no idea that capability was there.
My bank uses the sitekey and if you try to logon using a different computer, you will have to go through a few extra steps to enable the new computer to login to your account. Because of this, the man-in-the-middle attack would not work.
The main flaw in sitekey or other anti-phishing measures is that the phishing site can simply present you with an official-looking login page and say that this is our new and improved security page. Add some impressive graphics like locks and things and most victims will happily provide their username and password.
The problem is that an average user does not know how to evaluate all off the security cues the browser provides. In the physical world, it’s very hard to trick someone into going into a fake bank building, but on the web, it’s trivial to redirect someone to a fake server and inexpensive to create a very offical-looking virtual bank.
Say your bank site is www.bofa.com. The certificate issued to Bank of America by Verisign will have ‘www.bofa.com’ as its CN (common name). Your browser compares the certificate CN to the host name and complains if they don’t match.
The scammer won’t be able to get a cert from a trusted authority such as Verisign or Thawte. Your browser contains the top level certificates from these Certificate Authorities and many more. When a web site cert comes in the browser looks to see who issued it and uses the built in CA cert to verify it. The scammers cert won’t pass this verification and the browser will flag it.
a) Some sitekey systems require a cookie on the system to display the sitekey, otherwise they ask some personally identifiable questions before setting a cookie.
b) SSL certificate does not prevent a man-in-the-middle attack when you are at the wrong site. If you are not at the banks site, but it looks, acts and feels like it, your browser won’t detect a certificate mismatch.
c) Most users would not notice if they were not asked the sitekey anyway.
Combining a and b, you got to a phishing site (which behind the scenes browses to the bank site) and it acts completely like the Bank. I’m sorry, kferr, but when you said:
my marketing fud detector went off. Perhaps SSL protects you from a mitm attack when it’s on the network level (router/DNS/etc.), but how can you possibly tell a customer from a phishing site to which your customer inadvertently went? Even if it’s a previously stored cookie, unless you need a phone call to the Bank where they very carefully force you read off the URL the customer is at to reset the cookie (which nobody would put up with), there is no good way to detect that you are dealing with a phisher.
Not to drag this out, but suppose I register scammer.com. I go to VeriSign (BTW VeriSign bought Thawte a few years back, but the certs are still different), prove my identity, and then get a cert for my site (that will cover *.scammer.com). I then send you an email link to boa.scammer.com that appears to you as www.boa.com, and the browser will be happy.
Now, a scammer probably wouldn’t want to identify himself for the record, so maybe this isn’t really done, but AFAIK the technology wouldn’t prevent it. Am I missing something?
They can’t get a certificate for bofa.com, but they can certainly get a certificate for iscammedyourmom.com. It’s not like there is any kind of trust network, Verisign will just fork over a certificate to anybody with a business, a domain name and a few hundred bucks.
As a bit of a research point, I will offer up the following anecdote…
I am a person who works in technology. Specifically, creating Web sites, often with security features and SSL certs. I would say that I know my way around “what is secure and what is not.”
I also do a lot of online banking. Between doing the accounting for my company and my personal accounting, I’d say I go to about 10 sites that have sitekeys on a weekly basis.
So anyway, yesterday I was on the phone with someone from my bank and I went to the bank homepage to log in. I typed in my username then went to the sitekey page and typed in my password.
Except, the sitekey wasn’t there! The secret word and the special picture were not there. And I pressed “OK” to sign in and submit my password (only to be told it was not the right password.)
After a moment of thought, I realized that I’d typed in the wrong username, and the sitekey page didn’t have a picture and a phrase for me.
My point is that now, on the other end of the spectrum from “people who don’t know better” I feel like there’s getting to be lots of people like me who use secure sites very often and can’t be bothered to keep the stupid pictures straight (I’ve seen similar pics on different sites) and are just too used to these extra layers of security to notice whether the special pic and the special phrase are there.
Anyway, thought I’d throw that out there as an example of why sitekeys are kind of bogus. They’re only useful if you can keep all of your info straight. Otherwise, they’re just a “random” picture on a page.
Bolding mine. It appears to you as the right site, but the browser does a reverse DNS lookup and doesn’t like it. Unless, of course, that the DNS has been compromised (and there’s been lots of that lately) then you’re screwed.
To groman, the cookie is part of it, but there are other network and behavioural components. I’m a techie, I’ll have to kick you in the nuts for using the word ‘marketing’ near me.
I’ll stop using ‘marketing’ as soon as you admit that network and behavioral components are due to poor implementations for the phishing site A well designed fetcher could be made indistinguishable from some random browser on a public terminal.
I am your bank! You must correct information! We have bad data for you, we have disable you account!!! You must click on this link ->www.bankofamerica.com! Give us your secret password! To ractivate account!!
The URL in the email looks legit to a naive user but it’s not really what the browser is instructed to do. A user might notice that the URL in the browser address bar doesn’t match what he clicked on, but guess what, if you click on www.bofa.com, which is the legit site, you don’t get what you typed in either.
I don’t have a cert but if I did, the browser wouldn’t make a peep. It would check to see if the cert matched the URL, and it will.
A well designed fetcher could be made indistinguishable from some random browser on a public terminal.