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