I have created User,Roles and assign Roles to User through the functions provided by Membership functions("CreateUserRole","CreateMembershipUser" and "AssignUserToRole") in the aspnet database.The User,Roles are created successfully.I am able to login too in my system.
Same credentials I need to be configured in other machines too.So inserted same User/Password/Salt Password through scripts in all the membership tables.It is not working in other machines.Though the data is successfully inserted in other machines in the start up of the project.The function "ValidateUserCredentials" is giving error in other machines.Is there any setting to create password and Salt password while generating the first time?
If you are using ASP.Net Membership Provider, you need to check the following -
Both web.config files are same (except connection string).
ApplicationName is same in both Databases as well as both web.config files.
Password Format is Hashed, set hashAlgorithmType explicitly in membership tag inside both web.config, because different membership providers use different hashed algorithms.
For example,
<membership defaultProvider="..." hashAlgorithmType="SHA1">
Rule of thumb is you want to include same machine key in both web.config even if Password Format is Hashed. (If Password Format is Encrypted, machine key is mandatory and same machine key must be included in both web.config files)
Related
I have an ASP.NET Core 2.0 WebAPI application that has Db ConnectionString in appSettings.json.
While in development it has this value:
"DefaultConnection":"Server=localhost;Database=Tyroll;Trusted_Connection=True;MultipleActiveResultSets=true"
and only when we publish it to production we change this with appropriate passwords, by using VS 2017 publish profile.
So SQL server passwords for are not stored on repository and no problem there.
The file appsettings.json is protected by IIS
The question I wonder is should this password be somehow 'hidden' even on IIS?
One reason being additional security, so that SQL credentials are not in plain text in case of breach here.
Another for some authorization scenario where IIS admin should not have directly access to SQL server.
I figure it could be encrypted and the app itself will have key for decrypting it. This would not be 100% secure since in the case of breach on IIS even this key could be reverse engineered from the app, but it would make it more difficult then when it's there in plain text.
So first question is should I be doing this at all?
And second if 1.Q is Yes, what would be the best / recommended way to do it?
Is there some built in tool for this in .NetCore2 or VS2017 or IIS, or some other tool?
Here are some related links:
reddit aspnet_core_appsettingsjson_security_question
stackoverflow is-appsettings-json-protected-by-iis
itprotoday passwords-webconfig
keeping-secrets-in-asp-net-core
I would suggest that you should user Active Directory Integrated security for accessing the database , the App Pool can run under the user account and that particular user account will only have the required access to the database . This safeguards the user credentials in case of an attack since the password is never exposed.
Solution I implemented is making custom encryption of Password in ConnectionString.
But since the App needs to the decrypt it, it is more an Obfuscation.
For encryption I have used AES (using System.Security.Cryptography) and the key is stored: half in connectionString itself and other half hardCoded in the Application.
In addition regex was used to extract Password from ConnectionString and then was replaced with decrypted string of it.
Security Noob here.
I am trying to move from asp.net membership to Umbraco membership. But using passwordFormat="Encrypted" seems to encrypt differently between the Umbraco membership provider and Microsoft's SQL membership provider.
If I register two users with the SQL membership provider (with passwordFormat="Encrypted") - the encoded passwords are different. If I do the same with the Umbraco provider they're the same.
While all the strings decrypt to the same thing (the correct password) - I apparently can't use the passwords encrypted by the SQL membership provider in the umbraco DB (ValidateUser fails).
Anyone have any ideas?
Note: I'm using the same machineKey on both sites.
Edit: Calling EncryptPassword() and EncodePassword() on the Umbraco membership provider gives different results - and EncodePassword is the correct one to call. But EncodePassword isn't available on the .NET Membership provider. This was another part of my confusion.
The passwords may be different because they are salted. Check out the PasswordSalt column in the membership database, it should be a Base64 string.
The Umbraco passwords are hashed using the System.Security.Cryptography.HMACSHA1 class. I'm guessing you could hash the SQL membership users passwords with HMACSHA1 and call it good.
See Add User with hashed password for more details.
I have some code in a EF Code First initializer that is grabbing the Membership Provider (ASP Universal Provider) and seeding some users. I know that isn't necessarily normal scenario but it has been working great in local dev. When pushing to Azure I sometimes see it not work. I see the records created in the Membership tables created, but when I log in with the password it doesn't match. Updating the salt and password with values from my local also don't seem to work. Is there something specific about the machine or OS for the salt/password generation or validation? It doesn't make sense because that would mess up any farm scenario, just looking for any help on why I might see something like this.
Yes, if you set the machine key explicitly, Membership Provider uses that key to encrypt the password.
So you need to have same machine key in all web.config files.
I have had a working asp.net 4 membership wesite for about 5 months and today I changed the regex to loosen the password restrictions. I can still create and access new accounts, but can no longer access any of the previously registered ones.
I have checked the database and confirmed that they are all still there. My initial thought was an incorrect password. I've checked two accounts that I knew the password for and both are inaccessable. I attempted to use the password recovery option, but when I type in the username I'm told that the user does not exist.
When I check the databases and consult both the membership and profile tables, the old and new users, pre and post regex change, are all in the same table. This leads me to my final discovery and the one that I have no experience. Is there a new Machine Key that is creating the new users but cannot decipher the old ones, hence making them unavailable? If so, how can I fix this?
Like your comment my first thought was that the application key has been altered. This key is stored in web.config/system.web/membership:
<membership>
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider"
...
applicationName="YOUR_KEY_HERE" />
</providers>
</membership>
This key allows different applications with the same membership provider (e.g. the System.Web.Security.SqlMembershipProvider in your case) to utilize the same database for storing membership data.
One provider will not see users from the other provider and vice versa, because they take the aplication name into account when querying the database. But when you look at the Users table, you may not notice immediately the relation, since the SqlMembershipProvider uses a Guid in the Users table. But it's a foreign key to the Applications table, where you can find the application name.
See also: Always set the "applicationName" property when configuring ASP.NET 2.0 Membership and other Providers
My problem was slightly different* but I specified my own machine key in web.config. See the details here: http://msdn.microsoft.com/en-us/library/ff649308.aspx
(* my app was wandering from server to server in a large virtualized server farm hence changing the machine key with each hop causing the app being unable to read the cookies it has previously set.)
I have a web application developed in .net 3.5, and a SQL Server database.
Current auth method is a connection string in web.config, it seems like a good idea to move the authentication details out of plain text.
So, I have two questions:
Trusted Connection - The password policy here is strict, requiring frequent changes. Does this mean i'll have to update the password for the website every time it expires?
Is there another/better option?
As an alternative to trusted connection you can look at this set of articles on how to encrypt your web.config.
In brief, if you invoke from command-line
aspnet_regiis -pe "connectionStrings" -app "/SampleApplication" -prov "RsaProtectedConfigurationProvider"
section connectionStrings in the web.config of application SampleApplication from the default site will be encrypted using RSA.
I think putting the username/password is better simply because I don't want the user that runs my IIS server to have access to lots of databases. I would prefer to have it be focused, to where, for this application there is a user and that user has only access to this database.
You do need to be certain that your web.config file is secure, so you do need security on that.
If you want more security you could just use a dependency injection framework, and inject the compiled class that has the username/password, and just use that connection string. This class could be obfuscated, if you want some semblance of more security.
No, you won't have to keep changing the trusted connection details. You don't store the password there, so password changes won't affect you. (This is if you're using Basic Authentication, getting the users to connect to the SQL box as themselves)
But - if your application pool is running as a particular user, and that user has its password changed, you'll need to update that. You could consider having a user whose password doesn't expire for this.
Trusted connection isn't an option? A frequently changing password shouldn't be a limiting factor in your decision, since it's trusted you don't have to enter a password.
Another alternative is encrypting the connection string.