I have 2 projects. One of them is using ASP.Net authentication, the other uses Windows authentication, which is the administration side. I want the Admin project to be able to manage the users of the other. I can modify everything except the password.
If I use UserManager.PasswordHasher to create a new hash and update the AspNetUser, I cannot login with the new password (I can see the update has occurred). I tried to incorporate Asp.Net users in the admin project but it's messing with the Windows authentication.
Is this a salting issue? Is there a way to do a simple model update that will update the password hash correctly without re-implementing the entire Identity model?
Something like should work:
user.PasswordHash = UserManager.PasswordHasher.HashPassword(newPassword);
UserManager.Update(User);
I am running a ASP.net MVC 3 web application, and using the Membership Provider. I would like to know if its possible to allow the user (or administrator) to change an existing accounts username? I have not found a way to do this. The username is not an email address, but is validated on its uniqueness prior to my attempt at assigning the new name.
Any help would be appreciated!
The membership provider does not provide a method to update the username. You will either need to extend the membership providers UpdateUser method or directly interact with the membership tables to allow this change. However you approach this, keep in mind a few items
On update, you will need to check uniqueness of the username much like what happens when a user is created.
If the user is logged in and changes their username, you will either need to force them logout and log back in or reissue the AuthenticationTicket cookie. The reason being, if they change their username, then the authTicket cookie stored username and the actual username not longer match. If you use HttpContext.Identity.User.Name to query your datastore or check authorization to content, you will no longer return any results as that username no longer exists.
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.
I am having an ASP.net page with userid and question and answer
I need to verify the userid, answer is correct or not
I no need to enablepasswordretrival
and my password is hashed
how to do
Are you using the ASP.NET membership provider? If so then the system will do that authentication for you, you just need to set the appropriate permissions in each folder's web.config in your web site. Just make sure that the folder containing the login form, registration form, etc (all the content that anonymous users can get to, and yes, login needs that as they are anonymous until they have actually logged in) is set to allow anonymous users.
You can't have password retrieval with hashed passwords as it's a trapdoor (i.e. one way) encryption and can't be reversed. The only option with hashed passwords is to issue a new password.
I want to make a login system using ASP.NET (MVC).
On the internet, I found some bad examples that involved SQL in Click events. Other information pointed to the ASP.NET built-in membership provider.
However, I want to roll my own. I don't want to use the built-in membership provider, as it only seems to work on MS SQL, and I don't like the idea of having a few foreign tables in my database.
I could probably think of something, but I need a few pointers in the right direction. It does not have to be high-security, but just regular common-sense security.
And I have a few direct questions:
A lot of systems seem to have the Session ID stored in a user table. I guess this is to tie a session to a user to prevent hijacking. Do check this every time a user enters a page? And what do I do if the session expires?
Hashing, salting, what does it do? I know of MD5 hashing and I have used it before. But not salting.
Best practices for cookies?
I dont know about best practices but I can tell you what I do. Its not hitech security but it does the job.
I use forms authentication. I receive the password secured with ssl via a textbox on the login page. I take that password and hash it. (Hashing is like one way encryption, you can get hash code that cant be reversed back to the password). I take that hash and compare it to the users hash in the database. If the hash's match i use asp.nets built in authentication handling, which handles cookies for me.
The FormsAuthentication class has methods available to do this fo you, such as SetAuthCookie and RedirectFromLogin. they will set the cookie and mark them as authenticated. The cookie asp.net uses is encrypted. I cant speak for its security level though, but its in fairly common use.
In my class i do the password check and use formsauth to handle the rest:
if(SecurityHelper.LoginUser(txtUsername.Text, txtPassword.Text))
{
FormsAuthentication.RedirectFromLoginPage(txtUsername.Text, true);
}
You can implement your own membership provider using the ASP.NET infrastructure, see MSDN docs for MemberShipProvider class.
The built in provider works well. It does actually work with MySQL, although I found it not to be as straight forward as the MS SQL version. If you can use then do, it'll save you hours of work.
If you need to use another data store then I concur with axel_c, if I was going to roll my own then I'd write a membership provider as per MS specification. It will make the code more maintainable for any developers following you.
Salting is the practice of adding a unqiue string of characters to whatever is being hashed. Suppose mySalt = abc123 and my password is passwd. In PHP, I would use hashResult = md5(mySalt + password).
Suppose the string is intercepted. You try to match the string, but you end up matching gibberish because the password was salted before encrypted. Just remember that whatever you use for salt must be continuous throughout the application. If you salt the password before storage, you must compare the hashed, salted password to the DB.
You can use the built in SQL membership provider - and you could set up a dedicated "user access" database if you don't want the .Net membership tables within your database - just specify that in the connection string.
THe advantage with the provider model is at the application level, the code is independent of what particular authentication store you have used.
There are a good series of tutirials on the asp.net site:
link text
A disadvantage of the Membership Provider by microsoft is that you can't use it in a domain driven approach. If you want to, you can create your own user object with your own password hash and still use the authentication cookies provided by Microsoft. Using these authentication cookies means that you don't have to manage the session IDs yourself.
public void SignIn(User user)
{
FormsAuthentication.SignOut();
var ticket = new FormsAuthenticationTicket(1, user.UserName, DateTime.Now.AddMinutes(30), expires, alse, null);
var encryptedTicket = FormsAuthentication.Encrypt(ticket);
var authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket)
{
Expires = ticket.Expiration
};
httpContextProvider.GetCurrentHttpContext().Response.Cookies.Add(authCookie);
}
public void SignOut()
{
FormsAuthentication.SignOut();
}
I use my own user object and tables.
I store my passwords hashed in the usertable with a unique salt per user.
This is secure, easy to implement and it will fit in your design.
Your database table won't be polluted by Microsofts membership provider crap.
I would avoid the whole issue and use openid. There is a library available that you can use directly.
Here is a link to a blog post about putting this in place