“How much effort do you want to spend securing your computer systems? Well, how much do you not want to be in front of a reporter’s microphone if a security breach happens?” I don’t remember the exact words, but that quote strongly resembles something I said to a boss at a previous job. Securing systems is unglamorous detail work. One slip-up plus one persistent (or lucky) attacker means years of dedicated efforts are all for naught as personal information is inadvertently released. See, for example, what happened recently with Sony Online Entertainment’s recent troubles.

It was in that frame of mind that I responded to a series of questions from a librarian taking a computer science class. (As someone else who straddles the computer-science/library-science divide, I wanted to encourage this line of thinking!) Now library systems typically don’t have credit card information, so they may not be attractive to individuals that seek to expose or exploit personal information. But our systems do have physical addresses, e-mail addresses, and sometimes birthdays or other personal data. And we have a professional ethic to keep patron use information private.

The person that sent me these questions asked that I not mention a name or affiliation, but that it was okay that I repost the questions along with my replies. I’m hoping this encourages some discussion because my understanding of the use of encryption in ILS products is very narrow and only somewhat deep (and is getting shallower by the day as my direct experience is going on ten years old).

Background on the project is that during our encryption unit, I realized that I didn’t know anything about what libraries to do back up our strongly stated policies about protecting patron privacy, so I wanted to find out more about it.

Questions:

1. What encryption tools/standards, if any, are used to safeguard patron accounts (name, items checked out, databases accessed, etc.) at the library?
2. Where in the systems do these tools typically fit — at the ILS level, or somewhere else? (e.g., university ID systems)
3. How are circulation and other records expunged? I.e., are they permanently deleted in such a way that hard drive forensics couldn’t bring them back?

In my experience, this patron information is not encrypted in integrated library systems. The difficulty is that if those bits of information are encrypted, they must be decrypted by the program in order to be useful (generating an overdue notice means the patron’s information must be known to the program, displaying the patron’s name on his/her account information screen, etc.). And for programs to decrypt they must have the secret key. And if the programs know the secret key it is trivial for an attacker to get the key as well. And since good encryption, by its nature, is computationally “expensive” there would be a lot of system load with all of the encryption and decryption of bits of information. (Computationally expensive is good because it makes it harder for an attacker to guess the correct key.)

Password Hashing Flowchart

Note that passwords are a special case. Passwords are not really encrypted in a database; rather the output of a “one way hash” algorithm is stored. When the user tries to log in, the same one way hash algorithm is applied to the text string entered as a password and if the output matches what is stored in the database the user is let in.

As the diagram shows, with the login attempts the hashed password is not decrypted; the output of the hash algorithm is compared to what is known to be the hashed password.

[Aside: I'm trying an experiment in this post. The diagram is a Scalable Vector Graphic (SVG) file. It seems to be showing up fine in the browsers I'm testing, but I have no idea how it will appear in the RSS feed or if you are using an RSS reader or receiving this post via FeedBurner e-mail. If you don't see the graphic, try viewing the post via the DLTJ website.]

The most effective encryption would be at the database management system layer. For instance, Oracle has “Transparent Data Encryption” feature. “Data is automatically encrypted when it is written to disk and automatically decrypted when accessed by the application.” Automatic encryption is not built into MySQL, but you can use a MySQL-specific function to encrypt a field. PostgreSQL has a contributed module that performs the function.

Another option — other than database-level encryption — is to have the operating system encrypt the underlying filesystem (for example, the Red Hat Encrypted Filesystem). That way all of the database storage files — stored in that filesystem directory — would be encrypted.

Note, though, that in any of these cases, the key is known to the computer somehow, and so it is possible for an attacker to recover the key and decrypt the data. There are, of course, varying levels of obscurity one can apply to the key, but I think we’re getting pretty far off on a tangent.

How often circulation and other records would be expunged would depend on implementations in each software system, but as a general guideline I don’t think a strong deletion mechanism is used to obliterate data on the disk. I’d be happy to be proven otherwise. And as you consider hard drive forensics, also think about pulling the same information off backup tapes; that would probably be easier to get to.

In a follow-up, I was asked:

WRT your response on Q2, do you have an idea of what level “most” or “some” libraries might have the encryption, or were you speaking purely from a view of what ideal/good situations might look like?

On 3, I have heard from a few others that there seems to be just deletion with no zeroing out features or the like and that it does take a period of time (1-2 months) for backup tapes to be overwritten. So it strikes me that the weakest link may be in the area we talk most about protecting.

With regards to the database-level or the filesystem-level encryption, I was speaking from a point of view of what idea/good situations might look like. One of the outcomes of posting these questions to a wider group of readers is, I hope, more real-world experience reports from people who might be running systems that actually do this.

Yes, I think those are weak links, with the backup tapes being the biggest problem. One can’t predict when blocks on a live filesystem disk will be overwritten, but overwriting tapes is pretty predictable — and easy because one doesn’t need access to the live system.

This week’s Thursday Threads looks at a big hole in the security model of most internet sites that require you to log into them with a username and password plus a pair of stories about “big media” battles. If you find these interesting and useful, you might want to add the Thursday Threads RSS Feed to your feed reader or subscribe to e-mail delivery using the form to the right. If you would like a more raw and immediate version of these types of stories, watch my FriendFeed stream (or subscribe to its feed in your feed reader). Comments, as always, are welcome.

Users of Non-SSL Sites are Prone to Hijacking

When logging into a website you usually start by submitting your username and password. The server then checks to see if an account matching this information exists and if so, replies back to you with a “cookie” which is used by your browser for all subsequent requests.

It’s extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called “sidejacking”) is when an attacker gets a hold of a user’s cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.

Screenshot of Firesheep in action, from codebutler.com

This is a widely known problem that has been talked about to death, yet very popular websites continue to fail at protecting their users. The only effective fix for this problem is full end-to-end encryption, known on the web as HTTPS or SSL. Facebook is constantly rolling out new “privacy” features in an endless attempt to quell the screams of unhappy users, but what’s the point when someone can just take over an account entirely? Twitter forced all third party developers to use OAuth then immediately released (and promoted) a new version of their insecure website. When it comes to user privacy, SSL is the elephant in the room.

Today at Toorcon 12 I announced the release of Firesheep, a Firefox extension designed to demonstrate just how serious this problem is.

Most of the coverage of Firesheep this week focused on the fact that using Facebook on an open wi-fi network in a coffee shop makes you prone to having your account broken into. That is true, and perhaps most the most common scenario, but the problem goes deeper than that. This can occur at any point where a third-party can intercept the communication between your browser and the web server: your home wireless router, your internet service provider, or even some types of local area networks. The real answer is to have the entire session — from the point when you log in to when you log out — encrypted. Google recently made this the default for GMail sessions, and some of the engineers involved in the effort published findings about how the SSL encryption overhead isn’t that bad. In the meantime, Network World has some options to consider to protect yourself a little bit from this kind of attack. (Hat tip to Dan Scott on Code4Lib IRC.)

Cory Doctorow on the Role of “Free”

The topic I leave my family and my desk to talk to people all over the world about is the risks to freedom arising from the failure of copyright giants to adapt to a world where it’s impossible to prevent copying. Because it is impossible. Despite 15 long years of the copyright wars, despite draconian laws and savage penalties, despite secret treaties and widespread censorship, despite millions spent on ill-advised copy-prevention tools, more copying takes place today than ever before.

As I’ve written here before, copying isn’t going to get harder, ever. Hard drives won’t magically get bulkier but hold fewer bits and cost more.

Networks won’t be harder to use. PCs won’t be slower. People won’t stop learning to type “Toy Story 3 bittorrent” into Google. Anyone who claims otherwise is selling something – generally some kind of unworkable magic anti-copying beans that they swear, this time, will really work.

Cory writes this piece in the U.K. Guardian in response to a column from a fellow Guardian writer on how creative people can control their own intellectual property and some media companies’ demands for digital rights management are actually stifling creativity. It starts as a rant and moves quickly into a powerful summary of what is at stake in the “copyright wars.” (Hat tip to OCLC’s Above the Fold.)

What Network Neutrality Really Means

In its continuing contract showdown with Cablevision, the News Corporation tried to extend its blackout of the Fox Broadcasting network to Fox.com and to Hulu, the popular Web site for free TV viewing, on Saturday. Angry Cablevision customers reported being unable to watch episodes of “Glee” and “House” on Hulu.

The blackout caused shock waves because it had not been done before by a programmer. Though the shutdown was brief, the message was unmistakable: do not expect to be able to watch Fox online unless you are paying for Fox on TV.

The attempted Web blockade was leverage for Fox in its contract negotiations, but more important, it was the latest evidence that entrenched media companies hope to replicate their walled gardens in a new medium, the Internet.

Broadcast and cable companies in the New York City area are locked in a dispute over what the latter needs to pay the former for the right to retransmit the content on cable TV. The dispute spilled over into the internet when the cable company started blocking internet subscribers from reaching the broadcast company’s shows on its website and on Hulu. This could be seen as a litmus test for net neutrality: should an internet service provider be able to decide what content it sends to end-users — either by giving preferential treatment to some content or by blocking other content? The dispute, by the way, continues…even impacting those who want to watch baseball’s World Series.

The title of this post is the same as the report it describes, Everyone’s Guide to By-Passing Internet Censorship for Citizens Worldwide [PDF]. It was announced by Ronald Deibert last week on his blog at Citizen Lab. The one sentence synopsis goes like this: “This guide is meant to introduce non-technical users to Internet censorship circumvention technologies, and help them choose which of them best suits their circumstances and needs.”

Although the stated audience is non-technical users, I found the description of techniques and circumstances under which one might deploy the techniques very interesting. The document provides guidance for those seeking circumvention and those who want to provide it. After a brief introduction to censorship activities worldwide (including in the United States), it walks the reader through an analysis of needs and describes solutions that meet the needs based on the user’s technical skills. I knew ‘tor‘ — a long-time favorite of mine — would be in there, but I was surprised by the range of other options.

To put a library spin on the report, some of the solutions offered are usable on “public computers” — such as, say, what one might find in a library. One could take the report and read about the techniques with the intent to block them on your public workstations, but I think another reading of it would say that such attempts are ultimately futile because of the likelihood of other similar services popping up to take their place. Unless you are running a white-list-only setup (that is to say, your public workstations are explicitly set to only allow access to a prescribed set of sites), any user can walk up to any public workstation and access the circumvention sites described in the report or any other ones that spring into existence.

The circumvention techniques are, of course, do not provide an assurance of privacy. Even though the network traffic is encrypted, the activities of the user can still be monitored by keystroke loggers and other techniques in the workstation itself. In order to get around that, one would need to restart the public workstation with a bootable Linux distribution, but that is perhaps a report for another time…

The text was modified to update a link from http://deibert.citizenlab.org/Circ_guide.pdf to http://www.nartv.org/mirror/circ_guide.pdf on January 28th, 2011.

The text was modified to update a link from http://deibert.citizenlab.org/Circ_guide.pdf to http://www.nartv.org/mirror/circ_guide.pdf on January 28th, 2011.

The text was modified to update a link from http://deibert.citizenlab.org/blog/_archives/2007/10/10/3282831.html to http://deibert.citizenlab.org/2007/10/everyones-guide-to-by-passing-internet-censorship-for-citizens-worldwide-new-release/ on January 28th, 2011.

The text was modified to remove a link to http://www.tech-faq.com/bootable-linux-distributions.shtml on January 28th, 2011.