The off-the-shelf ASP.net Membership Provider and tables do not appear to be PCI-compliant. Has anyone already implemented a PCI-Compliant Membership Provider for ASP.net? In particular, I am looking at the requirements for section 8.5:
8.5.2: Is user identity verified before performing password resets for user requests made via non-face-to-face method?
For this I am thinking an email with a reset token valid for no more than X hours. The default provider just generates a random value and sends it via email (although we could enable Security Question/Answer to fulfill this requirement).
8.5.5: Are inactive user accounts over 90 days old either removed or disabled?
Default provider does not support this action. We could tie into the OnLoggingIn to do some checks prior to allowing to the login attempt to proceed.
8.5.9: Are use passwords changed at least every 90 days?
Should be able to check this OnLoggedIn. If last password date > 90, redirect to the password change form instead of the desired content.
8.5.12: Must an individual submit a new password that is different from any of the last four passwords he or she has used?
I do not believe the membership tables for the default providers support this. We could add a password history table and stick an entry in every time someone creates a new password. These could then be checked in the OnChangingPassword event of the ChangePassword control.
I am fully capable of doing this myself, but if there is already something out there I'd like to take advantage.
Couldn't find any out-of-box solutions, so will be following James's advice and writing my own.
Related
I'm just looking into ASP.NET Identity, which seems that it is the most preferable solution for user authentication in ASP.NET apps these days (replacing all the ASP.NET Membership stuff from the past).
I am looking for a solution that would allow to maintain information about anonymous users. Even if the user is not authenticated, we can collect and store most of the profile data that we could store if the user was authenticated.
Even if the user is anonymous, it makes sense to store data like:
shopping cart
comments he's written on the site (so that he can edit them as their creator)
various site preferences (his preferred language, and many other settings)
Then when the user registers, we can offer to copy some of this data into his new user profile (or copy it automatically) depending on what data it is.
Is it possible to achieve this scenario with ASP.NET Identity? It seems that when a user is anonymous in ASP.NET Identity, he cannot have any user profile data.
In order to use the same tables to store all this information as for authenticated users, we might need to create a new user in the system for every new visitor that comes to the site and does some action that requires storing of some user data.
After that, we'd need to pass some cookie identifier to the user, so that we can always connect the data to the user, which can be seen as some form of authentication (although invisible to the actual user). That way, the guest user could actually represent an authenticated user of the system (maybe he'd just have a special role?), even though to his knowledge he's anonymous.
What do you think about this approach? Are there any ways where ASP.NET Identity can help with this?
I found these two related Stack Overflow questions, but I haven't found my answer in them:
Does ASP.NET Identity 2 support anonymous users?
ASP.NET Identity - Anonymous profiles
Edit:
I discovered that there's a mechanism called Anonymous Identification in ASP.NET that seems to solve part of the issue.
https://msdn.microsoft.com/en-us/library/91ka2e6a(v=vs.85).aspx
Maybe it can be somehow integrated with ASP.NET Identity?
Edit2: As noted in the comments, the documentation for Anonymous Identification seems to be outdated and it's quite probable that Microsoft will not be focusing on this much in the future. Solutions that work with ASP.NET Identity or other OWIN-based solutions are preferred.
Asp.Net Identity has no such thing, and it will not be secure identify the anonymous user even through hip IP or a Cookie in his browser, you can ask the user to register with very minimum info or through FB or Twitter to make the registration process as short as possible, and later he can complete his profile, this way you will make sure the data is linked to an actual profile.
ASP.NET profile properties allow your application to track and permanently store user-specific information. For example, users can specify a postal code or a favorite color scheme, and your application can store that information and retrieve it from anywhere in the application. ASP.NET automatically matches the current user — whether the user is anonymous or logged on — with the personal information that is stored for their user account.
Configuring Profile Properties
You will begin by configuring your application to enable profile properties. You will then define the first property that you want to track for each user. This property is named PostalCode and will be tracked for both anonymous and logged-on users.
Source: https://msdn.microsoft.com/en-us/library/taab950e.aspx
I am creating a new asp.net MVC 5 application. Authentication is handled by a third party using smart cards. Once a user is authenticated by the third party, I am sent the user's unique ID (inside the http header) which I match up against my database in order to find relevant information about said user (roles, display name, etc.).
Currently, on every page request, the sent user ID is compared against the database, and checks are performed to ensure the user has the proper permissions to view the requested page. While this works, it sure seems like a bunch of needless database hits when all the user information could just be stored in a cookie.
If I was using Individual User Accounts for authentication, what I am looking to do would simply be built in using Identity and OWIN. But since I am not handling the authentication, but merely the authorization, is there a way to use all the nice features of Identity and OWIN (claims and cookies specifically)? If not, how might one go about this?
Also, of particular interest to me is when a role is added or removed. Using OWIN with Individual User Accounts, updating the cookie is as simple as logging the user out, and then back in immediately in the background. That functionality would also be desired for any solution presented.
Any insight would be extremely helpful. Thanks for reading!
You could do what you're asking by directly storing values in a custom cookie, but for your purposes it sounds to me like you might be more interested in utilizing sessions to track that info. This will keep all of your actual data stored server-side, which is more secure as it isn't vulnerable to cookie modification and it allows you more freedom to control the state (for your role example, you wouldn't have to "update" the cookie at all, just update the session variable on the server side to add or remove the role as needed).
Figured it out. Found a great article that really helped:
http://www.khalidabuhakmeh.com/asp-net-mvc-5-authentication-breakdown-part-deux
Here is my problem if i can call it that way.I have implemented authentification with custom memebership provider in asp.net mvc 2.0.Everything works well but i have one problem.When user log in he provides its username and password and i check this through databse in MSSQL then i validate user and pass and use FormsAuthentication to set only UserName as profile information.
But when that user wants to create new item(lets say for sale or something) that belongs only to him and can be listed with other items that user created i can use this username(in FormsAuthentication) check it in database and connect that item to appropriate user with foreign key but that works if username is unique so i need additional informations like ID column from database table "user" to store and use it later so what is the most secure and "best practice" way to store additional information of user and use it later because username as i mentioned must be unique in database and it is not enough information about logged user.
Couldn't you store the User object (or whatever additional info you have) in the Session? or using a cookie at the client side (if you need to persist the login state even after the user closes his browser etc)? Let me know if you need specific examples.
EDIT: After reading your comments, if you are looking for a "secure cookie" solution have a look at this: http://www.codeproject.com/Articles/13665/HttpSecureCookie-A-Way-to-Encrypt-Cookies-with-ASP
I use it to store the user's id (only his id). When I retrieve this cookie I load the user given his id. Some in-memory caching allows me to avoid loading the user on each request.
But just wanted to clarify that the session object seems great for what you are trying to do + you dont have to worry about security (for the average app that is).
In a generic asp.net website with Membership, Roles and hashed passwords enabled, I would like to provide the administrators with impersonation so that they may browse the website as that user would. The website should function as if that user is logged on and then be able to revert to their own login.
What is the best approach to achieve this?
An example use-case: A website with two types of users: 'Buyer' and 'Admin'.
The website provides a 'Purchase' button to buy something specifically provided to the user by the admins. i.e only that buyer can use the purchase button and make a payment.
User has trouble so a support admin can 'impersonate' the user's login and purchase on their behalf or 'see' the trouble they are facing.
Without impersonation, the only way is to allow this in code and that negates the purpose of 'seeing the user's issue'. Not even if I was not using hashed passwords and had used FormsAuthentication.SignOut() and manually logged in the admin as the user.
I hope i am making sense above.
Take a look at this sample on codeproject.com. I think it does what you're looking for.
I don't have the code we used to do this in front of me (assignment from a few years ago), but there are bits in the Membership API to sign someone in using code. I will not have access to the code until this weekend, unfortunately, or I could quickly share the bits and be done with this.
I do remember you had to get the user first, as a MembershipUser, using the Membership class. I am not sure, from this point, whether you had to validate against provider or what.We did use a custom provider, but I forget whether it was related to this solution.
Regardless, examine the security bits, focusing on membership and membershipUser.
Encouraged by SO, I'm trying to write an ASP.NET site that uses OpenID for user authentication. It's a regular WinForms site (not MVC.NET), using the DotNetOpenId library for authentication.
Is it safe for me to permit/deny administrative functions on the site by simply comparing the current session's "ClaimedID" (as returned in the OpenIdLogin_LoggedIn event, as member DotNetOpenId.RelyingParty,OpenIdEventArgs.Response.ClaimedIdentifier) to a known administrator's OpenID (i.e. mine)?
If so, is it safe for this ID to be visible (e.g. in open source code), or should it be "hidden" in a configuration file or a database row? (I know it's better design to make it configurable, my question is just about safety.)
My solution is to follow the same idea of the Roles table. After you've authenticated the user, look up that user's roles. If the user has role "Administrator" in the UserRoles table, then they can do whatever the Administrator can do.
I don't broadcast open ID's in my app. They're stored in the table. On every action result, I'm hitting the Users table, since I have also modified mine to store various user state information. With the exception of the home page, there is going to be some user information that I need from that table. I'm using LINQ, so I include the .LoadWith() to load the User with his list of roles when it serializes.
Jarrett makes some good comments about using database tables.
Just to answer another one of your questions, no, it's not a confidentiality thing to put your OpenID in your code generally. If setting up roles seems overkill for your site, a simple equality check against your ClaimedIdentifier is just perfect.