NYCPHP Meetup

[inforequest]

Aaron Fischer agfische-at-email.smith.edu |nyphp dev/internal group use| 
wrote:

>In my case I am thinking about encrypting (and decrypting) the user's 
>social security number....
>I'm in a shared hosting environment so I've got that working against me 
>as well.
>
>-Aaron
>  
>
In my view this is irresponsible.

1. the ss# is the defacto "personal identifying information" and 
demonstration of public trust for any legal test. There is no valid 
excuse for not protecting it.
2. the shared hosting environment is the classic "I saved money by 
consciously choosing an insecure, low-cost platform" situation. The 
combination supports a negligence action should there be a problem.

If the SS# is used as a unique identifier, choose something else or use 
an encrypted sring with the keys and ss# offline.

If the SS# is needed to cooperate with other systems, then you obviously 
have access to collaborating servers and can work together to keep the 
keys separate from the data. Yes there is a cost to that, see #1 above.

How rare is it that you don't have any other knowledge about a 
transaction at run time than the data submitted by the form? That is 
rare for environments where things like ss#'s are used. The application 
designer should use other a-priori knowledge to place the transaction 
into context, such that the ss# is not needed to be stored locally.  For 
example, if it's members only, then members who have ss#'s on file don't 
get asked their ss#. if you need to ask them, something else in your 
process needs to be fixed.

As much as I dislike the legal system, I admit that the process of 
passing-the-buck can work in the favor of the consumer sometimes. In our 
practical world risk is not to be avoided but managed. If anyone is 
requiring the ss# be stored locally, have that in writing in a form that 
supports a passing of liability away from you. You'll know it's a strong 
enough document when the project stops until the next guy finds a way to 
offload the liability to someone else. Think of ss# as a "hot potato" 
you don't want to be caught holding when the music stops.

If you find yourself assuming the liability because you need the cash, 
or are willing to assume the risk because you're the little guy, or you 
think everything is cool even though you're going against your gut 
feelin about security, consider what all the Bg Boy's already know:  in 
any deal, take a look around the room and look for the sucker. If you 
can't tell who the sucker is, it's you.


-=john andrews

-- 
-------------------------------------------------------------
"If you think this stuff is confusing, you should try optimizing websites for search engine exposure."  john andrews SEO http://www.johnon.com