jueves, 3 de mayo de 2018

Never hard code Connection strings

A common practice during development is to just hard code every connection string that is been used on the project, but why is this a bad, and I mean a really bad practice?

Let's see what outputs the C# compiler for hard-coded strings:


As we can see, the line marked as IL_0001 is where the sintrg is been loaded to a variable, it is just written there, with out any consideration, imagine if someone gets access to your binaries, then they can just decompile them and read any sensitive string that was just hard-coded inside the program.

How to store them.

Many aproches can be used, maybe using encrypted files to store those keys, but also that can be cracked, or maybe using environment variables that store the encrypted strings, but again, it can be cracked. So, we cannot trust anybody, we need to be completly away from any kind of machine to be completly safe, but we can trust one institution, and when running on a cloud platform this is important, all cloud providers have their safe way to store this things Azure has Key Vault, Amazon has Systems Manager Parameter Store and Google has 
ObjectAccessControls, all of them have their own capabilities and ways to charge you for those services.

Now, you maybe asking, why would I trust any of this companies to save my important stuff? You don´t have to, but they are certified by some external authorities, so at least you have a way to berify their security.

Additionaly you must be carefull when pushing a commit to an open repository, it is way to easy to find connection strings on Github, I personally use an extension on my IDE that can be configured to produce compiler errors if a connection string is hard-coded, I only have it configured to produce warnings, because compiler errors are a bit more frustrating. It also handles other things of the dev/ops pipeline, but the connection string checker is the feature I use the most.

No hay comentarios:

Publicar un comentario