Libraries & Leaky Data, Part 2

In my first post of the series “Libraries & Leaky Data,” I provided an overview of how libraries are accumulating patron information in a variety of “hidden” areas of the library. I noted that if a library were to be subject to a ransomware attack, it is possible that patron information could be stolen from machines dedicated to print release, computer reservation, or self-checkout. For the second part of this series, I will explain how libraries are passing data through their networks and through the internet insecurely.

First, it is important to understand that data traversing the internet from one server location to another are by default insecure unless measures are taken to secure those transactions. So a library patron logging onto their OverDrive account to search and get ebooks is in good shape because the OverDrive website utilizes HTTPS, correct?

Not necessarily. What many libraries are doing is providing this authentication on the back-end of this transaction without any security whatsoever. So the patron actually might submit their barcode and PIN via HTTPS, but the communication back to the library’s integrated library system (ILS) from the vendor, e.g. OverDrive, is likely using SIP2 to verify this barcode and PIN. The back-end communication does this without HTTPS or a VPN to protect that transmission. This creates the illusion of data security to the public, but the reality is the library’s go-to protocol (most likely SIP2) for 3rd party connections are usually deployed without any secure communication in place.

What this means is that for every patron login with OverDrive, the OverDrive servers verify back to the library’s ILS using insecure methods (no HTTPS at all) and the ILS sends a trove of patron data back to OverDrive in plain text. Here are the 10 patron fields of information shared within a single SIP2 patron authentication query.

1. User’s barcode
2. User’s PIN/password
3. User’s full name
4. Address
5. Email address
6. Phone number
7. Birthdate
8. Gender
9. Age category
10. Fines owed

This problem isn’t just with OverDrive but it is with nearly every 3rd party hosted service a library is using. If your library is authenticating with SIP2, the chances are that your other hosted services such as room reservation are doing the same thing: showing a HTTPS on the patron/staff interface, but communicating without any security on the back-end.

Making matters worse, this insecure communication problem is also inherent with our ILS platforms. The ILS staff client communicating back to the ILS server is another source of data being sent back and forth with potential insecure means. Some ILS platforms handle this well from a security standpoint, e.g. Polaris utilizes encryption within a remote desktop client. Other staff ILS clients require additional layers of security to prevent the client from sending or requesting data from the server in an insecure transaction. ILS platforms such as Symphony or Sierra utilize a staff client that will pass data back to the ILS server in plain text. Some of the newer web-based staff clients such as SirsiDynix BLUEcloud, Polaris LEAP, Evergreen, or Ex Libris Alma utilize the HTTPS security on the staff client, which is the ideal secure communication as it is end-to-end and requires no intermediate network security such as the VPN or VLAN.

How can we improve our library data security? I will outline the various approaches to improve and protect library data transmission in part 3 of this series.