3 ms·

The cost of full encryption is minimal on platforms like AWS Aurora. If the platform supports it - this is a good way to go. The incremental cost of encryption

The cost of full encryption is minimal on platforms like AWS Aurora. If the platform supports it - this is a good way to go. The incremental cost of encryption with Aurora is very low (< 3%). At rest, means that the data on disk is encrypted if the DB itself is compromised. The 2nd layer is if the server-app is compromised. In this case, the data has already been decrypted by AWS. The 2nd layer means that credentials, emails etc are safe in the server-app tier. You can lookup tokens by decrypting first. I'm not sure I'm understanding your question properly. Regarding prepared statements, the mysql2 node driver is equivalent to the non-prepared driver in speed and infinitely safer. I agree you don't necessarily have to do all these things, but at least think about them. We do all these items in our software and have not found it onerous. Happy to provide more details about this if you would like.

sho 9y ago
> At rest, means that the data on disk is encrypted if the DB itself is compromised Right, so basically block-level encryption of the actual DB data file. While this would be much easier than encrypting the record data at the row level, it only protects against literal copying of the data file, which in my experience is not a common threat vector. You're right though, it is simple enough to do this with something like aurora - although outside of AWS it may be very troublesome, with possible performance ramifications. I guess my point is that this article is presented as a basic checklist for all web apps, with insufficient consideration of the ROI for implementing these solutions. > You can lookup tokens by decrypting first A user attempts to access your API, presenting an access token. How do you query your DB for that access token if all your tokens are encrypted at the row level? You could encrypt it at the app level and search for the cyphertext, sure, but now your server needs to have the secret, and it needs to be global, seemingly removing the point. Every other aspect of your application (notifications engine, admin portal, anything else that needs the DB) must re-implement this scheme. Again, it might be useful, but the ROI is questionable, IMO. > Regarding prepared statements I misspoke here really - my reaction was against the stored procedures, not prepared statements, which are great and should be used whereever possible. My main point is that security, and all development really, is about trade-offs. The options here are presented without due consideration of the benefits and costs of the tradeoffs they represent - and they article doesn't ask you to just "think" about them, it's a checklist. If you are a bank with 500 developers and unlimited time, sure, do all of these. If you're a startup - questionable at best.
- aeronautic 9y ago
  Good point. I did say: "This checklist is simple, and by no means complete. It is a list of some of the more important issues you should consider when creating a web application." But I'll try to make that clearer. I'm limited by space and peoples attention span. Having links to implementation notes will address your concern I think.
  - sho 9y ago
    > I'm limited by space and peoples attention span Might I suggest a simple "tag" for each suggestion indicating the appropriate market for that point. Eg good - your basic SAAS/casual web app. Great - apps dealing with moderately sensitive data. Extreme - you're building a bank, seeking PCI compliance, storing medical data, etc. You could break it out at the top, and then it doesn't take much space in the body of the post, but still provides some context for which projects should be adopting this level of paranoia?
    - wapz 9y ago
      A tag like this would be a great idea. I'm playing around with a very basic casual web app that will have no sensitive data besides a hashed username/password. If someone wants to hack the database and give themselves nearly unlimited in a game with no leaderboards and share it with their friends I could care less (I'd actually be happy because that means someone actually cares about the app). I'll be using a BaaS to store data so I don't think I have to worry about things like sql injection but I have no experience with web work so correct me if I'm wrong.
- LanceH 9y ago
  Having a system encrypted at rest is a huge reduction in legal liability under HIPAA. It may be similar in other industries. On the other hand I might not care if someone stole my recipe collection.

sho 9y ago

> At rest, means that the data on disk is encrypted if the DB itself is compromised Right, so basically block-level encryption of the actual DB data file. While this would be much easier than encrypting the record data at the row level, it only protects against literal copying of the data file, which in my experience is not a common threat vector. You're right though, it is simple enough to do this with something like aurora - although outside of AWS it may be very troublesome, with possible performance ramifications. I guess my point is that this article is presented as a basic checklist for all web apps, with insufficient consideration of the ROI for implementing these solutions. > You can lookup tokens by decrypting first A user attempts to access your API, presenting an access token. How do you query your DB for that access token if all your tokens are encrypted at the row level? You could encrypt it at the app level and search for the cyphertext, sure, but now your server needs to have the secret, and it needs to be global, seemingly removing the point. Every other aspect of your application (notifications engine, admin portal, anything else that needs the DB) must re-implement this scheme. Again, it might be useful, but the ROI is questionable, IMO. > Regarding prepared statements I misspoke here really - my reaction was against the stored procedures, not prepared statements, which are great and should be used whereever possible. My main point is that security, and all development really, is about trade-offs. The options here are presented without due consideration of the benefits and costs of the tradeoffs they represent - and they article doesn't ask you to just "think" about them, it's a checklist. If you are a bank with 500 developers and unlimited time, sure, do all of these. If you're a startup - questionable at best.

aeronautic 9y ago
Good point. I did say: "This checklist is simple, and by no means complete. It is a list of some of the more important issues you should consider when creating a web application." But I'll try to make that clearer. I'm limited by space and peoples attention span. Having links to implementation notes will address your concern I think.
- sho 9y ago
  > I'm limited by space and peoples attention span Might I suggest a simple "tag" for each suggestion indicating the appropriate market for that point. Eg good - your basic SAAS/casual web app. Great - apps dealing with moderately sensitive data. Extreme - you're building a bank, seeking PCI compliance, storing medical data, etc. You could break it out at the top, and then it doesn't take much space in the body of the post, but still provides some context for which projects should be adopting this level of paranoia?
  - wapz 9y ago
    A tag like this would be a great idea. I'm playing around with a very basic casual web app that will have no sensitive data besides a hashed username/password. If someone wants to hack the database and give themselves nearly unlimited in a game with no leaderboards and share it with their friends I could care less (I'd actually be happy because that means someone actually cares about the app). I'll be using a BaaS to store data so I don't think I have to worry about things like sql injection but I have no experience with web work so correct me if I'm wrong.
LanceH 9y ago
Having a system encrypted at rest is a huge reduction in legal liability under HIPAA. It may be similar in other industries. On the other hand I might not care if someone stole my recipe collection.