[OPEN-ILS-DEV] Feature proposal: SSN-censoring functionality

[Wolf Halton]

Storing SSNs unencrypted is a terrific mistake, in the US. Storing them at
all is a Very Bad Thing (TM).
Storing a hash that is evidence that a proper authority has seen the
number, or just a boolean true, seems like enough.

Wolf Halton
http://sourcefreedom.com
Apache developer:
wolfhalton at apache.org
On Aug 24, 2012 5:00 PM, "Lazar, Alexey Vladimirovich" <
alexey.lazar at mnsu.edu> wrote:

> All true and understood, but probably a different issue.  The reality of
> what the "SSN equivalent" is in jurisdictions other than USA likely varies.
> It may be perfectly legal and acceptable to use that "SSN equivalent" (be
> it passport number or some other ID), because there may not be a different
> option. It is possible that the "SSN equivalent" does not carry the same
> financial risks as the US SSN for misuse.  Regardless, if privacy and
> security of that ID can be maximized, that's probably a good thing.
>
> On Aug 13, 2012, at 13:39 , Justin Hopkins wrote:
>
> > I also believe that storing SSN's is a Very Bad Thing. This may be
> because I'm coming from an overwhelmingly enterprise/academic environment
> where FERPA is taken very seriously, but in general I treat SSN's as I
> would credit card numbers or personal medical information. I don't see
> reason for needing to use them in an ILS. Doing so immediately makes your
> system worthwhile for any potential attackers and puts your organization in
> the position to have to make a painful disclosure to your public should
> there be a breach.
> >
> > Regards,
> > Justin Hopkins
> > IT & Web Services Coordinator
> > 573-808-2309
> > justin at mobiusconsortium.org
> >
> >
> >
> >
> > On Aug 13, 2012, at 10:30 AM, Thomas Berezansky wrote:
> >
> >> The more I look at the list of issues you present, the more I am
> convinced that storing SSNs as they currently are is a *bad* thing. Perhaps
> storing them in general is a bad thing?
> >>
> >> Disclaimer: MVLC has local laws preventing us from even considering
> storing SSNs or Drivers License numbers, so we don't store that information
> at this time.
> >>
> >> "Sanitizing" the data as it comes out requires flagging it as to be
> ignored going back in, unless non-sanitized data comes back. This will
> really screw with the code paths for patron editing and retrieval. Note
> that currently the *only* place I know of with protection for US-style SSNs
> is the patron sidebar view. Hitting "Edit" shows you the full thing anyway.
> >>
> >> A better solution may be to define a new table for storing one or more
> pieces of data for identifying the patron. Permissions can then be used to
> allow enforcement of who is allowed to see the information, complete with
> whether or not they can see the un-sanitized data. (This could, in theory,
> allow Massachusetts libraries to store this data and still comply with the
> law.)
> >>
> >> Each piece of information to be stored in that manner could then have
> one or more regular expressions for sanitizing. I would implement that as
> one or more search/replace sets, with capture group(s) being used in the
> replacement.
> >>
> >> If these data pieces are never exposed via things like pcrud then they
> will be very difficult to get out of the database.
> >>
> >> Two remaining issues I see off the top of my head are:
> >>
> >> Reporter - It tends to bypass permissions.
> >>
> >> Patron Editing/Registration - Do you show the full value by default, or
> provide a change/update interface that can load the full value (provided
> you have permissions to see the un-sanitized current value)?
> >>
> >> Thomas Berezansky
> >> Merrimack Valley Library Consortium
> >>
> >>
> >> Quoting Kivilahti Olli-Antti <olli-antti.kivilahti at jns.fi>:
> >>
> >>> Goood moorning Evergreeners!
> >>>
> >>> As a fruit of our migration planning work, I present to you... the
> schematics to an internationalizable SSN-censorer!
> >>>
> >>> Currently Evergreen only hides the sensitive letters from a
> us-standard SSN number. It seems to be that almost every nation has their
> own SSN-format. While we have been looking for ways to improve this
> handicap in Evergreen we have given great concern to make this modification
> as internationalizable as reasonable.
> >>> A challenge in designing a solution is the fact that even inside one
> installation, we can have SSNs from multiple SSN-formats.
> >>> In our case it seems to be that such cases are rare. Maybe <2% of our
> clientele has a SSN of other formats than Finnish (then Swedish or Russian,
> and fringe cases). I believe the case is same in the states as well. For
> this reason I am planning to have filtering done according to SSN-format
> relevancy.
> >>> We have a list of SSN-filters, and the top one is the most used one.
> If it won't match the given SSN, then we try the next relevant one, until a
> match is found or error is given to add a new filter.
> >>> Here are the more detailed steps to complete the task, in other words,
> the implementation plan.
> >>> http://193.65.112.189:8080/browse/EGDEV-28
> >>> The task is waiting for planning review and feedback from the
> community.
> >>>
> >>> This functionality will be implemented by The Regional Library of
> Joensuu as a high priority modification during our migration period to
> Evergreen.
> >>>
> >>> --
> >>> Olli-Antti Kivilahti
> >>> Open Library 2013
> >>> Library of Joensuu
> >>>
> >>
> >>
> >
>
>
> Alexey Lazar
> PALS
> Information System Developer and Integrator
> 507-389-2907
> http://www.mnpals.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20120826/6cbcd75d/attachment.htm>