NYCPHP Meetup

[Aaron Fischer]

I'm not sure if my description of shared hosting environment is accurate.

I am with one department at a college.  There are a number of 
departments who use the same web server.  The IT department maintains 
the server and assigns permissions and directory access to the various 
departments.  It is in that sense that I am in a shared environment.

The SS# is not being used as a unique identifier.  It is part of the 
information that a student can choose to fill in when they are applying 
for admission to the college.  (It is not a required field.)

Not sure what the sring is or how to keep the key offline, but those are 
the types of issues I want to be researching.  The encryption part of 
the application development won't start until at least next week.

-Aaron


inforequest wrote:
> 
> 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.
> 
 > 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
 >>
 >>



> 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
> 


-- 
Aaron Fischer
Web & Systems Specialist

Smith College
Office of Admission
http://www.smith.edu/admission