SQL Security
Securing SQL in a web environment.
This is a complex issue that needs to be considered from multiple angles.
Where the data is hosted is a consideration, what is the data, how secure does it need to be, what types of security issues are you trying to prevent.
If your data is sitting in a SQL server, one 'solution' is to use integrated security to not expose SQL logins and passwords, on the surface this looks good until your account is hacked, then the hacker has the ability to access the data without too many issues.
My personal preference is to use only SQL logins, no integrated accounts, at least two main accounts, the SA (the admin account) and at least one account to access the actual data.
But SQL logins have issues, somehow you are going to have to put the password somewhere, for Azure based solutions you can use Azure key vault. But what about the on premise SQL server, there is 3 main ways to store this information, configuration files, registry, environmental variables, the key thing is to not have the password in the website, so if just the website gets hacked you are not exposing login details for SQL server, via connection strings.
Whatever storage system you use the data should not be saved in clear text, what do you encrypt, just the password or the whole connection string, the way I look at it is this, what is easier to crack, a 10 digit password or a 50 character connection string, the later will be harder to crack as long as you are not just converting characters into encrypted characters, look at how the German enigma machine, it was cracked partially because certain words appeared in almost every message, decrypt that bit and you can work out the rest of the message.
My personal preference is encrypt the whole connection string, use it in an environmental variable, whilst it is not full proof, it will significantly slow down a hacker, remember if a hacker gets onto your server and gets access to your SQL Server, they may do backups, they may copy the .mdf files, they might steal your backup files, you need to think about these potential outcomes.
I use SQL Express for a number of smaller projects, it's a free version of Microsoft SQL Server, but it comes with limitations, from a security perspective, not being able to compress or encrypt backups does leave a door open.
Something I have done in the past is do the SQL Express backups, then using 7zip encrypt the backups, then remove the unencrypted version, but you are back to the plain text password issue like connection strings.
The Salt/Key above is valuable this is how you encrypt and decrypt strings, this is like a long password, it should be protected.
There are things you can do with this Salt/Key to make life harder for the hacker, reversing it, chop it up so it becomes 2 or more variables that have to be glued together, placing in bit in the registry and another in a variable in code. Or placing one chunk in one project and another in a second project, meaning the string is spread out across two DLLs.
Other things that are important, don't leave debug code on your webserver, this would allow a hacker to run your code step through it and see the Salt/Key, also only have the decrypt side of the code in the web application, this means can't see how the encryption was done.
Above is the encrypted string.