App best practice > Client Credit Information

Hey Everyone,

I'm in the process of laying out a new app for a client. They need to be able to receive customers credit information (for a credit check done manually) via the website.

So I have a few questions regarding the information.

First I know I'll want to have a secure connection to transfer this type of sensitive data. Is there a known tutorial or good read for creating a secure connection for a portion of a rails app?

The client had originally asked that the information be e-mailed to the person running the check manually. I again am worried about sensitive information being sent from the server via email. My thinking was store it the db and have the person check the web app for output on clients. Again all in a secured environment.

If the sensitive data was being stored in the db if maybe it is a good idea to flush it out after a pre-defined period of time. So the important information (sin & credit card numbers etc) aren't left behind.

What are your opinions?

Did I read you correctly in that you want to store user credit-card numbers in your database for some period of time?

-eric

Well that was the question. Whats the best way to go about this. If it's more secure to just get the information to the recipient by email then so be it. It needs to be somewhere long enough for someone to manually run the check then it can be gone. So whatever the most secure way to do that is.

brianp wrote:

Well that was the question. Whats the best way to go about this. If it's more secure to just get the information to the recipient by email then so be it. It needs to be somewhere long enough for someone to manually run the check then it can be gone. So whatever the most secure way to do that is.

E-mail would be less secure than a properly guarded DB with a secure connection, I think. But..surely you don't need a credit card number to run a credit check, do you? (I don't think I've ever been asked for mine.). If you do, then please make sure you follow the PCI security guidelines.

Best,

Hey,

I don't exactly know why the credit card is needed but they gave me a pdf version of the form they get people to fill out manually and it's on there so... I had hoped I could find api's for the services they then re-enter the information into with no luck. They said they have to take the information and submit it to 1/3 different locations on a case for case basis each requiring slightly different information.

I agree I've never had my credit card requested for a credit check, all you actually need is the sin number.

But thanks, I'll look into the PCI security guidelines and make sure to follow them thoroughly. Maybe I can get them to re-asses the form and not require it. But even the rest of the information is still pretty sensitive enough to aim for the best of security.

I'm still wondering though how to go about creating the secure connections.

As well, if I am storing this kind of sensitive data maybe it would be a good idea to have an expiry. Data will only be held for so long before it is wiped from the db?

The answers have kind of unnerved me. Is this maybe a job I should re- assess doing all together? Or as long as I follow the guidelines it should be okay?

thanks,

brian

Hey,

I don't exactly know why the credit card is needed but they gave me a pdf version of the form they get people to fill out manually and it's on there so... I had hoped I could find api's for the services they then re-enter the information into with no luck. They said they have to take the information and submit it to 1/3 different locations on a case for case basis each requiring slightly different information.

There are likely APIs for each of the credit bureaus - I just got done implementing a similar system to attach to the Lexis-Nexis background check systems. I'd love to share, but LN puts all their docs under NDA. :slight_smile:

I'm still wondering though how to go about creating the secure connections.

The best you're going to be able to manage is likely the previous suggestion - only make the information available via a secure part of the site. SSL is a good first step, but more complicated things could also be useful (two-factor auth, etc).

As well, if I am storing this kind of sensitive data maybe it would be a good idea to have an expiry. Data will only be held for so long before it is wiped from the db?

It couldn't hurt to also encrypt the relevant data in the DB, although that's still not great (you have to have the keys on the server to use the data...).

The answers have kind of unnerved me. Is this maybe a job I should re- assess doing all together? Or as long as I follow the guidelines it should be okay?

It seems like the client here doesn't have the foggiest idea about security, and that's a dangerous position for you to be in. Actually achieving PCI compliance is going to take considerable time and money; make sure that you document any corners they want you to cut, as you'll need that if (or when) they get sued for leaking customer info. It probably wouldn't hurt to have a lawyer do a quick once-over on the contract to see exactly how much liability you may have if there is a breach.

--Matt Jones

Matt Jones wrote:

Hey,

I don't exactly know why the credit card is needed but they gave me a pdf version of the form they get people to fill out manually and it's on there so... I had hoped I could find api's for the services they then re-enter the information into with no luck. They said they have to take the information and submit it to 1/3 different locations on a case for case basis each requiring slightly different information.

There are likely APIs for each of the credit bureaus - I just got done implementing a similar system to attach to the Lexis-Nexis background check systems. I'd love to share, but LN puts all their docs under NDA. :slight_smile:

That's completely irrelevant. You wouldn't be sharing LN's docs.

[...]

It seems like the client here doesn't have the foggiest idea about security, and that's a dangerous position for you to be in.

Based on the little info we have, I think I agree with that assessment.

Best,

It seems like the client here doesn't have the foggiest idea about security, and that's a dangerous position for you to be in. Actually achieving PCI compliance is going to take considerable time and money; make sure that you document any corners they want you to cut, as you'll need that if (or when) they get sued for leaking customer info. It probably wouldn't hurt to have a lawyer do a quick once-over on the contract to see exactly how much liability you may have if there is a breach.

I have to admit though as the "developer" I don't know to much about PCI compliance either. This will be my first real "sensitive data" app. So using SSL and other methods is all new to me.

Now the 12 PCI DSS Requirements seem pretty straightforward. They are planning on paying for hosting so most of that seems like the kind of thing that would be on the host side. So it sounds more like just finding the right host that follows the guidelines ?

Encrypt information in the db. have expirations for sensitive info. use SSL to transfer info and only between the client to the db and the db to the immediate person who needs to deal with the data. Track access to the information.

And better then all of that sit down with the client and re-asses the process in hope we can work with api's so the information can go straight to the checks and I won't have to deal with any of the above.

But really. If I do go ahead with this. Is there anything else I should look into. I know they don't know much and are more relying on me to have all the security information.

Thanks for everyones input. I do know my own limits with developments and if it looks like it is to beyond my ability I have no problem backing out. For both my own and my clients benefit. I just want to make sure I can get a full picture before I pull out/go ahead.

thanks, brianp