Home / Blogs

Hacking: Users, Computers, and Systems

As many people have heard, there’s been a security problem at the Internal Revenue Service. Some stories have used the word hack; other people, though, have complained that nothing was hacked, that the only problem was unauthorized access to taxpayer data but via authorized, intentionally built channels. The problem with this analysis is that it’s looking at security from far too narrow a perspective—and this is at the root of a lot of the security problems we have.

Fundamentally, there are three types of intrusion, which I’ll dub “user”, “computer”, and “system”. User intrusion is the easiest to understand: someone has gained illegitimate access to one or more user accounts. That’s what’s happened here: the authentication mechanisms were too weak to withstand a targeted attack on particular individuals’ accounts. This is the kind of attack that the usual “pick a strong password” rules are designed to protect against, and the kind that two-factor authentication will protect against. Authentication failures are not the only way this can happen—there are things like cross-site scripting attacks—but in general, the impact is limited to some set of user accounts.

Computer intrusions are more serious: the attack has gained the ability to access files and/or run code on one or more computers within a protected site. In general, someone who can do this can compromise many user accounts; it is thus strictly worse than a user intrusion. Generally speaking, this class of problem is caused by buggy software, though there are other paths for the attacker, such as social engineering or compromising an authorized user’s credentials. (The attacker may even be an insider with legitimate access to the target machine.)

System intrusion is the most nebulous concept of the three, but often the most important. It can refer to any security failures. Imagine, for example, that there was a magic URL that would cause Amazon to ship you some books, but without giving access to any of their computers and without billing any other customers. It’s not a customer intrusion, and it’s not a computer intrusion—but the system—the collection of computers, people, and processes that collectively are Amazon—has done the wrong thing.

System intrusions—hacks—often cannot be fixed in a single place. It may be that some interfaces were poorly designed for the humans who have to use them (and make no mistake, that’s a serious technical issues), or it may require much more far-reaching changes. Let’s go back to the IRS hack. Looked at simply, it’s a user account intrusion; there are thus the predictable calls for two factor authentication when logging in to the IRS. It sounds simple, but it’s not; in fact, it’s a fiendishly hard problem. Most people interact with the IRS once a year, when they file their tax returns. This particular application is especially useful when doing things like buying a house—and that’s not something folks do every week. How will people possibly keep track of their credentials for this site? Use text messages to their phones? The IRS does not have a database of mobile phone numbers; suggestions that they should have one would be greeted by howls of protest from privacy advocates (and rightly so, I should add). Besides, if you change your phone number would you remember to update it on the IRS site? If so, how would you authenticate to the site when you no longer have your old number? Authentication to the government is among the most difficult authentication problems in existence; it’s a cradle-to-grave activity, and generally used infrequently enough that people will not remember their credentials.

Where does the blame lie? Arguably, the IRS should have had a better understanding of attackers’ capabilities before deploying this system. It’s not clear, though, that they can do much better. The choice may have been between not offering it and offering it knowing that there would be some level of abuse. In that case, the focus should be on detection and remediation, rather than on stronger authentication.

By Steven Bellovin, Professor of Computer Science at Columbia University

Bellovin is the co-author of Firewalls and Internet Security: Repelling the Wily Hacker, and holds several patents on cryptographic and network protocols. He has served on many National Research Council study committees, including those on information systems trustworthiness, the privacy implications of authentication technologies, and cybersecurity research needs.

Visit Page

Filed Under


The flaw seems to be one I've Todd Knarr  –  May 29, 2015 7:08 AM

The flaw seems to be one I’ve seem way too often: using publicly-known (or at least widely-known) information to authenticate identity. That can’t work because, by definition, I’m not the only person who knows that information and knowing it doesn’t prove you’re me. It’s only becoming an issue because we’re moving towards on-line access where the accounts can be remotely attacked without the attacker having to place himself directly at risk. Infrequently accessed or not, we’re going to have to adapt security precautions to fit changing situations. Frankly I’m in favor of either creating a standard 2-factor algorithm like Google’s Authenticator so a single device can store the codes for an unlimited number of accounts (and the keys can be backed up and reloaded by the user but not accessed remotely short of a compromise of the user’s local computer/device), or barring that getting people to routinely use a password vault so they don’t have to remember passwords themselves. If that requires changing habits… the only constant in the universe is change, people need to get used to it.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



New TLDs

Sponsored byRadix


Sponsored byDNIB.com

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC