This is a good list, but I find that people are often confused about this requirement:
> Similar to encryption in transit, practicing data encryption at rest—using standards like AES-256—will ensure that stored data is not accessible to any application or user unless they present the decryption key.
A lot of people seem to have the attitude "Oh, my DB is in Amazon RDS, and they say everything is encrypted, so I'm good". However, if your DB creds get hacked, they can still read all the info in your DB.
What should really be required is a tokenization or app-side encryption scheme, ideally using something like AWS or GCP KMS so that all decryption requests are logged and monitored, for any even remotely sensitive data that is saved to the DB. That can also make it much easier for developers, because it's safe to give out read-only user access if you're sure they can't read any sensitive private data.
Assuming that your sensitive data is a key part of your product offering (and if it isn't you shouldn't be storing it imo) - wouldn't logging all decryption requests just generate a lot of noise during the day-to-day operation of your application? I struggle to see a scenario where what you described actually increases the real-world security of your data, beyond allowing you to do a more in depth retrospective of who took what data (which can be achieved without the overhead of double encryption).
In the event that some DB creds get leaked or brute forced or however, to the application/DB those creds will look just as legit and any irregularities would only be discovered at best while the data is being taken
I think your latter pattern is referred to as “envelope encryption” or “data key encryption.” This allows you to store ciphertext and decrypt on demand. Bonus points is using a different datakey per customer/logical container/etc while still using one (or more) KMS keys. An example https://encryption-ws.workshop.aws/keymanagement-kms/envelop...
Fine if your sensitive data are infrequently needed in the clear--credit card numbers and the like--but probably not realistic if the sensitive data are part of regular operation. I'll also note that the risk hasn't changed all that much; a compromise of the app server/decryption oracle/etc. having access to the key material is roughly as severe as a compromise of the app server having credentials and network access to the database.
Not just your creds getting 'hacked', but also to secure your data against a court order. AWS can be compelled by a 3-letter government agency to turn over your data without even telling you. Encrypt it. Own your own keys.
Decent list and a nice way to educate whilst pitching your product.
A lot of these points are applicable outside of Fintech. If you have any type of data that if leaked could ruin your business then it's worth a look over.
It also tends to present a piece of info to identify itself, so that you know it's not just something utterly random.
It's been superseded in a bunch of ways, but it cut down on fraud, so it has been useful.
That's the only metric the payment network participants really care about. Perfection would be great, but as long s there are results, they're good with it.
I've seen 3D Secure implemented almost exclusively using apps nowadays, i.e. you need to confirm the transaction in your bank app. The iframe doesn't matter.
The old implementation with the iframe was bonkers, just teaching people to enter their banking credentials on random sites. I hope it bit them in court if they ever tried to blame customers for getting phished.
I've seen this COUNTLESS of times with big and small companies.
It's my favorite thing to do when signing up for a new service. See if I can wiggle-waggle the account-statements.
Like I said, it's a really simple thing, and maybe most of HN readers are "above these sort of errors", but I see a few times a year, with just the services I use.
Also a good little tip(again might be preaching to the wrong crowd) is to use some form of non-deterministic ID-schemes for accounts,statements and of course user-ids.
UUID's are great for this, If for some reason you do have a gap in you system and your id's are deterministic, the bad-actor can just enumerate ALL accounts and users.
Sorry if I'm insulting the "average HN reader" with this "simple and obvious mistakes", but I like I said, I see this A LOT. YMMV
This isn't a set of security best practices. Many are simply required by PCI-DSS, along with a whole bunch of other things if you're doing card payments.
Some of them do offer security benefits (e.g. tokenization) but are often considered more because they reduce cardholder data within your network, which can make things a lot cheaper. A rare example of economic and security factors aligning!
> Similar to encryption in transit, practicing data encryption at rest—using standards like AES-256—will ensure that stored data is not accessible to any application or user unless they present the decryption key.
A lot of people seem to have the attitude "Oh, my DB is in Amazon RDS, and they say everything is encrypted, so I'm good". However, if your DB creds get hacked, they can still read all the info in your DB.
What should really be required is a tokenization or app-side encryption scheme, ideally using something like AWS or GCP KMS so that all decryption requests are logged and monitored, for any even remotely sensitive data that is saved to the DB. That can also make it much easier for developers, because it's safe to give out read-only user access if you're sure they can't read any sensitive private data.