Re: Implementing masking either via RCAC or encryption fieldproc

On 19 February 2018 at 13:12, Jay Vaughn <jeffersonvaughn@xxxxxxxxx> wrote:

Consider a pgm that does the following... (for a masked user)...
1.) a loanholder ss# is retrieved via chain i/o for one reason or another
2.) it is returned, of course masked (999999234)
3.) then suppose that same pgm needs to chain to another file with the
returned masked value (say for instance a transactional file keyed by ss#
(non-encrypted))...
4.) finally the masked return value needs to be displayed on a
screen/report in its masked form

This is why FIELDPROC was not a good fit for us. We went with storing
the un-masked primary key in a hidden field and putting the masked
field on the display. Pass the real/hidden one to follow-on processes
via call/parm. Database tables always contain the un-masked value.
We are aggressively removing such numbers from the database
altogether. SSN really should not be a primary key to any table;
we've been replacing it with a surrogate key.

An alternative we discarded was to create a separate 'true' SSN field
and replace all the existing SSN fields with a randomly generated key,
so that the default that everyone got to see was the meaningless
random number. It would then take special programming (and access to
the proper VIEW) to be able to see the real SSN. That has similar
advantages to FIELDPROC in that every existing program sees the
'random/masked' value and it leaves all the primary keys in all those
daughter tables intact. Write one sub-procedure to extract the real
SSN and keep that locked down. You can even encrypt the SSN at rest
so that no one can read it without going through your subprocedure.
We thought this was too much work for the few places we display the
SSN any more.

--buck