I've a code to persist information in cookies about users like UserName and password.
Question is:
Its not secure to store information like that plain text in cookies.My DB store hashed passwords,so i could save those hashs in cookies and retrieve them later,but if i do that i wouldnt be able to fill password's textbox cause the hash string would be too long for it.
Is there any solutions?
You never should store Passwords in plain text, and even a hashed password can be vulnerable to reverse-lookup unless it is salted correctly. ASP.NET Forms Authentication already lets you create a Persistent authentication cookie that will allow the user to stay logged in, so you should use that instead. See the Timeout, expires, and IsPersistant properties when Creating the Forms Authentication Cookies.
Alternatively you could setup a token based authentication system, by which users get a security token after they enter their login information and this token is valid for a specified amount of time. This is how Live ID and Google Accounts work, and they usually store the tolken in a cookie that is valid for weeks at a time.
Related
I'd like to know what kind of content is stored in this cookie. I'm trying to make a login prompt for my flutter app, but for Data protection guidelines I'm not allowed to store the password of the website in the app (as hash) and now I'm trying if I can get determine if a user has entered the correct password out of the cookie or not.
I am a beginner of asp.net. I currently have a login page with forgot password link button on the bottom of the screen. I am also using forms authentication to prevent an unauthorized user from accessing the other pages. The authentication seems to be working fine except for one thing.
How do I retrieve my password from the user list?
You don't want to store or retrieve the original password for security reasons - asp.net should be storing a hash of the original password in your data store. When a user enters their password again, the configured hashing algorithm should hash it to the same value as before and it matches the stored hash on the backend to authenticate.
See also Asp.net MVC - How to hash password for more background.
I am reading on form authentication in ASP.NET and cannot understand some moment:
James enters a username-password, they are saved in the db. A cookie from username is created, encrypted and attached to a response. As I understand then, when we get a request we need to recognise that cookie received are from James and so we can show his customised page.
What I would like to understand is how system will retrieve username form cookie and then load his info from db?
Forms Auth is storage agnostic. It doesn't have to use a database, indeed you can use it with usernames and passwords in web.config.
So what happens is
A user logs in.
The user is authenticated against the membership provider (which can use SQL, Active DIrectory, web.config, Oracle, MySQL, whatever)
A forms authentication token is created for the user, and is placed on the user machine via a cookie.
Each subsequent request reads the forms authentication token, and queries the provider to get the user details.
The user details are used to populate the user identity in the HttpContext and current thread for the request which is then available to your code to use.
In your code you can check the User property in the Page class (WebForms) or the User property in the controller class (MVC).
While you can get at it via the current thread, or the current context it's not advised, especially once you start using background tasks, where the identity may not propagate to the thread, or the context may change.
You'll note that nothing is stored in a database when the user logs in. It's all in the forms authentication token, and the work of retrieving the user from it's store on each request is done for you.
Afaik Forms Authentication does not store or load anything in any database. You can use a database to store the username and password, or you can put them in the web.config. How you store user credentials and validate them is up to you, and can happen separately from Forms Authentication.
Once you have validated a user (against database or some other logical storage), you use FormsAuthentication to write the authentication cookie. You do not need to worry about decrypting the cookie.
You can get the username from System.Threading.Thread.CurrentPrincipal.Identity.Name. To retrieve user's info from the database, you would query the database using the value if the principal identity name.
Response to comments
Right, you can use forms authentication with the membership provider, active directory, or your own custom user database. FormsAuth doesn't care about the password at all, unless it is stored in web.config (as noted in blowdart's more complete answer). It just writes the cookie, which is decrypted and used to create the thread identity automatically.
Additional Info
Even though this was marked as the answer, blowdart's response is much more complete. You really should not get the identity from the thread if you need it in an ASPX page or MVC controller, use the properties he referenced.
You get the username in your web form by calling User.Identity.Name, e.g. like this:
protected void Page_Load(object sender, EventArgs e)
{
string userName = User.Identity.Name;
}
ASP.NET interprets the cookie for you, you don't have to read it yourself. Or is your question how to store the user and password in the DB?
how to auto login the user like in facebook.
what i mean that if the user ticks remember me then next time he will be auto logged in
thanks
How websites like Facebook do it is by storing a cookie on the users computers/browser. Which stays there until it is deleted or expires. When the user then visits the Website your code will read the data from the cookie and authenticate based on that information. You could be storing a Token for example which you save to a database so your can see that it represents the user, this is just a idea. Just to be safe you should maybe also consider encrypting the data in the Cookies. Be careful about just reading Cookie's, they are easy to change and can give you some serious security problems.
So it depends if your rolling your own custom authentication, in which case you need to create the cookie and check for it. Or if your using ASP.NET FORMS for authentication in which case you can look here - How to get the asp.net login control to auto authenticate a previously authenticated user?
Use a persistent cookie (or HTML5 local storage like Stack Overflow does) to store some reference so that you know who has authenticated in your back end.
You need to set a cookie when the user logs in and set its expiration time in the future. Until the time elapses, your application would recognize the user.
I'm making the assumption you'll be using Forms Authentication.
If so, take a look at the System.Web.Security.FormsAuthentication class.
Specifically - these two static methods:
bool Authenticate(string username, string password)
void SetAuthCookie(string username, bool createPersistentCookie)
Setting the createPersistentCookie to true will persist the session cookie across browser sessions.
I want to enable Facebook authentication and the FB-Graph in my website, which already has forms authentication. Using http://multitiered.wordpress.com/2010/08/05/getting-started-with-the-facebook-c-sharp-sdk/, I was able to figure out how to login server-side.
However, the problem with this approach is that a secure cookie will not be created, since the call returns the authentication code in the querystring via a callback. This means that the user will have to login every time.
I can see two ways around this:
Store the access token in a secure cookie manually
Instead of the above approach, use the FB JS API to login - this stores a secure cookie with the access token automatically
I would prefer not to use the second approach, as I would like the login code to be server-side.
Which would be the better approach? Am I missing something?
I use the JavaScript method to first authenticate the user, the JS SDK then writes an encrypted cookie (called "fbs_[YourAppID]") when a connected user hits your page; using one of the many Facebook c# SDKs, this cookie can be decoded using your application secret giving you the user ID, oAuth token, expiry date etc.
Then I hook into the AuthenticateRequest event of my .NET application, check the presence of the cookie, decode if it found, and then find a user who has been assigned this facebook ID (your user table must have a extra field for storing the ID of their facebook account).
If a match is found, I write a normal forms authentication cookie for this user, then .NET will recognise them for all future requests. If no user is found, then this is a brand new user who has just connected. Use the SDK again to query the graph API using their oAuth token, get things like their name/email etc and create a new account, then issue a authentication token as normal.
By writing a normal authetication cookie, the user will stay logged into to your site for all requests, just as if they were a normal user.
One side point, when using email address, check for duplicates, and check for the facebook cookie in all requests. For example, an existing registered logged in user may have just connected.