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/
