4 ms·

Security Best Practices for Fintech Application Development

simonw 5y ago
People in FinTech must have realized that the design of 3D Secure is an absolute joke by now? It's an iframe, embedded in some random web page, that asks you for additional security-related information? How is that still a thing?
- tgsovlerkhgsel 5y ago
  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.
- aconbere 5y ago
  Does anyone have numbers on efficacy? Given the low interchange rates in Europe I would have guessed that despite some flaws overall reduction in fraud was effective.
- hkon 5y ago
  2FA is the norm in here now. I think it's good.
- irjustin 5y ago
  3D Secure in Asia is a 2fa system either by SMS or more ideally by in-app authorization via (silent) push notification. Didn't realize it was anything other than these 2 things?
  - simonw 5y ago
    That sounds good. Maybe the version of 3D Secure I'm talking about has been replaced by something better now?
- Nursie 5y ago
  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.
redact207 5y ago
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.
hn_throwaway_99 5y ago
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.
- jimt1234 5y ago
  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.
- sbysb 5y ago
  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
  - hn_throwaway_99 5y ago
    This article from Google explains a little more: https://cloud.google.com/sql/docs/mysql/client-side-encryption https://cloud.google.com/sql/docs/mysql/client-side-encrypti...
MattPalmer1086 5y ago
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!
rawoke083600 5y ago
One thing to add, if I may - It's super-stupid but super-common and maybe not 100% applicable here ? If you have invoices,accounts or statement pages/API's. Please make sure ONLY the real user or admin can see the data. Example: myfintech.co/accounts/?invoice=123 myfintech.co/accounts/statement/?user=456 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

People in FinTech must have realized that the design of 3D Secure is an absolute joke by now? It's an iframe, embedded in some random web page, that asks you for additional security-related information? How is that still a thing?

tgsovlerkhgsel 5y ago
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.
aconbere 5y ago
Does anyone have numbers on efficacy? Given the low interchange rates in Europe I would have guessed that despite some flaws overall reduction in fraud was effective.
hkon 5y ago
2FA is the norm in here now. I think it's good.
irjustin 5y ago
3D Secure in Asia is a 2fa system either by SMS or more ideally by in-app authorization via (silent) push notification. Didn't realize it was anything other than these 2 things?
- simonw 5y ago
  That sounds good. Maybe the version of 3D Secure I'm talking about has been replaced by something better now?
Nursie 5y ago
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.

redact207 5y ago

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.

hn_throwaway_99 5y ago

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.

jimt1234 5y ago
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.
sbysb 5y ago
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
- hn_throwaway_99 5y ago
  This article from Google explains a little more: https://cloud.google.com/sql/docs/mysql/client-side-encryption https://cloud.google.com/sql/docs/mysql/client-side-encrypti...

MattPalmer1086 5y ago

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!

rawoke083600 5y ago

One thing to add, if I may - It's super-stupid but super-common and maybe not 100% applicable here ? If you have invoices,accounts or statement pages/API's. Please make sure ONLY the real user or admin can see the data. Example: myfintech.co/accounts/?invoice=123 myfintech.co/accounts/statement/?user=456 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