I'm trying to figure out how to use the new DataProtection features of .NET Core in a way that will allow me to specify my own encrypt/decrypt key. This will allow me to encrypt data outside my netcoreapp and then decrypt that data inside my netcoreapp (and visa versa).
Background:
I have database with hashed passwords and encrypted Social Security Numbers. There is an application that sits on top of this database that is written in .NET 2.0.
We are creating a new UI in ASP.NET Core that will exist at the same time as the .NET 2.O UI. Users can sign in under the old UI to do things and then turn around and sign in under the new UI and do other things.
What I've tried so far:
The documentation from the ASP.NET Core Documentation website does not cover this scenario.
I found the the test Encrypt_KnownKey() which uses ManagedAuthenticatedEncryptor. I believe it is using it's own key, but unfortunately it is internal.
We have converted our .NET 2.0 encryption code to .NET Core but it's a whole-bunch-of-scary and I was hoping for an out-of-the-box solution.
UPDATE:
My current process stores the key using Windows DPAPI, so I updated the key-{guid}.xml by replacing the generated Windows DPAPI encrypted key with the Windows DPAPI encrypted key from my existing system. Not surprisingly, this did not work.
It doesn't seem unreasonable to want to specify a specific key, so I'm hoping the reason I'm having issues finding the solution is my lack of knowledge of all things encrypted.
Related
My question is about encrypting data in classic ASP and what the best course of action would be to encrypt text (not passwords) for storage and then allow all users to have access to the data (decrypt it). Basically the project consists of a classic ASP application that allows users to create accounts and see messages from other users. These messages need to be encrypted before being stored.
I have found some classic ASP encryption methods including Microsoft CAPICOM but the website points to a link where the download can be found for it and actually is a dead link. https://msdn.microsoft.com/en-us/library/ms995332.aspx
I have also seen some other forums posts mention creating a .net web service that will handle the encryption/decryption process which can be called from the classic ASP files.
I also stumbled on another concept which does not use the public/private key and uses an approach and uses a shared private key?
So I am hoping someone might know what method is best to try and accomplish this.
You only had to Google CAPICOM download.
Site: Download Center: Platform SDK Redistributable: CAPICOM
This download contains the redistributable files for CAPICOM 2.1.0.2 and samples of its use. CAPICOM can be used to digitally sign data, sign code, verify digital signatures, envelop data for privacy, hash data, encrypt/decrypt data and more.
Version: 2.1.0.2 File Name: capicom_dc_sdk.msi
Date Published: 9/26/2016 File Size: 1.8 MB
See also: Alternatives to Using CAPICOM
Are there any advantages to using the Secret Manager instead of environment variables for developing ASP.NET Core, Azure Functions, Azure WebJobs and Xamarin projects using Visual Studio 2017?
Maybe another way of asking the same question but which one is the newer/more preferred method?
Secret Management is a mechanism of storing sensitive arguments within the profile of executing user, while using environment-variables aren't hidden from the view. Aside from the location of such data, I don't think there are any other major differences related to performance of retrieval or similar. You won't make a mistake if you decide to store non-sensitive data using the same secret-management, if you'd like - at that point it becomes a preference.
I am looking for a way to have ColdFusion and ASP.NET share session variables. I have seen posts in the past saying that you cannot do this directly with out calling some sort of ColdFusion function to return some sort of string representation of the session. I have recently learned about something called ehcache that is a third party session storage tool. That got me wondering is there a third party session tool that will allow ASP.NET and ColdFusion to share a session.
Some details about our systems:
They are running Windows Server 2008
We are using IIS
We are using ColdFusion 9
ColdFusion/Railo and asp.net can use EHCache, but they're very unlikely to share sessions out of the box. Each will have their own session key, which they'll use to put the data in/out. They'll all have their own way of storing the data. I may be wrong, but from memory, ColdFusion uses WDDX, Railo uses something like JSON and I've no idea what the .Net platform uses.
The point is that each hides the complexity of dealing directly with ehcache, but they each do it in their own way. If you want to interoperate, you may need to have each read/write directly to ehcache (or the database). You'll also have to work out a way of sharing a common key between .Net and ColdFusion.
If you're rolling your own version of this, then using JSON proably makes sense as the common format.
I currently have an ASP.NET website that has an encrypted connection string within it's web.config file. The settings are in the general AppSettings section, not the ConnectionString section. Within the application code we manually decrypt the connection string at run time as needed.
While working on refactoring the site, I came across a method that Microsoft once suggested which involves running an aspnet_regiis command in order to insert encrypted data directly into the ConnectionString section of the web.config file. This suggested method is now considered Retired Content although it doesn't say why (other than a small reference that some of the links may no longer be valid).
Here's the site I'm referring to:
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
My questions are basically - Should I bother refactoring the existing functionality to use Microsoft's once recommended way? I believe it would be more efficient than the current process. Also, why would this method be considered Retired Content? Is there a better way to do this, rather than my site supporting the encrypt/decrypt methods?
I've search Google & StackOverflow for other ways of doing this, but they all seem refer to Microsoft's way - or the way I currently have it implemented.
Maybe the site/doc you're referring to is marked as obsolete, but the technology behind is not. Here are the official links, not marked as obsolete:
DpapiProtectedConfigurationProvider Class (with an example), there is also the RsaProtectedConfigurationProvider that is capable of encrypting sections
Encrypting Configuration Information Using Protected Configuration
Encrypting and Decrypting Configuration Sections
ASP.NET IIS Registration Tool (Aspnet_regiis.exe) with the -pe option
I would definitely use this technology.
I'm guessing that they say the documentation is considered retired content because it was written for the .NET 2.0 framework. That being said, as Simon said, the technology behind it is still good to use.
The nice thing about using aspnet_regiis to encrypt your web.config file is that it is transparent to the application. You can write your logic assuming that the appSettings or connectionStrings sections are not encrypted, and if they are are encrypted using this method the .NET framework will take care of decrypting them before giving you the value.
One thing to keep in mind with using this method is that it will encrypt the entire appSettings section. If you open your web.config once it's encrypted you will not see any of the keys, but just a big encrypted hunk of data.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...