I know I can encrypt sections of my web.config to protect sensitive data.
I know that the machinekey is used to encrypt/decrypt the section(s).
I know that I'm hosting in a web farm so my machinekey needs to be sticky.
But I think I'm missing the point. If I place the machine key in the web.config, and I place the encrypted section in the web.config, then how is that secure? Surely that is obfuscation at best?
My scenario:
We are building web applications that are hosted in the cloud, developed and managed internally. The reason for needing to protect sensitive keys is because we have settings that allow use of third party tools (e.g. ESP, Cloud storage, etc). With these publicly visible in the web.release.config transform, developers are free to connect to product services, opening an element of risk.
If you can fill in the gaps in my logic, that would be great. But what I'm really after are suggestions on best practice solutions to my problem.
I'll add more information on request.
The solution in your case is to use key containers. You have to create key containers, export it and import it into the other system where you need the key.
You can find out how to do it here :
https://msdn.microsoft.com/en-us/library/yxw286t2.aspx
Related
I was wondering what the best (most secure) way to encrypt Web.Config files in an ASP.Net MVC 4 Application are? I have some background with developing in-house applications using C#, but we never focused too much on encryption due to other security that was already in place.
EDIT: My host Server is ORACLE if that changes anything? A friend mentioned perhaps using aspnet_regiis.exe after deployment of my code with the '-pe' argument. Anyone have any pros/cons for this method?
EDIT2: ORACLE is a Database, not a Server! Can I go home yet?! >_<
The typical way is to use a ProtectedConfigurationProvider to encrypt the sensitive sections. There are several existing implementations. You can also implement your own if needed.
I was wondering what the best (most secure) way to encrypt Web.Config files
"Most secure" depends on what threats you are trying to protect against. You can assume that all the standard cryptographic algorithms are secure, but by encrypting web.config, you've simply exchanged the problem of protecting plaintext credentials in web.config for the problem of protecting an encryption key.
Typically you'll use Protected Configuration to encrypt web.config.
If you use the DPAPI provider, you'll encrypt using the server's machine key. This means that the encryption can be broken by anyone who can log in to the server. Also by anyone with write access to a folder containing a web site on the server, because they can upload code, say an aspx page with embedded script, that can do the decryption. This is a good choice if:
your server is secure (not shared with other untrusted applications, e.g. a hosting environment)
you don't want to copy the web.config to other servers (e.g. in a web farm) - it needs to be encrypted independently on each server.
Alternatively, if DPAPI doesn't meet your requirements, you should probably use the RSA provider. You can protect the key with an ACL against unauthorized access by other users on the same server, and can share it across multiple servers.
You can use the CryptoAPI to encrypt individual configuration values.
You can use the DPAPI to encrypt entire sections.
So I am using connection strings in my web.config using SQL authentication.
Of course people say this could be a vulnerability as you are storing password in plaintext.
However, from what I know, IIS never serves web.config, and web.config should only have read access to administrators and IIS anyway. So if the hacker has gained access to the webserver, then it won't matter what encryption I use because the private key will be on the webserver.
Wouldn't encrypting connection string be classified as security through obfuscation?
Is it worth encrypting web.config connection string and storing the private key on the webserver?
Further, of course if I don't use SSL, I am transmitting connection string over HTTP in plaintext. If I use SSL then this problem should be mitigated as well.
I wouldn't say that storing a plaintext password in Web.config is a security vulnerability, in and of itself. But encrypting the password is a useful defense-in-depth measure, not just security through obscurity:
What if IIS is misconfigured to serve Web.config?
What if a security vulnerability is discovered in ASP.NET (like the padding oracle vulnerability) that allows anyone to download Web.config?
There are varying degrees of access to the Web server, from full administrative privileges to server-side code injection. If an attacker can only manage to do the latter, he might be able to read Web.config but might not be able to access the machine keys, especially if your application is running under partial trust.
In the end, it's up to you to decide if the risk of storing plaintext passwords in Web.config is acceptable. Of course, if Windows authentication is an option, then you may want to consider using that instead of SQL authentication.
UPDATE: When talking about security, it's a good idea to identify the assets and the threats. In this case, the asset is sensitive data in the database (if the data is unimportant, then why bother protecting it with a password?), and the threat is the possibility of an attacker somehow gaining access to Web.config and thus the database as well. A possible mitigation is to encrypt the database password in Web.config.
How much of a risk is it? Do we really have to plan for such an astronomically rare occurrence?
This mitigation has already proved its worth once: when the ASP.NET padding oracle vulnerability was discovered. Anyone who stored a plaintext password in Web.config was at risk; anyone who encrypted the password wasn't. How certain are you that another similar vulnerability in ASP.NET won't be discovered in the next few years?
Should we also encrypt source code and decrypt on run-time? Seems excessive to me.
So what if an attacker does get access to your source code? What's the asset you're protecting, and what's the threat you're concerned about? I think that in many cases, source code is much less valuable than data. (I'm thinking here about off-the-shelf commercial and open-source software which anyone can obtain.) And if your source code is valuable, maybe obfuscation is something to think about.
I feel if they already have even limited access to your box, then your host has failed or you've installed vulnerable services already.
What about security vulnerabilities in ASP.NET or your code? They do pop up from time to time.
My concern is standard practices. Is it a standard?
Microsoft has recommended encrypting connection strings.
What you should do is evaluate the risk that storing a plaintext password poses:
How likely is it that an attacker will be able to discover and exploit a security vulnerability that exposes Web.config? Based on past history, I'd say the likelihood is low (but not "astronomically" low).
How valuable or sensitive is your data? If all you're storing is pictures of your cat, then maybe it doesn't matter much whether an attacker gets your database password. But if you're storing personally identifiable information, then from a legal standpoint, I'd say you should take all possible measures to secure your application, including encrypting your connection strings.
Consider that, if Production passwords are present in the web.config file, then any developer with access to that file has access to the Production database. This is especially a problem when the username in the connection string has read/write access to the database. It then becomes possible for developers to "fix" things with no record that the "fix" ever occurred.
I think this is not from "outside" protection, but for "inside".
Sometimes, SQL administrator/user and OS administrator are different people. But OS administrator has access to all files, so he could easily read the SQL credentials in web.config file. But those credentials can be encrypted in a way, that even OS administrator has no way to decrypt.
And it is hardly "security through obscurity", because encrypted connection string canno't be decrypted without correct user certificate and usualy only IIS "user" has that one.
I used to read some articles on IHackStuff online blog. This guy explained some ways to get to really interesting info using Google search engine typing things on the search box like:
filetype:config web.config -CVS
This came out with multiple results related to cached web.config files on production servers, all the info of those files were available to public eye. Considering this possibility I would still recomend to encrypt web.config database access info whenever such info is valuable enough.
You're right to say that web.config won't be served by ASP.NET to a browser. But developers are cautious, so when they release a new version, sometimes they copy a known good web.config to something like web.config.old or web.config.bak. And because developers are lazy, after the release they forget to delete the old web.config, or keep it hanging round for a few days in case they need to rollback the release.
Now, .old and .bak files will be served to a browser, which means it's easy to write a script or a tool that scans for these files and downloads them to an attacker who can then go through them at their leisure to look for connection strings with usernames and passwords, and suddenly credit card numbers from your database are circulating the Internet...
If you don't want to get into command-lines and RSA keys (and frankly, why would you?), take a look at this tool for encrypting your web.config.
I have come across this excellent blog explaining how to encrypt/decrypt the database connection string with a PKCS12ProtectedConfigurationProvider inside Azure Cloud.
http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-connection-security.aspx#create_aspnet
Is this something that should be done, or is it rather security overkill?
If Web.config cannot be accessed from internet due IIS restrictions, nobody would be able to read the DB connection string (incl. password etc) inside the Web.config anyway, so why bother to encrypt it in first place?
Many Thanks,
I think it is the same argument as when considering encrypting connection strings outside Windows Azure, which is - who has access to the box.
I have been talking to organisations who had several people with access to the box, which would allow them to see the web.config and extract the credentials for the databases, in places where you don't want system administrators/developers/etc accessing your database, this makes sense.
If you are the only one with access to the instance or if that is not a concern of yours, you don't have to worry about it
Oi, some vendor is telling my bosses that not encrypting the web.config is big security hole. This sounds like bunk to me. I mean, if someone compromises the server aren't we screwed anyways?
Like #Joelt suggested, ASP.NET had a security issue semi recently that allowed people to access files in the root web etc. Now, this issue could have existed for a long time. Alternatively, there could be a secret flaw right now that no one knows about except some leet punks ... which means we're all vulnerable right now. I mean, until the ASP.NET team (and security people a week or two before them) announced that previous flaw ... how long was that out in the wild? How many people exploited that?
So - that's the general idea. If for some reason a flaw exists - where people can remotely gain access to files - including web.config - then your data could be known.
Now - the kicker is this. So .. someone might find out about my DB name, DB ip addy and DB password .. right? but they need to access my internal DB ... so good luck there. BUT, my web.config might have my twitter username password in there? (Ding! light just turned on). My 3rd party api username/passwords. etc.
THAT is where the real security issue lies, IMO.
I'd hate it if u learn my companies twitter username/password and then start defacing our twitter account.
The encryption does not mean that you are protected. The private key needed for decryption is stored on the server, so if your server is compromised your web.config can be decrypted.
We only encrypt the connection string section of the web.config. It helps prevent other prying eyes from easily accessing our connection strings especially in the development environment (which is often much less secure than your production environments).
The encryption is just a small piece to the layered security. It is by no means an end-all solution for protecting your sensitive information.
There was a recently released security hole in ASP.net that would have allowed a remote user to access any file in the web root, including web.config, without accessing the entire server. Additionally, there may be login information in the web.config that allows compromising one server to compromise another.
Sort of. In my case, I host on a shared hosting account. So a lot of people have access to my account and the files stored there.
Personally, I don't worry about it too much. But, if someone had a mind to, they could access that information. And even if you own the server, if it's a company then there could be a lot of people who have access to it.
For critical data, encrypting it makes sense.
I am trying to secure a MSSQL database for our .Net website.
I wanted to separate the database into different schemas so that we had an schema like 'Account' which had personal information and a schemas like 'Public' that had generic public content data.
Each of these schemas would be accessed using different SQL user accounts and they would each need their own DBML since they would need separate connection strings(we are using LINQtoSQL).
My colleague is claiming that since we just have both of these accounts in our web.config anyways this design is no more secure than just using one SQL server account that has access to the whole database. There is no need to separate the schemas since we aren't using Windows based authentication.
So my question is who is correct? Would separating the database into schemas be any more secure? Or is it a waste of time since both SQL accounts would be located in the web.config (even if encrypted)?
Your colleague is wrong on one level and right at another.
Breaking the database into schemas as you propose will help with attackers who are able to find things like SQL injection flaws. If you are diligent in setting your permissions, that is...
However, splitting the schema like this offers no additional benefit if someone manages to get into the actual file system and can red the web.config.
You need to think about all the possible layers.
If you haven't already, check out this great resource:
http://msdn.microsoft.com/en-us/library/ms998372.aspx
Also, try googling storing your connection strings in the registry. There are some good references for that, which will help protect you if someone gets into the file system and can read your web.config.
Finally, don't forget to encrypt your web.config...
Separating the accounts will reduce the risk in case the attack vector is SQL Injection. The attacker will only be able to do whatever is allowed by the priviledges of the session is using to carry on the injection. Presumably only an authenticated attacker can use the Account session as the injection vector so he will be detered because it can be discovered from logs who did it. Wether this separation is an effective mittigation of a threat, it depends a lot on information you left out, most importantly how do you separate access to the two areas in your code.
Having both connection strings in the web.config means that if the ASP pool itself is compromised then an attacker can use both string.
I presume the strings are encrypted none the less, see Encrypting Configuration Information Using Protected Configuration. This way at least the connection info is not lost if the web.config is leaked.
Well if you encrypt the section the accounts are in, I don't see what would be the problem. The only problem could be on connection pooling, it will fragment the pool in 2 that's it.