I have read about aspnet_regiis for encrypting web.config sections in an ASP.net project, but I am confused how this works since the decryption key must live in plaintext on the actual server somewhere.
I would ideally like to use AES for encryption, but this requires adding the aes key to the web.config in plaintext itself, which seems useless to me. (from https://stackoverflow.com/a/8777147)
Perhaps I am missing something.. can someone explain how this encryption process is actually secure?
aspnet_regiis encryption is easy to decrypt if you are able to login to a session on the machine and have access to the key.
This protects against a scenario where someone can view the file but cannot login to the machine and a scenario where the decryption key is correctly ACL'ed to a known set of users.
Under the hood it uses DPAPI and machine context specific information. I believe you can also encrypt using a user profile in which case no other user can decrypt it.
Here are some useful links:
http://weblogs.asp.net/owscott/archive/2005/07/29/421063.aspx
http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
You must create a key first and than use this key in your web.config
An detailed explanation can be found here: msdn microsoft
the one under web farm scenario's is the most practical.
I think it's useful to encrypt them if you have a lot of passwords etc. in the web.config.
Related
This has puzzled me for a while now. I don't have a broad understanding on encryption, but I understand the principle.
For the sake of an example, let's assume I have a program whose sole purpose is to post a random user's input to my private facebook profile. Now to do this, the program must have my login information to facebook (if this is not the case, assume another third-party application). This information, or credentials, must be stored somewhere, since the program's post method would be done without administration.
I know it is a bad policy to store the login credentials in the code as plain strings, as the compiled code can be decompiled and my credentials would be readable. The recommended solution is to store them in a separate file, encrypted.
As far as I understand, the encryption / decryption needs a key that also needs to be stored somewhere. Can't this key and the encryption algorithm be read from the decompiled code and used to decrypt the credentials?
Is the benefit of storing the credentials encrypted based on the extra step on decompile-decrypt, or have I drastically misunderstood something?
There are 2 ways one could check supplied credentials when you have encrypted version:
Decrypt the encrypted version; this would obviously require storing the tools necessary to decryption, which is unsafe
Encrypt what you are trying to check, and see if it matches your encrypted version. This does not require the ability to decrypt anything.
In this path: %APPDATA%\Roaming\Microsoft\Crypto\RSA
Keys are stored there but I can't make use of them. When I open them in a HEX EDITOR, I can only see parts of it, the remaining parts seems to be encrypted via CryptoAPI. How do I decrypt it?
Note: This key in particular was not created by an application I developed. I did some research and it seems CryptoAPI uses DPAPI to protect them. Any ideas?
Thanks!
You can look at the code at this site. They provide code to decrypt these certificates (which are used for EFS, among others). You do need the user password for Windows.
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.
I have 2 fields that I need to encrypt in a SQL Server database, a password and an ID number. I'm thinking on Rijndael and I've already got the scripts to encrypt/decrypt and will use machinekey for the public key.
The ID number will have to be able to be decrypted from 2 different apps, a web app and a console app that live in the same server.
What approach should I take for the machinekey? Should I create one using a tool like this one:
http://aspnetresources.com/tools/machineKey
Or should I just autogenerate them in the 2 apps web.config files as:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1" decryption="AES"/>
What's more secure? Or is there a more secure way? I read something about DPAPI which uses the actual machine's key?
First of all don't encrypt password field. Encrypting password is bad, someone gaining access to the key can decrypt all of your passwords so use Hashing. The algorithm you use for hashing i recommend should be bcrypt.
Secondly for encryption of ID use AES 256 bit algorithm and for storing encryption keys use microsoft solution that uses cryptoutility component which uses DPAPI (see:https://msdn.microsoft.com/en-us/magazine/cc163884.aspx). Donot store keys in the code anyone having the access to code can find that key and also you won't have any auditing capabilities related to who accessed the key and changed. Also storing in-process dll is bad that presents several security risks.
I want to encrypt the connectionstrings in my web.config. And my application will be deployed in web farm.
I tried reading some blogs about this, but got confused.
Can somebody tell me a link which they have really tried and got succeded.
You may have considered this, but if not: the RSAProtectedConfigurationProvider can use either machine-level or user-level keys to encrypt. The default is machine-level. This means you can't encrypt your web.config once and deploy it to every machine in your web farm. You must encrypt it on each machine since the key to encrypt and decrypt only exists on that machine.
You can get around this problem by using a user-level key or sharing a key across all web farm machines:
Import/Export keys - http://msdn.microsoft.com/en-us/library/yxw286t2(VS.80).aspx
Machine-level verus user-level key containers - http://msdn.microsoft.com/en-us/library/f5cs0acs(VS.80).aspx
We use the RSA Protected Configuration provider. That page isn't light reading, but it's got what you need.
I recommend the command like so (example from the article):
aspnet_regiis.exe -pef "connectionStrings" C:\Projects\MachineRSA
Before encrypting the connection strings, think about what you are trying to protect against by encrypting them. Your application will need access to the cleartext connection string in order and therefore will need access to the key. Therefore, an attacker who compromises your ASP.Net application will likely be able to steal the key and your protected connection string. So encryption is not really adding much benefit.
Instead of encryption, focus on how that file is handled by operations personnel and the file permissions that are applied in production. Only allow Read access to the ASP.Net worker pool account that your application runs as.