If you are a bank with 500 developers and unlimited time, sure, do all of these. 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. My main point is that security, and all development really, is about trade-offs. I misspoke here really - my reaction was against the stored procedures, not prepared statements, which are great and should be used whereever possible. Every other aspect of your application (notifications engine, admin portal, anything else that needs the DB) must re-implement this scheme.Īgain, it might be useful, but the ROI is questionable, IMO. 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. > You can lookup tokens by decrypting firstĪ user attempts to access your API, presenting an access token. 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'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. 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. Right, so basically block-level encryption of the actual DB data file. > At rest, means that the data on disk is encrypted if the DB itself is compromised It is absolutely possible to have excellent security without implementing any of these ideas, and I don't think they're helpful at all - and certainly not "simple". The costs of implementing these recommendations would be staggering for the questionable benefits they would provide. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries. That is an extraordinarily inefficient and costly way to develop. > Fully prevent SQL injection by only using SQL prepared statements and stored procedures So two layers of encryption!? Again, how is one supposed to look up an access token or email address if it is encrypted? And it strikes me that if you don't trust the first level of encryption, the solution is to fix that, not add another one. > Use secondary encryption for data identifying users and any sensitive data like access tokens, email addresses or billing details I'm not even sure what this is supposed to mean and it is certainly not common practise. > Encrypt all data at rest in the databaseĪLL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? While it means well, I think some of this advice is pretty bad, or at least unbalanced.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |