Timeline for Hashing a credit card number for use as a fingerprint
Current License: CC BY-SA 3.0
44 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 17, 2021 at 10:34 | history | protected | CommunityBot | ||
| Mar 27, 2020 at 23:12 | answer | added | KurtWegner | timeline score: 1 | |
| S Mar 3, 2015 at 10:33 | history | suggested | kalina | CC BY-SA 3.0 |
cleaning up
|
| Mar 3, 2015 at 10:10 | review | Suggested edits | |||
| S Mar 3, 2015 at 10:33 | |||||
| Jul 18, 2014 at 13:21 | comment | added | Xander | @staticx If Stripe's server is down and you're using them for your merchant services, you can't process cards/transactions anyway, so it's irrelevant if you happen to depend on them for this function as well. | |
| Jul 18, 2014 at 13:16 | history | edited | FloatingRock | CC BY-SA 3.0 |
deleted 1 character in body
|
| Jul 18, 2014 at 12:57 | comment | added | Neil Slater | I have used Hash( fixed_salt_or_pepper + PAN ) to index blacklisted cards, and that passed PCI audit (and FISMA I believe). However, we did not use that mechanism to store customer's usable cards. | |
| Jul 18, 2014 at 9:48 | history | edited | FloatingRock | CC BY-SA 3.0 |
added 109 characters in body
|
| Jul 17, 2014 at 18:35 | history | edited | FloatingRock | CC BY-SA 3.0 |
added 56 characters in body
|
| Jul 17, 2014 at 18:13 | answer | added | Andrew Hoffman | timeline score: 0 | |
| Jul 17, 2014 at 16:52 | vote | accept | FloatingRock | ||
| Jul 17, 2014 at 16:43 | vote | accept | FloatingRock | ||
| Jul 17, 2014 at 16:48 | |||||
| Jul 17, 2014 at 14:08 | answer | added | John Downey | timeline score: 34 | |
| Jul 17, 2014 at 13:38 | answer | added | Damon | timeline score: 4 | |
| Jul 17, 2014 at 11:33 | comment | added | Engineer2021 | In your last edit, just because somebody does it, does not mean tomorrow it will be frowned upon. Plus, what if the Stripe server is down? Do you really want to be tied to that service? | |
| Jul 17, 2014 at 10:19 | history | edited | FloatingRock | CC BY-SA 3.0 |
added 71 characters in body
|
| Jul 17, 2014 at 10:02 | history | edited | FloatingRock | CC BY-SA 3.0 |
added 107 characters in body
|
| Jul 17, 2014 at 9:57 | comment | added | FloatingRock | @NateKerkhofs it's so that the customer (the consumer of the API) can decide on what to do in each scenario. If you want to group customers that use the same CC, you'd need some sort of fingerprint to identify the token -- which is what Stripe provides. You could do whatever you like with that fingerprint. | |
| Jul 17, 2014 at 9:47 | comment | added | Nzall | not quite related to security, but is your goal to make it so that 2 customers cannot use the same CC? I can quickly imagine a few situations where 2 separate accounts use the same CC: a father and son that both play videogames, and the father uses his CC to pay for the son's games on his own account; a married couple that have separate Amazon accounts to keep their kindle collections apart, but use one creditcard for both purchases; A company that needs multiple separate Office365 organizations, but pays for them with the company credit card. avoid making stuff unique that might not be that. | |
| Jul 17, 2014 at 8:51 | history | edited | FloatingRock | CC BY-SA 3.0 |
added 11 characters in body
|
| Jul 17, 2014 at 8:45 | history | edited | FloatingRock | CC BY-SA 3.0 |
added 482 characters in body
|
| Jul 17, 2014 at 0:31 | answer | added | John Deters | timeline score: 9 | |
| Jul 16, 2014 at 21:02 | history | tweeted | twitter.com/#!/StackSecurity/status/489515470060412928 | ||
| Jul 16, 2014 at 19:17 | vote | accept | FloatingRock | ||
| Jul 17, 2014 at 16:43 | |||||
| Jul 16, 2014 at 19:06 | answer | added | Xander | timeline score: 31 | |
| Jul 16, 2014 at 18:39 | comment | added | Engineer2021 | So how is trunk encrypted and how is the card encrypted inside the trunk? | |
| Jul 16, 2014 at 18:35 | history | edited | FloatingRock | CC BY-SA 3.0 |
added 672 characters in body
|
| Jul 16, 2014 at 18:32 | comment | added | FloatingRock |
@staticx so to give this some context, see the Stripe API docs and search for fingerprint. It's the same concept. The credit card information will be stored on a secure machine that's not accessible by the customer (API consumer), but the fingerprint is returned in order to allow them to make comparisons.
|
|
| Jul 16, 2014 at 18:28 | comment | added | Engineer2021 | @Xander: I prefer a one way token personally. | |
| Jul 16, 2014 at 18:24 | comment | added | Xander | @staticx It's kind of a cheesy term I know, but since by definition a salt needs to be globally unique, a value that's used more than once doesn't qualify. | |
| Jul 16, 2014 at 18:19 | comment | added | Engineer2021 | @Xander: Interesting, never heard that term before. I passed a PCI audit using a salt, I mean pepper, about 2-3 years ago. | |
| Jul 16, 2014 at 18:18 | comment | added | Xander | @staticx That isn't a salt, it's a pepper, and it isn't particularly valuable from a security perspective when trying to prevent hash-cracking, as you still only need to compute a single set of hashes to recover all values. | |
| Jul 16, 2014 at 18:16 | comment | added | Engineer2021 | @Xander: Reuse the same salt. The salt is normally stored unencrypted. For comparison purposes anyways, just retrieve it and rehash using the same salt, check if they match. That being said, I wouldn't store any credit card number. | |
| Jul 16, 2014 at 18:10 | answer | added | Engineer2021 | timeline score: 0 | |
| Jul 16, 2014 at 17:50 | comment | added | Andrew Hoffman | Redirect them to paypal? | |
| Jul 16, 2014 at 17:19 | comment | added | Xander | I tend to agree with u2707's answer and if you can't safely store the credit card numbers, I don't think it's reasonable to store hashes either. I can't suggest doing this to your customers. | |
| Jul 16, 2014 at 17:07 | comment | added | FloatingRock | @Xander Thanks for the clarification. Ok, no salt then. Which hash would you suggest? | |
| Jul 16, 2014 at 16:40 | comment | added | Xander | So salt + hash won't work, because salts are unique. So, two identical card numbers, once salted, will produce different hashes, and you will not be able to determine that the card number matches a pre-existing salted hash of the same card number, since the salts will be different. | |
| Jul 16, 2014 at 16:20 | history | edited | FloatingRock | CC BY-SA 3.0 |
added 267 characters in body
|
| Jul 16, 2014 at 16:15 | history | edited | FloatingRock | CC BY-SA 3.0 |
added 267 characters in body
|
| Jul 16, 2014 at 16:04 | answer | added | u2702 | timeline score: 16 | |
| Jul 16, 2014 at 15:37 | comment | added | Andrew Hoffman | Cause if you want to protect it from bruteforce guessing like you would a password, then you'd need to treat it like a password, except with CC numbers instead. CC hash and salt associated with that user. A good slow hash with stretching, secure comparison, etc. | |
| Jul 16, 2014 at 15:33 | comment | added | Andrew Hoffman | Are you going to be checking them sort of like a password, or will you need to be able to query? Salting would straight up break the ability to query. | |
| Jul 16, 2014 at 15:23 | history | asked | FloatingRock | CC BY-SA 3.0 |