Credit card storage

[Danilo Tuler]

Hi,

I'm not a security expert, but I've been studying how to safely store credit cards.

I wonder if Vault has been used for this.

Thanks,

Danilo

[Armon Dadgar]

Hey Danilo,

This is exactly the kind of thing Vault is designed for. We just published a blog on how

we manage PII data in our Atlas product here:

https://hashicorp.com/blog/how-atlas-uses-vault-for-managing-secrets.html

Specifically, the “transit” backend in Vault is used for this:

https://vaultproject.io/docs/secrets/transit/index.html

Hope that helps!

Best Regards,

Armon Dadgar

--
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To post to this group, send email to vault...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/19636287-15c6-4f7a-9252-dbe3d0f2be18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Seth Vargo]

+1 to what Armon said.

However, one of the first rules of storing PII is asking yourself the question "do I need to store this information". The most secure information is information you do not have :). 

Credit card processing companies such as Stripe allow you to specify a customer ID and setup recurring payments (as examples) instead of storing the raw credit card information on your servers.

Best,

Seth

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/etPan.556c3575.2ae8944a.1159f%40Armons-MacBook-Air-2.local.

[Michael Fischer]

It would be a very good idea, practically speaking, to consult with
your local PCI compliance expert before using Vault to store CC data.

--Michael

> https://groups.google.com/d/msgid/vault-tool/etPan.556c805b.6b2d44a5.1a1%40Bacon.

[Danilo Tuler]

Unfortunately I do have to store CC data, even if I'm using a payment gateway (which BTW does offer a vault). The reasons are out of scope here.

So this is the basic idea using the transit backend:

Each customer would have its own named key, created (written) by the application, but read by no one (only vault itself).

CC's get encrypted using the customer key, and stored in the application database (I use MongoDB).

Questions:

1) what is the advantage of using a transit backend instead of a generic one? I understand that the storage is outside vault's security barrier, and it's my responsibility to keep it safe. But having a totally separate database for secrets seems like a wiser solution.

2) by using a generic backend, how could I have a different encryption key for each customer?

3) is there any design document about key rolling? Will this be a responsibility of the client or built-in vault?

Thanks,

Danilo

[Armon Dadgar]

Hey Danilo,

With the transit backend, you would not make a new key for every customer. Instead you would have

a single named key like “credit-card” that is used for every row. Otherwise, you are correct, the Vault itself

sees the encryption key, and the database only sees the cipher text.

For the other questions, the transit backend supports the cryptographic operations that you need.

The generic backend only stores and retrieves values, but it is not suitable for storing a large key set.

The transit backend stores only the encryption keys themselves, and performs the cryptographic operations

using them, but allows the storage to be offloaded to an external database.

Vault 0.1 does not support key rolling, but we’ve merged in support for it in master and it will be

available in Vault 0.2. Vault has unseal keys that can be “rekeyed” to change, and backend encryption

keys which can be rotated.

The transit backend itself will eventually support key rolling, so that there can be multiple versions

of the “credit-card” named key. Additionally, we are going to support derived keys, so that you can

have a unique per-transaction key.