The SiteKey Fallacy

While working this summer a long way from my home bank, I opened an account at Bank of America so I could deposit my paychecks. Before I could do my banking online, though, I had to learn all about their authentication system called SiteKey.

BoA is quite proud of this system, which is designed to avoid phishing attacks, in which some malicious guy (affectionately dubbed Mallory) creates a web site that looks just like Bank of America's, convinces somebody to click that link to login to their BoA account, and steals their password when they try to login. With SiteKey, in theory, the user knows they're logging into the real BoA web site, not some bogus one.

For those too lazy to click the SiteKey link above, it works like this: when you initially sign up for online banking, you choose a unique picture from hundreds of options and you provide a unique phrase. This photo and passphrase together make up your SiteKey. Later, when you want to login, you first enter your Online ID without the password. Then the BoA website shows you your SiteKey. Only Bank of America knows what your SiteKey is, since you created it with their site securely when you signed up, so (theoretically) seeing your SiteKey means you must be at BoA's web site. Now you can safely enter your password and login.

This is terrible for two reasons:
1) There already exists a perfectly good system in place to accomplish exactly the goal of authenticating web sites to end users.
2) SiteKey doesn't work.

I'll address these in order.

First, there already exists a system by which end users can verify that the web site they're viewing is authentic. Basically, when you visit a secure web site, the site provides some sort of proof that it is owned by the organization which claims to own it. When viewing a secure site, most modern browsers show a padlock icon somewhere on the page or in the URL bar, and you can click that icon for more information. Browsers also alert users if they're dealing with a website which can't prove it is who it claims to be. (The details of all this are beyond the scope of this blog entry, but for the curious, look up public key encryption, SSL, and certificates.)

Thus, as long as the user checks for the presence of this padlock icon, as well as the URL which he's viewing (since that's the identity of the web site), he can be pretty sure that any information submitted will be securely transmitted to the person he's expecting to send it to.

BoA does use this system for their web site, but SiteKey is implemented on top of that as a way to make the user feel more secure. While I appreciate the goals BoA seeks by doing this, it's fundamentally a bad idea. Standards exist for the benefit of users. If every web site that wanted to make users feel secure implemented their own solution for the problem, then we'd have countless different solutions, confusing users even more and hurting the overall web experience.

A much better approach is to develop new standards or improve existing standards to solve this problem. That way, users aren't confronted with various different attempts to solve the same problem. This has the added benefit of community involvement, which results in people finding fatal flaws in otherwise great ideas before they're implemented (see below).

In most cases, creating a community standard (or changing an existing one) is difficult. In this case, though, the standard already exists and works fine! The problem is that many people ignore security warnings. A simpler solution, then, is to publicize the existing system and make it easier to use (e.g., by providing better browser support, possibly in the form of extensions).

A much bigger problem with SiteKey is that it simply doesn't work. It makes phishing attacks marginally more difficult, but nevertheless possible. It's fairly simple to break.

Normal phishing attacks look like this:
1) Lure user to evil web site looking just like a real web site
2) Get the user to enter their username/password
3) Save the username/password that the user entered, and forward them onto the real site (or tell them that the login failed, or whatever - you really don't care what happens now, since you have their username and password!)

A SiteKey phishing attack could look like this:
1) Lure the user to an evil web site looking just like the real web site
2) Get the user to enter their username
3) From the evil web site, enter the username into the real BankOfAmerica web site.
4) BoA doesn't recognize the evil web site's computer, so it asks a personal question to verify the identity.
5) Display this personal question to the user, and forward their response to the server.
6) Now that the evil site has answered the personal question properly, BoA shows the SiteKey and asks for a password. The evil site relays that to the user and asks for their password.
7) The user enters their password. The user is toasted once again.

Note that this is only marginally more difficult. Anyone sufficiently motivated who could accomplish the first sort of attack can easily accomplish the latter. So seeing your personalized photo of a cute little puppy might make you feel secure, but don't get too comfortable. You still need to take all the precautions against phishing attacks you always had to take (as I mentioned above: check the URL, and your browser's padlock icon).

It's worth mentioning that this vulnerability has been pointed out before in SiteKey and similar systems, and alternatives have been proposed. Which makes it all the more saddening that another institution I actually care about seems to be switching to a SiteKey-like system.

Installing Nexenta Alpha 5 on Toshiba A75 laptop

Excited from my recently-completed internship on Sun's Solaris Kernel Group, and desperately needing to reinstall something on my Toshiba A75 laptop, I decided to go ahead and try installing Nexenta Alpha 5.

Why Nexenta?

I've been a Debian (or Debian-based-distro) user for a while. First I used stock Debian, but Kubuntu quickly became my distro-of-choice after I installed it over year ago. To me, it had everything I loved about Debian (a familiar /etc layout, a great packaging system, etc), but more of the useful (but non-free) packages and better forums for support. [K]ubuntu took something I loved, and made it easier for me to use.

Nexenta is a distribution of OpenSolaris based on Ubuntu. The idea is to make something much like Ubuntu, but with the fast, rock-solid Solaris kernel rather than Linux. Now, I believe the biggest problem with using OpenSolaris is the lack of a package manager on par with apt, not to mention all the other tools and programs I know and love. But with Nexenta, you get apt as well as over 12,000 packages. (Debian developers appear less than enthused. (I dare you to read more than 50% of that thread.))

I'm installing Nexenta on my laptop because I'm hoping this will be another case of taking something I love (Ubuntu) and making it better (with a more solid kernel, zfs, zones, dtrace, etc). I recognize that it might not be quite as good as Ubuntu in terms of the level of support for everything I use, but if it's most of the way there, the extra Solaris features might be worth it to me.

Installation

Goals

I wanted to run ZFS for most of my storage, and I definitely wanted the partitions (or slices, in Solaris-speak) encompassing /home and other non-system areas to be separate. That way, when I reinstall, I don't have to back that up - I can simply tell the installer to skip those partitions.

Troubles

Not surprisingly (to me), the installation did not go terribly smoothly. Because of my storage goals (above), I couldn't use the default partitioning scheme. But the Nexenta installer does not have good support for manually partitioning your disk - either you let it decide how to arrange your partitions, your you use the cryptic format(1M) utility.

Note that format(1M) isn't usually too bad if you know what you're doing, but in my case, I was quickly turned off. When I selected my disk (c0d0), it asked me nearly a dozen questions whose answers I couldn't have known easily and I expected it to determine automatically. Apparently, this is not a common case, but I needed to know the number of heads on the disk, the number of sectors per track, the number of cylinders (data and alternate), the number of blocks per cylinder. There were a number of other questions, but those had a "default" option.

For the answers to these questions, I booted up my existing Ubuntu system and ran "fdisk -l". (Note: I didn't want to keep score, but at this point we have Linux: 1 and Solaris: 0.)

The other major problem I had was that once I did accomplish all this, when I rebooted, I got the word "GRUB" in the corner of my screen, and nothing else. The pretty GRUB menu never came up. I think this was related to a screwy partition table I had set up. More below, but after reinstalling with a "proper" setup, it seems to be working.

Slicing (Partitioning)

Important things to remember when setting up your slices (which I discovered from this multi-boot Solaris x86 page) is that slices 2, 8, and 9 are considered special:

• Slice 2 should always be a partition with the "backup" tag which occupies the entire hard drive (I didn't even realize that slices could overlap).
• Slice 8 should always be a partition with the "boot" tag
• Slice 9 should always be a partition with the "alternate" tag and occupy 2 cylinders

I have yet to find any documentation on what the different tags mean, though.

Anyway, I expanded the example in the Nexenta Alpha 1 guide (which the Alpha 5 guide references if you need to manually partition the drive). I followed that guide closely, so I'm not going to repeat the steps here. But since my drive was already partitioned for Windows and Linux, I first had to delete all the existing partitions. In the format tool, I typed "partition" and then deleted each partition. Then I saved and exited the partition tool. Then I reentered it - it now got me to the default formatting described in that guide (a 100% Solaris disk).

Using their example as a guide, but taking into account my desire to use ZFS, I created the following table on my 100gb hard drive:

Slice #	Tag	Cylinders	Size	Comment
0	root	3-916	7gb	Root partition
1	swap	917-1047	1gb	Swap partition
2	backup	0-12157	whole drive	Reserved - don't change this
3	alternate	1048-6602	42gb	ZFS 1
4	alternate	6603-12157	42gb	ZFS 2
5	unassigned	0-0	0	(Not used)
6	unassigned	0-0	0	(Not used)
7	unassigned	0-0	0	(Not used)
8	boot	0 - 0	8mb	Reserved - don't change this
9	alternate	1 - 2	16mb	Reserved - don't change this

Note that I split up my non-system storage space into two slices so that I can use zfs mirroring. I'd rather use multiple drives and raidz2 of course, but it's a laptop with just one drive. Having both mirrors on the same drive might be a performance hit (have to look into that), but should be more reliable. If the drive fails, I'm dead, but if there's a transient hardware error that only messes up some data, I can recover. I'll be regularly backing up this machine anyway (I hope).

Summary

With the exception of the problems noted above in the "Troubles" section, the installation went smoothly. On the second try (with a correct slice table), she booted up wonderfully. Time to go play!