User puts in their card number, which is then passed to a payment processor. The processor sends back a response of invalid card, or a token unique to that card for the specific vendor. The vendor then stores the token and last 4 digits, and sometimes the card type. Another layer of security can be added by requiring the CCV at every checkout as well. After the first transaction, the vendor sends their ID token, the card token, and optionally the CCV and the processor checks everything again and sends back pass/fail.
The Big Programming Thread - Page 968
Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
tofucake
Hyrule18714 Posts
User puts in their card number, which is then passed to a payment processor. The processor sends back a response of invalid card, or a token unique to that card for the specific vendor. The vendor then stores the token and last 4 digits, and sometimes the card type. Another layer of security can be added by requiring the CCV at every checkout as well. After the first transaction, the vendor sends their ID token, the card token, and optionally the CCV and the processor checks everything again and sends back pass/fail. | ||
Acrofales
Spain17158 Posts
On July 04 2018 04:34 WolfintheSheep wrote: I'd still recommend PCI standards for theoretical information. Encryption key storage is included in the requirements, but yes, ultimately no system is every going to be completely secure. Security is always risk minimization, not risk prevention. That's why a 3rd party credit card vault (which I think is the industry term) is a lot more secure than storing the data yourself. That doesn't really help Excludos understand how you'd go about implementing that credit card vault, tho. My bet is that you'd do it very similarly to a shadow file for passwords. | ||
Excludos
Norway7667 Posts
On July 04 2018 06:01 tofucake wrote: credit card storage isn't done User puts in their card number, which is then passed to a payment processor. The processor sends back a response of invalid card, or a token unique to that card for the specific vendor. The vendor then stores the token and last 4 digits, and sometimes the card type. Another layer of security can be added by requiring the CCV at every checkout as well. After the first transaction, the vendor sends their ID token, the card token, and optionally the CCV and the processor checks everything again and sends back pass/fail. Interesting. That helps a bit. However does it really change that much seeing as both the id token and card token could still be stolen and used? Or is there something which restricts where the id token and card token is used from perhaps? CCV is an obvious and good security layer, however I've seen many sites forego it completely (Which, when you're running an automatic renewable subscription service you'd have to do anyways). | ||
Excludos
Norway7667 Posts
On July 04 2018 06:05 Acrofales wrote: That doesn't really help Excludos understand how you'd go about implementing that credit card vault, tho. My bet is that you'd do it very similarly to a shadow file for passwords. A shadow file isn't really secure, even if encrypted, as anyone with admin access can read it. Something as critical as this is only really ever secure if even admins doesn't have access or the ability to get their hands on the the stored information except for encrypted mumbo jumbo. Hacks happens regularly, and even worse insiders happen regularly. If you're thinking about information + salt = hash, that only works if you never intend to decrypt it, as you can then just check hashes against other hashes, and never against the original information itself. | ||
Acrofales
Spain17158 Posts
On July 04 2018 06:20 Excludos wrote: A shadow file isn't really secure, even if encrypted, as anyone with admin access can read it. Something as critical as this is only really ever secure if even admins doesn't have access or the ability to get their hands on the the stored information except for encrypted mumbo jumbo. Hacks happens regularly, and even worse insiders happen regularly. Well, no. The whole point is that you don't store the password. Just a hash of it. So yeah, you only check the encrypted mumbo jumbo matches. | ||
WolfintheSheep
Canada14127 Posts
On July 04 2018 06:01 tofucake wrote: credit card storage isn't done User puts in their card number, which is then passed to a payment processor. The processor sends back a response of invalid card, or a token unique to that card for the specific vendor. The vendor then stores the token and last 4 digits, and sometimes the card type. Another layer of security can be added by requiring the CCV at every checkout as well. After the first transaction, the vendor sends their ID token, the card token, and optionally the CCV and the processor checks everything again and sends back pass/fail. The "ID token" and "card token" you're referring to is the 3rd party vault I mentioned, and it's not a fully adopted model. Local Credit Card Storage is definitely done, especially since companies are not constantly updating with standards...and the credit card vault isn't even a required standard. On July 04 2018 06:16 Excludos wrote: Interesting. That helps a bit. However does it really change that much seeing as both the id token and card token could still be stolen and used? Or is there something which restricts where the id token and card token is used from perhaps? CCV is an obvious and good security layer, however I've seen many sites forego it completely (Which, when you're running an automatic renewable subscription service you'd have to do anyways). The ID token and Card token should be tied to your personal business/merchant ID as well. In that regard, it's essentially a public/private key. In theory, hacking your local storage would only given card tokens that can't be used anywhere else, and the same goes for hacking the centralized card vault. CVV, in my experience, tends to be used a lot more during credit disputes than initial transactions. Which is why, as you say, it's ignored quite often. | ||
Manit0u
Poland17031 Posts
| ||
phar
United States1080 Posts
| ||
Excludos
Norway7667 Posts
On July 05 2018 07:24 phar wrote: Oh joy, with luck I'll be able to use Java 9 features in 2025 at my company lol At least you're not using Unity which is consistently 2 years behind the latest C# version, which takes my company another 1-2 years to switch over to. | ||
Silvanel
Poland4597 Posts
| ||
Acrofales
Spain17158 Posts
On July 06 2018 18:15 Silvanel wrote: Well i dont know much about java but i saw that our company is just starting new project using JAVA 8. Is it significantly behind ? It's the current LTS version, so in that sense no. However, we're up to Java 10, and as that article above states, Java 11 will be the next LTS and is about to be released. That said, the only really big change between 8 and 11 is the different GC. The Optional statements, and "soft" typing (it's still hard types, just giving the compiler some work) aren't that big a deal, imho. | ||
Manit0u
Poland17031 Posts
Here's a nice explanation of new Java release cycle: https://jaxenter.com/end-life-comes-early-jdk-8-140824.html This picture shows it nicely Note that lines in red mean support and updates will be available only if you start paying Oracle money. | ||
Manit0u
Poland17031 Posts
| ||
JWD[9]
364 Posts
so i try to merge dictionaries {string->dictionary{string->none} } in python And it works...well kinda
the shell output:
Is it because the nested dictionaries are never copied? and the top level dictionaries refer to the same nested ones? | ||
Deckard.666
152 Posts
This is an in-place operation that returns None. What you want is simply
without the assignment.
This is only making a shallow copy. What you need is a deep copy:
This way d will be unmodified by the function merge_dicts. | ||
Manit0u
Poland17031 Posts
+ Show Spoiler [TL:DR] +
| ||
JWD[9]
364 Posts
Manit0u, that looks fancy but is not the exact problem. I don't want to overwrite the values in a with b, i want to combine them. | ||
Manit0u
Poland17031 Posts
On July 12 2018 04:00 JWD[9] wrote: Wee, thank you Deckard.666. Manit0u, that looks fancy but is not the exact problem. I don't want to overwrite the values in a with b, i want to combine them. Define "combine". That's how usually merge works in various languages. If you don't want to overwrite a with b just do a reverse merge (just swap the params) and you will get all the unique keys from both dicts and preserve original values. | ||
Deleted User 3420
24492 Posts
its soooooo slow manitou, that syntax makes me want to update to python 3.5... anyways I just avoid using nested dicts. but if I did, I would be using defaultdicts | ||
Silvanel
Poland4597 Posts
Also to other people dont forget about some more specialized python datatypes, they are super usefull sometimes: https://docs.python.org/3/library/collections.html | ||
| ||