[HN Gopher] Security Best Practices for Fintech Application Deve...
       ___________________________________________________________________
        
       Security Best Practices for Fintech Application Development
        
       Author : ricardo_navarro
       Score  : 43 points
       Date   : 2021-10-04 18:18 UTC (4 hours ago)
        
 (HTM) web link (community.marqeta.com)
 (TXT) w3m dump (community.marqeta.com)
        
       | hn_throwaway_99 wrote:
       | 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.
        
         | sbysb wrote:
         | 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
        
         | jimt1234 wrote:
         | 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.
        
       | redact207 wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2021-10-04 23:01 UTC)