My case is that I want to make the data protected even from people who have access to the back-end (the keys store), so they couldn't read it without the user's (represented by the client app, in my case the browser) assistance.
One option is to have the decryption keys stored on the client and passed with each request which sounds pretty messy to me and i'm not sure I want my keys to wander around the net like this. What I imagine though is that the client will keep some token (it might be a password the user knows) and the decryption can't happen without it.
I thought about using the purpose string for this, I have the feeling it is not a good idea since its main purpose is isolation. On the other hand it is part of the additional authenticated data used for subkey derivation. (based on this article https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/subkeyderivation?view=aspnetcore-2.1#additional-authenticated-data-and-subkey-derivation).
I came across some examples that create their own symmetric encryption with a lower level classes. (like this post Encrypt and decrypt a string in C#?). Since I'm not an expert in this area I would like to use as much build in classes as possible.
What is the recommended way to achieve what I need with the classes from the Data Protection API? (I'm using .net core 1.1 on Ubuntu)
One suggested way to run jobs is to save context parameters in properties files.
Like this one:
#
#Wed Dec 16 18:23:03 CET 2015
MySQL_AdditionalParams=noDatetimeStringSync\=true
MySQL_Port=3306
MySQL_Login=root
MySQL_Password=secret_password_to_cipher
MySQL_Database=talend MySQL_Server=localhost
This is really easy and useful, but the issue with this is that passwords are saved in clear.
So I'm looking for ways to do easily ciphering.
Here are 2 very insteresting questions already discussed in Stack overflow about password ciphering technics:
Encrypt passwords in configuration files
Securing passwords in properties file
But they are Java native and I'm searching for a better Talend integration. I've already tried different ways in my Talend jobs:
Simple obfuscation using base64 encoding of passwords
Using tEncrypt and tDecrypt components from the forge
Using Jasypt ot JavaXCrypto librairies
Using pwdstore routine from the forge
All these technics are described in a tutorial (in french, sorry) explaining how to crypt passwords in Talend
But another issue is encountered: keys used to cipher/uncipher are always in clear, so if you know good ways to address this point I'll be glad to experiment it.
Fundamentally, anything an application can reach can be reached by somebody breaking in into the system/taking over control of the application.
Even if you use obfuscation (such as base64 or more advanced), or real encryption where the keys are available (even if they too might be obfuscated).
So essentially there is no good enough way to do what you seek to do and worse: it simply cannot exist.
So what do you do instead ?
1. Limit the rights
MySQL_Login=root is a big problem ... a compromise of the application will lead to an immediate compromise of the database (and its data).
So, limit the rights to what is absolutely needed for the application.
This should really be done and is quite easy to achieve.
2. Separate user and admin level access
If certain things are only needed after user interaction, you can use secrets provided by the user (e.g. a password of the user can give a hash and that can be xor-ed with and get you a key that's not always present in the application nor configuration files).
You can use this e.g. to separate out permissions in two levels: the normal user level which only has the bare minimal rights to make the application work for the average user, (but e.g. not the application management rights that allow managing the application itself), and use the secrets kept by the user to keep (pert of) the key outside of the application while there's no admin logged in into the administrative part of the application.
This is rarely done to be honest, nor all that easy.
But even with all that you essentially have to consider the access to e.g. the database to be compromised if the application is compromised.
That's also why data such as application user password should not (must not) be stored in the database without proper precautions.
I have an ASP.NET MVC3 application that uses an EF 4.1 DbContext, database-first data layer. The EDMX approach works fine as I tend to make changes to my data model before adapting the application to them. The application works fine with the special EF connection string that includes metadata references.
However, there's one fly in the ointment. The application also uses ASP.NET membership and roles which require a standard connection string. I have several use cases that involve both the membership tables and other (EF managed) tables. As the two use separate connection strings, transactions that involve both need DTS to handle them. I don't want to go that route if I can help it, I'd rather all parts of the application simply use the same connection.
Getting EF to run with a plain connection string however is eluding me. Can anyone tell me how it is done, please?
You have several options here. (I know this is long, but please try to read the whole thing). It would help if you can give an actual scenario where you need such a transaction.
First, you are working on a false assumption that if both EF and Membership have the same connection string, it will use a common connection. This may be true sometimes, but is not guaranteed. Connection pooling tries to use the same connection for a given string, but if a connection is already in use it will create a second connection (or reuse an existing second connection already in the pool). So this line of reasoning will get you in trouble at some point.
One of the problems that Membership is designed to solve is to have a pluggable provider interface, so you can swap out membership providers and move to a different one (such as going from Sql to ActiveDirectory), without having to modify your application (or having to modify it much).
More tightly integrating these functions means throwing that benefit away. Maybe that's acceptable, but you should realize that going along these paths essentially tightly couples your data model to the specific Membership provider schemas. A few years ago, that didn't seem like it would be a problem as the membership system hadn't changed in years... but lately, MS and others have been introducing new Membership systems like SimpleMembership and Universal Providers which have different schemas.
So, if we're removing one of the primary features of Membership, why even continue to use it? Well, there are still some benefits from Membership. The primary one being that it provides an out of box full implementation of a user management library, including secure password encryption/hashing and features like question and answer authentication. That's not something to sneeze at, as doing a secure, bug-free membership system from scratch is not trivial (even though it would seem so at first).
So, one option is to implement your own MembershipProvider based on an existing one (like SqlMembershipProvider. Microsoft provides the source for these). Then you can simply override the schema to match whatever you want, but keep all the other features like password encryption and what not. Just fit them into your own schema. That makes them fit your data model a lot better.
However, even if you choose to use the standard membership provider, then there are some things you can do.
First, you can simply map the membership tables into your Entity Framework model. Just drag and drop them onto your designer, or add them in Code First. However, if you do this, you should only use them as read-only, and you should not create foreign key relationships between the membership tables and your tables. Instead, just do manual joins in your EF query (which is more work, but safer) and treat them as stand-alone tables.
Ok, so what about situations where you need to update or delete data from the membership tables as part of a query? Frankly, if you're using the standard membership tables I see almost no reasons this should ever have to happen.
The Membership tables are pretty simple and have very little actual data in them you should need as part of any statements in your app. Unless you're using the Profile provider, which I never do. If you need to map the membership tables, I suggest creating your own table of data rather than using the ProfileProvider.
The only reason I see where you may want to enlist a transaction is when creating a new user. However, since this is a one-time event, then a DT may not be such a terrible thing. However, there may not always be a DTC available to you... so in those cases, the best you can do is use a try-catch block to deal with exceptions.
The alternative is to completely throw away Membership and create your own IPrincipal and IIdentity implementations and simply write your own user management (I would still use the SqlManagementProvider source as a basis for this, however, as it's a good implementation).
Then, since user management is not part of a separate subsystem, you can safely use it for updates and deletes without worrying about what the other subsystem might be doing.
TL;DR
If you can't accept a DT, then either change your workflows, change your code to work with a try-catch-finally statement (though this won't guarantee rollback in case the app code dies suddenly, like a power outage), or use a custom IPrincipal and IIdentity implementation.
I discovered an answer here: https://stackoverflow.com/a/3408209/1169670. Adding "Enlist=false" to the ASP.NET Membership system's connection string stopped the escalation to DTC.
However, this approach simply prevents the membership system enlisting in the transaction. That was sufficient for my requirements, but it may not be in every case.
You should take a look at asp.net universal providers which are EF Codefirst based. the membership schema is exposed as POCO classes and DBSet so you should be able to include the DBSet into a common DBContext class
http://nuget.org/packages/Microsoft.AspNet.providers.core
I don't think you can get EF to use a "Plain" connection string.
In a few applications I have identical normal and EF connection strings sitting side by side
I'm working on a rewrite of a website that has to pull its user data data from a third-party system accessed via remote objects. In the interest of standardization, I've implemented a custom MembershipProvider for authentication and a custom RoleProvider for authorization, but I'm now pondering the best way to deal with profile data. Most of the advice I've seen says to use the ProfileProvider model to deal with profile data if at all possible, but its design really seems not to mesh well with the system I have to interface with.
The biggest sticking point is the ProfileProvider's insistence that a Profile is a bag of objects that is operated on as a single entity. That may fine for a SQL-based provider, but calling the remote objects is a very expensive operation. If I make a call to Profile.FirstName, GetPropertyValues looks like it's sent a SettingsPropertyCollection containing every object defined in the profile. For this website, that will include multiple sets of address information, order information, attendance information, and other things besides. Pulling all of that information at once is murderous on performance. It does look like targeted saves can be done through use of the IsDirty flag on each SettingsPropertyValue object, but only if it's a primitive type... which most of the properties aren't.
Am I understanding this correctly? If all the ProfileProvider provides is "Return this profile" or "Save this profile" then lazy loading seems impossible, and the performance hit is too great. If I ditch the profile model, what's a good alternative method for dealing with all the profile data? Should I just roll my own session-backed mechanism?
An extremely secure ASP.NET application is having to be written at my work and instead of trawling through the Internet looking for best practices I was wondering as to what considerations and generally what things should be done to ensure a public web application is safe.
Of course we've taken into consideration user/pass combinations but there needs to be a much deeper level than this. I'm talking about every single level and layer of the application i.e.
Using URL rewrites
Masterpages
SiteMaps
Connection pooling
Session data
Encoding passwords.
Using stored procedures instead of direct SQL statements
I'm making this a community wiki as there wouldn't be one sole answer which is correct as it's such a vast topic of discussion. I will point out also that this is not my forte by any means and previous security lockdown has been reached via non-public applications.
That's a bigger toppic than I think you perhaps realise. The best advice is to get someone that already knows who can advise you. Failing that I would start by reading the Microsoft document "Improving Web Application Security: Threats and Countermeasures" but be warned that runs to 919 printed pages.
You should refine the idea of "stored procedures" into just using parameterized queries. That will take care of most of your problems there. You can also restrict fields on the UI and strip out or encode damaging characters like the pesky ';'...
use forms authentication instead of storing authentication data in session.
Obviously: Hash passwords. If you want to be very cautious use SHA1 encryption instead of md5.