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: [email protected] On Aug 24, 2012 5:00 PM, "Lazar, Alexey Vladimirovich" < [email protected]> 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 > > [email protected] > > > > > > > > > > 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 <[email protected]>: > >> > >>> 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/ > >
