Why are ASP.Net membership credentials stored in a database not portable between (1) web apps and (2) machines?
Two scenarios --
We backup the production database and restore it to the development server. None of the production login credentials work on the development server, even though the underlying data was restored from production seconds before.
We build a new version of the app ("v2," let's call it), and install it on the production database under a different website (alongside the production app -- "v1"), but talking to the same production database. None of the login credentials work on v2 of the app, even though it's talking to the same database and therefore has the exact same membership data.
There is no machine key in the web.config file. If I leave this out, I assume it bubbles up from the machine.config file, which means it should be the same per machine, which means the two webapps talking to the same database on the same machine (the second scenario above) should share credentials, correct?
We also checked the application names and IDs in the databases, and they are identical between machines.
If you reset the passwords, everything works fine (with new passwords). But that means everyone has to reset their passwords, which isn't ideal.
It seems that somehow, the password salt changes from database server to database server and from web app to web app.
Edit:
Using ASP.Net 4.5 and System.Web.Security.SqlMembershipProvider 4.0.
Another Edit:
I have verified the PasswordFormat is "Hashed." Additionally, I have checked the Password and PasswordSalt fields between the two databases. They are identical.
Solution:
The hashing algorithm in the web.config was set differently between the two apps.
The hashing algorithm was different between the two webapps. One was using the default "SHA1," and the other was explicit set to "HMACSHA512."
Related
I'm using the latest .NET Core (1.1) and EF Core to build my ASP.NET website and I also use ASP.NET Identity, and I have already published my website to Azure host and everything is working as expected there(including my Windows localhost). However now I'm switching to my own Linux(Centos 7) dedicated server with Apache, and I have the site working however I get "Invalid Token" messages when trying to reset password or confirm email.
I have checked other questions like this and solution was to encode/decode url which is sent via email, however I have did that already but it's not working still.
I also tried to copy the whole database from localhost to my server in case there was something with migrations on the Linux host, however that also did not help. All migrations are applied and other things that don't use Identity context also work.
After additional searching I have found that it might be problem with different machine keys on the host and that the security stamp is not in sync, but I don't see how could that affect me because I deploy a whole new version of my app to the server, and on localhost everything works as well on Azure hosting. Also this used to be the problem with ASP.NET MVC, not Core.
How can I even debug this issue? I have not seen anyone having this problem with the new EF Core and especially not on Linux host.
I deploy the site using the latest VS 17. I have set up Apache proxy as guided on the official .NET Core website: link
Dotnet core MVC application on default saves your Authentication tokens encrypted in a cookie.
The seed/key for this encryption/decryption of the data is based on your machine key, which is different on every machine.
If you ran multiple instances of your app (load balanced) this message/error will happen when your system tries to decrypt the session cookie, created on the other machine.
On the other hand if you still have cookie information in your browser and you start hosting the website on a different host ofcouse this new host wont be able to decrypt these already existing session cookies.
I Know this because i had the same problem. You can find the source-code of session here: https://github.com/aspnet/Session/tree/dev/src/Microsoft.AspNetCore.Session
I tried this when dotnet core was not yet released and i ended up using this blog. But probably now is very outdated.
I'd advice you advice you to use an external session store instead of using the cookie as data storage. read through their documentation on how to set that up: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/app-state
I have a Visual Studio solution that consists of an ASP.NET website and a Lightswitch (soon to be 2 LS apps). I have configured everything so that a single login allows the user access to both apps. Currently both apps and the aspnetdb database are all on one machine.
Eventually, I want all three apps to be Azure websites with authentication via an Azure SQL database.
I want move the aspnetdb authentication database to an Azure and deploy the second LS app as an Azure website. Eventually the other 2 apps will be migrated to Azure, but in the meantime they will remain on the old server.
My question is are there any extra security issues I should be concerned with this arrangement? I have never had authentication and websites on different servers.
I don't think there are extra security issues as long as you're happy with the security around the connectivity to the SQL Database (which is based on HTTPS).
I do, however, think you should consider using Windows Azure Active Directory instead which will offer a potential cost saving and reliance on recent standards for authentication. if you haven't already look at this walkthrough. it does not talk about LS but rather an MVC application, but you should be able to see the setup process
You replied my question late, and accepted the answer. Anyhow, I'll answer your question so that this might be able to safe your time in the future.
If you want to host in Azure, you should not use Legacy Membership Provider (in which tables are generated using aspnet_regsql.exe).
Instead, you want to use new ASP.NET Universal Providers which is SQL Azure compatible.
any extra security issues I should be concerned with this arrangement?
You can configure to allow certain IP address(es) to access to your SQL Azure DB from outside of Azure. However, if someone knows your SQL Azure's username and password, they can access your Database within Azure.
Basically, you should be fine as long as nobody know your SQL Azure DB's username and password.
I'm not a developer, but need to fix an app that is based on .NET (2.0) and MySQL. I have searched quite a bit, hence the question.
Checked everything on staging, and it seems to be working fine. However, when move to live, users cannot log in. Exact same setup, just change the connection string and connects to the staging database and user log in. I also know that in both circumstances a connection to the database is being made. Users can register and are added to the database.
I believe the same happens when the .NET applications connect to a SQL Server database, however, it is possible to change "applicationname" in the web.config.
So the questions are:
Is there also an "applicationname" change for MySQL?
Could there be anything else causing the problems?
I have a single website that can be reached on our development system and my local machine. By modifying my hosts file I'm trying to make SSO to work. It simply doesn't, despite the two sites are being practically identical.
The odd thing is that SSO only doesn't work when the other copy of the website is hosted on that particular development machine. If I set it up on an other machine and my local machine, SSO works flawlessly.
The only difference between the development system and my machine is the operating system and the fact, that the website is precompiled on the development machine.
It's also interesting that SSO works when every site is hosted on the development system.
Is there anything on a machine or web site that influences the encryption and decryption of forms authentication cookies other than the machineKey section of web.config?
It's worth noting that the length of cookie values generated by the development system and mine are different. Cookies generated on my machine are almost twice as long usually.
Make sure to even out the "forms" node by all attributes, i.e. entries in both application web.configs should have identical "forms" nodes
That particular machine (or all other machines) have installed the MS10-070 update, also known as the fix for "ASP.NET Padding Oracle Vulnerability" (CVE-2010-3332).
Run Windows Update on everything and it should sort itself out.
I have an existing app in production that uses SqlMembershipProvider and has a specified machine key:
<machineKey validationKey="..." decryptionKey="..."
validation="SHA1" decryption="AES"/>
It runs under .Net 2.0 AppPool currently.
I'm writing a new application that has to use the existing database, which I have a backup of. I'm trying to get SqlMembershipProvider working with it (which it does) but I can't get a known username/password working. This account works in prod, and the password hash and salt are the same on both databases (prod and mine). However at the point where the SqlMembershipProvider compares the password from the database with the hashed password entered, they aren't the same.
This article suggests breaking changes with the default hashing algorithm in ASP.Net in .Net 4.0:
http://www.asp.net/learn/whitepapers/aspnet4/breaking-changes
However I am already specifying a machine key as suggested. Further, I've stripped out the .Net 4.0 components and dropped it back to 3.5 (which is CLR 2) and the hash of the entered password is still the same.
Furthermore, I tried redeploying this new temporary app to the same server production is on, and it still fails to login (although I can't verify if it fails due to password hash mismatch).
What else can I try here?
You need to specify the hashAlgorithmType of the membership provider in the web.config as the default has changed with .net 4.
The value that you want is most likely SHA1.
Please see the following page for more details: http://geekswithblogs.net/DavidHoerster/archive/2010/06/15/asp.net-membership-password-hash----.net-3.5-to-.net-4.aspx
First copy the production app to dev/test and run it there to see if it works as expected.
If it does, proceed to upgrade the project to run under .NET 4.0, but do not modify any other code (ie. don't try to make it work with SQLMembershipProvider) - retest the application
If that works, you know it's not an environment issue, and it's not a .NET breaking change issue, which would point to something in your code not working as you expect it should work. My guess is that the hashing algorithm you're using in the new application is different from the one being used in the old application. Were you salting the password in the old application? Are you using the same salt in the new application?