Libraries & Leaky Data: Part 2

By Aaron Skog

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.

Description: Library Data Communication Diagram

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.

One thought on “Libraries & Leaky Data: Part 2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s
https://ilaconnecter.home.blog/2020/01/06/libraries-leaky-data-part-2/
ilaconnecter.home.blog
crawl=CC-MAIN-2022-40
174229
application/http; msgtype=response
sha1:SAEV5XCPVJS2OWISKOZD4UMNUY3QM3VY
<urn:uuid:fa7dc6db-0068-469e-885d-90bdccf3a2ee>
2022-09-30T11:40:38Z
192.0.78.30
text/html
sha1:B4RUXRLSMQ5J7LRGLWY5FRF7EOG7AS33
<urn:uuid:94566a05-9134-4119-956c-acd6e215add1>
https://ilaconnecter.home.blog/2020/01/06/libraries-leaky-data-part-2/
response
<urn:uuid:df464cf2-3bc6-4118-9d42-a4c0c4ba84c2>
isPartOf: CC-MAIN-2022-40
publisher: Common Crawl
description: Wide crawl of the web for September/October 2022
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-70
software: Apache Nutch 1.19 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/