We are implementing a load balancer for our web site for redundancy purposes so if website 1 goes down, the load balancer will send all traffic to server 2 and vice versa.
I have implemented a machineKey that I generated in the web.config, but in doing so have broken my membership logins.
From what I've read, the provider should default to "hash" unless I have the provider set to "encrypted" and this shouldn't have affected my login, but it has. I can't seem to log in anymore, receiving an invalid password error.
Here is my relevant web.config code:
<machineKey
validationKey="A181A9E1960ABFC9DF3F2D8AAC8597FFDCA69A87591B5D89D0A539A21AC543022680DFBF181BACC37533D15FCA59A0E4E1A2AA748A268FFED48AAFED00C8BA7A"
decryptionKey="7366076C8BE16F2DA3AF9642071A136E5D8386ECA7659347560063474AFF61BB"
validation="SHA1"
decryption="AES" />
<membership defaultProvider="DefaultMembershipProvider">
<providers>
<add name="DefaultMembershipProvider"
type="System.Web.Providers.DefaultMembershipProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
connectionStringName="ClientRunner"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
applicationName="/" />
</providers>
</membership>
What am I doing wrong here?
I'm not exactly sure why this worked for me, but what I ended up doing was to modify my web.config like so:
<membership defaultProvider="DefaultMembershipProvider"
hashAlgorithmType="HMACSHA256">
and
<machineKey
validationKey="50E5BFCB171748F86DA392AC55D5217EDEFCE43C9B6D192C5265D8F0CDDC86CECBA42040C408B7B71EAD6A4CE669545AAFDE76BBA42CA44203223A7ADC442D1E"
decryptionKey="EE9C03B1D922639AB7BA3C00E8C993BD8F6D27635B07979DF09F8C174C91CA65"
validation="MD5" decryption="Auto" />
The existing membership info seems to be allowing me to sign in now.
Related
I'm using Membership provider configured in Web.config like this to use SQL CE:
<connectionStrings>
<add name="DefaultConnection" connectionString="Data Source=|DataDirectory|\Users.sdf" providerName="System.Data.SqlServerCe.4.0" />
</connectionStrings>
and:
<membership defaultProvider="DefaultMembershipProvider">
<providers>
<clear />
<add name="DefaultMembershipProvider" type="System.Web.Providers.DefaultMembershipProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" passwordFormat="Hashed" applicationName="/" />
</providers>
</membership>
This works correctly if I have no machinekey specified.
If I add a machinekey to the Web.config as follows, then existing users can no longer login. However I can create new users and they can log-in.
<machineKey validationKey="D829F10BE92767EC2F9E9FC53B2CF3952AAD386483D6E81E74B4BD84DBE66F71CA121581598FEA669892DBDE46507DF3C8028BBD8FD4E678557621141945171C" decryptionKey="D14678D1FB1777E10316163F6D97071CDF2A447FA15C172DC9525BA397BB0610" validation="SHA1" decryption="AES" />
<pages enableViewStateMac="true"/>
If I remove the machinekey then originally-created users can log-in again, and newly-created users cannot.
Why does adding a machinekey change whether existing users can log-in, given that the password is hashed not encrypted?
By default, .Net Framework 4 use SHA256. Please make sure algorithm is same in both places, and try either SHA1 or SHA256.
<membership ... hashAlgorithmType="SHA1">
<providers>
...
</providers>
</membership>
<machineKey ... validation="SHA1" decryption="AES" />
I have an Azure web site that uses forms authentication with an Azure membership via the standard Microsoft tools and database. When I website administration tool, it sees the database and creates the users correctly. When I try to login however, I receive an authentication error.
The really strange part is that I have another Azure website that also uses a membership database. I copied the membership info directly from that sites web.config file into my broken site. When I go to administer the website, again, it sees the users correctly but when I attempt to login, I get receive an authentication error. To be clear, I can login properly from the working site but when I move the config info over to my new site, the same credentials fail.
How can I determine what is causing the problem? Below is code from web.config:
<add name="StrataluxAuthorize" connectionString="Data Source=xxxxxxx.database.windows.net;Initial Catalog=StrataluxAuthorize;Persist Security Info=True;User ID=xxxxxx;Password=xxxxxxxxxx" providerName="System.Data.SqlClient" />
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" defaultUrl="~/" timeout="600" />
</authentication>
<profile defaultProvider="DefaultProfileProvider">
<providers>
<add name="DefaultProfileProvider" type="System.Web.Providers.DefaultProfileProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" applicationName="/" />
</providers>
</profile>
<membership defaultProvider="DefaultMembershipProvider">
<providers>
<add connectionStringName="StrataluxAuthorize" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="true" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="/" name="DefaultMembershipProvider" type="System.Web.Providers.DefaultMembershipProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</providers>
</membership>
<roleManager enabled="true" defaultProvider="DefaultRoleProvider">
<providers>
<add connectionStringName="StrataluxAuthorize" applicationName="/" name="DefaultRoleProvider" type="System.Web.Providers.DefaultRoleProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</providers>
</roleManager>
Just a guess based on the info given. Be sure that the "ApplicationName" property of the membership profider matches for both sites that will use the same Membership database. It doesn't appear that you have explicitly defined one so I believe by default it will use the Web Project Name. So if there is a mismatch (presumably there would be) between the 2 website names then the membership db will try to create a new application id in the database.
Sample Config:
<membership defaultProvider="DefaultMembershipProvider">
<providers>
<add connectionStringName="StrataluxAuthorize" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="true" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="" name="DefaultMembershipProvider" type="System.Web.Providers.DefaultMembershipProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</providers>
</membership>
Just a bit more clarification:
If you want the users which originaly appeared in web app "A" to be available in web app "B" then the application name in the configuration of web app "B" should be "A". Otherwise the membership provider will view it as a new application and it will get its own id and unique set of users.
I have an ASP.NET WebForms app using Microsoft ASP.NET Universal Providers (NuGet) for membership and roles. Under full trust everything works fine, but when I edit web.config to specify medium trust I get this error when loading a page that accesses the membership:
Type 'System.Web.Providers.DefaultMembershipProvider' cannot be instantiated under a partially trusted security policy (AllowPartiallyTrustedCallersAttribute is not present on the target assembly).
I've searched the web and haven't found much info about whether this is a known limitation or if there is a workaround. I'm working on the open source app Gallery Server Pro, which is distributed in the MS Web Gallery and must support medium trust environments.
Any insight?
[Edit] Per the request, here is the web.config stuff (I'm not using profiles or the session state provider):
<membership defaultProvider="DefaultMembershipProvider">
<providers>
<clear />
<add name="DefaultMembershipProvider" applicationName="Gallery Server Pro" connectionStringName="GalleryDb" passwordFormat="Clear" enablePasswordRetrieval="true" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="50" minRequiredPasswordLength="2" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" type="System.Web.Providers.DefaultMembershipProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</providers>
</membership>
<roleManager enabled="true" cacheRolesInCookie="true" cookieProtection="Validation" defaultProvider="DefaultRoleProvider">
<providers>
<clear />
<add name="DefaultRoleProvider" applicationName="Gallery Server Pro" connectionStringName="GalleryDb" type="System.Web.Providers.DefaultRoleProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</providers>
</roleManager>
I think it may be because of catching role in cookies,
<roleManager enabled="true" cacheRolesInCookie="true" cookieProtection="Validation" ...
Remove that part, or make it false and then check if its working..
As medium security will block cookies and many more things, as cookies are not considered secure. Its basic material for scavengers(hacking data from left over/temp files).
I hope this will do..
I recently upgraded MySql Connector /NET 6.0.4.0 to version 6.4.4.0. My site uses the MySql Membership Provider to process logins, but since upgrading no users can log in. That is to say, Membership.ValidateUser(user, password) returns false for previously valid usernames and passwords.
I'm conscious that I haven't specified an encryption/hashing key anywhere in web.config, and maybe the new version hashes passwords differently by default? If I create a new user, they can log in just fine, it's just all the old users who can no longer log in.
Is there a workaround to save hundreds of people from having to set new passwords? Or at least to stop a repeat of this problem if I upgrade again in the future?
web.config
<system.web>
<roleManager enabled="true" cacheRolesInCookie="true" cookieTimeout="240" createPersistentCookie="true" cookieSlidingExpiration="true" defaultProvider="MySQLRoleProvider">
<providers>
<add name="MySQLRoleProvider" autogenerateschema="true" type="MySql.Web.Security.MySQLRoleProvider, MySql.Web, Version=6.4.4.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" connectionStringName="LocalMySqlServer" applicationName="/"/>
</providers>
</roleManager>
<membership defaultProvider="MySQLMembershipProvider">
<providers>
<clear/>
<add name="MySQLMembershipProvider" type="MySql.Web.Security.MySQLMembershipProvider, MySql.Web, Version=6.4.4.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" connectionStringName="LocalMySqlServer" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="5" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" passwordStrengthRegularExpression=""/>
</providers>
</membership>
...
</system.web>
I'm using ASP.NET 3.5 and connecting to MySql 5.
EDIT This just got wierder; it seems that some users can still log in, but others can't. My old login definitely stopped working, and I've checked that it's not locked out or anything.
So, I am converting an application from integrated security to forms authentication using the built-in membership provider and having the most bizarre behavior. Initially, I used the default sqlexpress configuration where it creates an aspnetdb.mdf file in your App_Data folder.
However, I wanted to move this to my SQL Server and did so by creating the procedures and tables in an SQL Server database and pointed my provider at that database. And yet, when I would run the Web Site Administration Tool, it would not look at the SQL Server.
It keeps creating an aspnetdb.mdf file and using that, even though my application appeared to be properly hitting the SQL database. Finally, I turned off the SQLEXPRESS service, and now is where the really odd bit happens.
Login works fine - Membership.Provider.ValidateUser(LoginUser.UserName, LoginUser.Password) returns true. However, when an IsInRole call is made, it times out failing to connect to the database. Clearly, it is trying to connect to the SQLEXPRESS database. I have restarted IIS, restarted the database service to no avail.
Is this not the right place to tell the membership service what database to hit:
<connectionStrings>
<add name="MyConnection" connectionString="user id=myuser;password=mypassword;data source=SERVER\INSTANCE;initial catalog=mycatalog;"/>
</connectionStrings>
<system.web>
<authentication mode="Forms">
<forms name="formsauth" protection="None" path="/" loginUrl="~/Account/Login.aspx" cookieless="UseCookies"/>
</authentication>
<roleManager enabled="true" />
<membership>
<providers>
<remove name="AspNetSqlMembershipProvider"/>
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="MyConnection"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
applicationName="/MyApp"
requiresUniqueEmail="false"
minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
/>
</providers>
First and foremost, the reason why the aspnetdb.mdf is being created is because you're using the ASP.NET Configuration Tool. It only works for the SQL Express instance. It can't be used on a fully fledged SQL Server. For that, you'll essentially need to re-create the administration panel within your own application.
If you wish to use Roles under the local SQL Server, you'll need to configure your web.config to point to your SQL Server for the role provider as well. By default it points to the aspnetdb.mdf file that the Membership provider also points to.
For example:
<system.web>
<roleManager defaultProvider="SqlRoleProvider" enabled="true">
<providers>
<clear />
<add name="SqlRoleProvider"
type="System.Web.Security.SqlRoleProvider"
connectionStringName="MyConnection"/> <!--- Point this to your sql server -->
</providers>
</roleManager>
</system.web>
For you it would look something like this:
<configuration>
<connectionStrings>
<add name="MyConnection" connectionString="user id=myuser;password=mypassword;data source=SERVER\INSTANCE;initial catalog=mycatalog;"/>
</connectionStrings>
<system.web>
<authentication mode="Forms">
<forms name="formsauth" protection="None" path="/" loginUrl="~/Account/Login.aspx" cookieless="UseCookies"/>
</authentication>
<membership>
<providers>
<remove name="AspNetSqlMembershipProvider"/>
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="MyConnection"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
applicationName="/MyApp"
requiresUniqueEmail="false"
minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""/>
</providers>
</membership>
<roleManager defaultProvider="SqlRoleProvider" enabled="true">
<providers>
<clear />
<add name="SqlRoleProvider"
type="System.Web.Security.SqlRoleProvider"
connectionStringName="MyConnection"/> <!--- Point this to your sql server -->
</providers>
</roleManager>
</system.web>
</configuration>
See here for more details: Membership and Role Provider