Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

collecting sensitive data

by casimo (Sexton)
on Jul 16, 2009 at 23:12 UTC ( [id://780880]=perlquestion: print w/replies, xml ) Need Help??

casimo has asked for the wisdom of the Perl Monks concerning the following question:

I have a client that is starting a loan website. They need to collect applicant's bank account data and social security. On the site there will be a form to submit this data which the client needs access to.

What is the most secure way of getting this data to the client?

I have concerns because I've never collected/stored sensitive data like this and want to make sure I have my bases covered.

Replies are listed 'Best First'.
Re: collecting sensitive data
by Your Mother (Archbishop) on Jul 16, 2009 at 23:49 UTC

    I'm the wet blanket of despair... It's very good that you're asking. It's kinda bad that you're trying. There are many ways to mess this stuff up and doing it for a real live social-security/bank-account site the first time out of the gate is what I would call a really bad idea. Here is a partial list of concerns and ideas-

    • All requests with sensitive information (including sign-in) must be under HTTPS configured and set up on a guaranteed host; cookies must never contain customer information.
      • Cookies should be secure and httponly.
    • Taint all input. Escape all output.
    • Encrypt/salt passwords so they can't be discovered, reversed, or found in a lookup table.
    • Encrypt the stored financial and personal data. Keep the keys in a separate location; i.e., not the database.
    • Limit all access to all resources to the smallest possible permissions/connectivity needed to run.
    • Run everything as an untrusted user so you can't make dangerous mistakes.
    • Bone up on PCI compliance. Follow it.
    • Read OWASP. Take it all seriously.
    • Raise the bid on your contract, or eat the cost, to hire someone who has done all this several times to audit the project when you're close to a production release.

    Good luck and stay scared. It makes more secure apps.

    Update: changed PCI link to the one grep provided; it's better. Update:update: removed a redundant/awkward sentence.

    Update: added OWASP and HttpOnly notes.

      Are there frameworks/platforms that might make the attempt less "bad"?

      I agree with the advice to engage someone experienced but I suggest you do it from the start rather than when you are close to production. I have seen several projects / development companies commit suicide by leaving security problems to be discovered near the end of development, shortly after I engaged to bring the applications into our production environment at which time we required rigorous security reviews.

      Thanks for the replies.

      I have convinced the client to not store any of the sensitive data online...however, they do need to collect this information from the site somehow.

      Any thoughts on how to simplify things? Perhaps encrypting the sensitive data and emailing it to the client? (maybe breaking the data into two emails?)

      I know PCI issues will still exist (for the client), but I want to make sure that my link in the chain is secure.

        Email can be made secure but I believe it is probably more difficult than doing it in a limited access DB with a site under SSL/HTTPS. Plus it initiates a situation where an end user can accidentally broadcast sensitive data with a careless forward/CC or an Outlook virus or whatever. I'd say steer completely away from email and encourage your customer(s) to think the same. Consider any bank or serious online store you've ever visited. There is not one that would send any of this stuff that way.

        I don't mean to be discouraging either. I think it's possible to do this right. Just be very careful and please seek a project review as grep and I suggested before you flip anything live. You could theoretically do something like a hacker prize too. Offer $250-500(?) to anyone who can get a dummy account -- and explain how s/he did it -- out of a test deployment of your code.

        I endorse the amendment ig gives below: an earlier review is a better idea. As for frameworks: none I know but I'll bet there are some options. I've worked within an established codebase taking cards and SSNs (and it was chillingly insecure). I never had to do one from scratch and even after a decade of CGI/web-apps I'd still be nervous, extremely cautious, and thorough.

Re: collecting sensitive data
by grep (Monsignor) on Jul 16, 2009 at 23:48 UTC
    You're getting into a big deal, but I'm guessing you already know that. For a standard you may want to start with, look at the PA-DSS. This is the Payment Card Industry's (PCI) standard for applications. It talks about handling sensitive credit card data and I think will provide you with a good basis.

    But the best advice is never store sensitive data longer than you need to. As soon as you can get rid of it - do it.

    Also have someone knowledgeable with secure handling of data review your design and your final implementation. Even if you feel comfortable with securely handling sensitive data, it's always better to get a second opinion.

    grep
    One dead unjugged rabbit fish later...
Re: collecting sensitive data
by CountZero (Bishop) on Jul 17, 2009 at 10:03 UTC
    What is the most secure way of getting this data to the client?
    If you are asking for the transport layer: it is HTTPS, do not even think of doing it in any other way (email, various encodings, home-made encryption, ...)

    But that is only a (small) part of your whole can of worms: once the data is with the client, the *real* problems begin. If you let them, the data will end up in the clear on a lap-top with the master-pasword on a Post-It tacked to the screen and the laptop on the backseat of an open-topped car in the parking lot of the local mall.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: collecting sensitive data
by jrsimmon (Hermit) on Jul 17, 2009 at 01:01 UTC
    Reading through this would at least be a start. I'd like to echo the concerns listed above though -- you really ought to think twice about this. I work in the retail industry and PCI requirements are both complex and, at times, convoluted. Your very first step should be talking with legal counsel...and perhaps some psychological help while you're at it.
Re: collecting sensitive data
by goibhniu (Hermit) on Jul 17, 2009 at 13:51 UTC

    I'm going to join others that have not directly answered your "how to get sensistive data to the client" question and add another general resource. For that I apologize, but hope this helps.

    OWASP is an organization with general info on writing secure web applications. It's fairly java-centric, but all the principles apply well enough. In particular, look at their Top Ten list of web application security flaws. Remember that the whole application has to be secure, not just the part that has to do with sensitive data.


    #my sig used to say 'I humbly seek wisdom. '. Now it says:
    use strict;
    use warnings;
    I humbly seek wisdom.
Re: collecting sensitive data
by JavaFan (Canon) on Jul 17, 2009 at 14:38 UTC
    I noticed that HTTPS was mentioned by a few people. Note that HTTPS only offers a start. It's far from sufficient when it comes to the transportation. HTTPS it itself make the channel "secure" (as in, 'it takes a while to decrypt'). It doesn't authenticate either end of the channel; just the fact that I talk to you over HTTPS doesn't mean I'm entitled to your data, nor does it mean I am who I say I am.

    Basically, when two parties communicate, you want to:

    • Encrypt you channel. Noone should be able to read what was send by inspecting the wire.
    • Authenticate both parties. You shouldn't send data to someone who isn't your client, and your client shouldn't accept data from someone else. No man in the middle attacks.
    • Authorize the parties. A test server from the client may be authenticated, but it's not entitled to the production data.
    • Audit trail the communication. Who logged in when. What was asked for. What was send.
Re: collecting sensitive data
by JavaFan (Canon) on Jul 17, 2009 at 14:17 UTC
    I have a client that is starting a loan website. They need to collect applicant's bank account data and social security. On the site there will be a form to submit this data which the client needs access to.

    What is the most secure way of getting this data to the client?

    Don't ask us. Ask whatever government agency is responsible for that in your country. What you are doing has in many countries heavily regulated minimum requirements regarding privacy, encryption and auditability and such. Or rather, have your client ask what requirements you need to implement.

    Do realize that there usually heavy penalties (ranging from fines, loss of license to prison time) from not following the legal requirements.

Re: collecting sensitive data
by BrowserUk (Patriarch) on Jul 17, 2009 at 15:38 UTC

    This is more a question than a statement, but this is definitely one of those wheels that shouldn't be reinvented.

    Aren't there well-known, trusted, & secure people (sites) that you can hand your customer over to, that will deal with the sensitive details of CC transactions?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: collecting sensitive data
by graceoflarkspur (Acolyte) on Jul 17, 2009 at 23:01 UTC
    Just an aside, and this might sound obvious -- but I'd also be damn sure to get another party to specifically do penetration testing for web exploits on the test server's data. (Of course, I guess it might also sound stupid for some reason...)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://780880]
Approved by AnomalousMonk
Front-paged by hangon
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (6)
As of 2024-03-28 14:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found