First off, I am not using Forms Authentication.
I found a great tutorial that almost does what I want:
http://www.codeproject.com/Questions/358434/Keep-me-signed-in-until-Loggged-out
The only problem is that it does not seem like a good idea. It stores the username in the cookie. That seems very bad.
How could I do something like this tutorial but in a safe way?
I essentially just want this basic flow:
if user logged in then show page
User can have the option of being logged in for the session (30 mins of inactivity) or until they choose to explicitly logout.
I have a feeling I will need a session table in my db for this, but I am not sure.
It doesn't have to be top of the line security since this is for an intranet, but I do still want it to be somewhat safe.
Thanks
Easiest way is in your Login function, once you have verified them just add:
FormsAuthentication.SetAuthCookie(theUserName, persistCookieBoolean);
Now you have an authentication cookie set. No encrypting or decrypting needed. Get the username like:
HttpContext.Current.User.Identity.Name
And see if they are logged in:
HttpContext.Current.User.Identity.IsAuthenticated
And now you can set authorization easily in the web.config too. Related post: Manual Access control in ASP .Net
Encrypt your data (username, etc) before storing in the cookie.
Read the cookie, decrypt the data & then validate.
Check this:
Encrypting & Decrypting Data in .NET Applications
Encrypt/Decrypt string in .NET
You can use Sessions.
Example Code VB:
On login do:
Session("Username") = "username"
Then each time on page load check if Session("Username") has any data/is not null.
If it's null or empty then the Session has expired and you can kick them out of the page.
Related
I have a website with two different domain.
us.site.com
usa.site.com
Now when user Click on Login
It first check its country. According to country I want to redirect whole site on that url and that time it not again asks for account id and password. so i want to maintain these things but it should not visible in Url.
Please Suggest me any way to do this.
I don't want to use QueryString and Cookie
Posting my comment as an answer.
Basic idea as following. You can use cookies. On login, create a cookie for "site.com" having user information. When user redirects to for say login to usa.site.com, check the cookies in pageload. If you found the cookies read the cookies and convert it to session. Use session further to check loogged in user information.
Related question link,
How can you keep a session across multiple subdomains in c# mvc?
How can I share a session across multiple subdomains in ASP.NET?
Write cookies from subdomain and read from another subdomain without changing web.config
To make cookie secure use encryption.
Reference :
http://www.codeproject.com/Articles/13665/HttpSecureCookie-A-Way-to-Encrypt-Cookies-with-ASP
Encrypt cookies in ASP.NET
http://www.c-sharpcorner.com/UploadFile/manishkdwivedi/encrypting-and-decrypting-cookies-in-Asp-Net-2-0/
Use MD5/SHA Encryption to store value in cookie and once you redirect to other page then use decryption Algo and use that cookie value.
It will solve your issue.. Check below link for reference -
http://www.codeproject.com/Articles/38951/How-To-Hash-Data-Using-MD-and-SHA
http://www.codeproject.com/Articles/14150/Encrypt-and-Decrypt-Data-with-C
http://www.codeproject.com/Articles/12602/Using-MD-Encryption-with-C-and-MSSQL
Or you can use alternative way to store value in database temp table
I read the documentation of Nancy Forms Authentication. As far as I can tell, the approach recommended there leads to lifelong session IDs:
"The identifier is the token that will be put in the authentication
cookie which will be used to re-establish the identity of the user
that is performing the request, so that you do not need to enter your
credentials for each request."
As far as I understand, that "identifier" is what most people call a session ID.
It is also important to know that the identifier should be treated as
permanent for the user that it was generated for and will be reused
across requests and application sessions.
Is this really the recommended approach? If I understand correctly, this means that session IDs never change and never expire. So the session ID is the equivalent of a password, which
is retransmitted in a cookie with every request
is probably stored in clear-text in the DB, if you follow the docs to the end
I know that I could implement this differently with Nancy, but my point is that such an approach should not be explained in the docs as reference.
So if an attacker ever succeeds in stealing that session ID, e.g. by an XSS attack, he gains lifelong access to the system.
Please correct me and show me the mistake in my thoughts!
The identifier you are referring to isn't a session id, it's an unpredictable user identifier, which is then mapped (if necessary) to the real user identifier in the back end. This is so if someone logs in as user X, and somehow manages to decrypt, re-encrypt and re-sign the cookie they can't just change the user ID to "admin" or something similar and gain admin access (which is how the ASP.Net Oracle attack worked). It's also HttpOnly, so not really capturable via XSS, although technically it could be captured using XST.
Creating and expiring a session (and deleting the auth cookie if necessary) is a different task altogether - how and when you determine if an auth cookie should be accepted, removed, or confirmed with an additional password request is application specific. This is a common pattern now where a site will consider you "logged in" eternally, until you do something "secure", in which case it will ask you to revalidate if you haven't done so recently.
Hope that makes sense.
that "identifier" is what most people call a session ID.
It's not. It's something like UserId. as the documentation states:
We have chosen to use a GUID as the identifier. The reason for this is that using something like the username of id is a potential vulnerability, because, if the cookie encryption was somehow compromised, it would be easy to spoof the identity of another user by guessing their username or id.
They're just using a GUID assigned to the user for more security. Of course, (cookie based) FormsAuthentication has all the disadvantages of cookies. If someone can get access to your auth cookie, they can authenticate themselves as you. But session cookies and forms authentication cookies are completely different things, This answer states the differences pretty clearly.
I am new to stored procedure and asp.net world.
I have 'USER' table with three fields,
#id,#username,#password
I have created login page with two textbox, if the username and password is correct it is redirected to next page.
But how to pass #id value to next page, so that i can display 'USER INFORMATION' in that page.
all i want is writing asp.net c# code for the store procedure .
It sounds like you're reinventing the wheel. Is there any particular reason you're hoping to roll your own login system? ASP.NET provides a very good login system, which might be worth looking into.
The following link shows you how to use ASP.NET basic user login system in your website
Walkthrough: Creating an ASP.NET Web Site with Basic User Login
As a side note, if you do decide to develop your own login system for what ever reason PLEASE do not store the users password plain text! This is considered EXTREMELY bad practice. What you should do is use a hashing algorithm (NOT encryption) like SHA512 on the password and then store the result of that. Then when you go to login, you hash the password they are trying to login with and compare it to what you have stored. Ideally you should also Salt your hash but at the very least you should be hashing it.
But how to pass #id value to next page
You can store Id in session variable. Check session variable on page_Load event if it is not null load the information you want.
I am new to stored procedure
Why do you want to use store procedure for login?
i Think this litle tutorial is all that you need :)
http://csharpdotnetfreak.blogspot.com/2012/06/login-page-form-example-in-aspnet.html
Use Postback to get the userInput. Then send the data to your stored procedure.
If password correct Redirect and set session/cookie-information.
else just set an error message on the site.
more reading on Postback and viewstate.
http://delphi.about.com/library/weekly/aa051705a.htm
Probably my question is stupid but it is driving me crazy, you see I have this application its session is not expiring after logging out even though I have used Session.Abandon(), Session.Clear(), and Session.Removeall(). I have been searching all over the internet but no luck so far and I really wish I can get some help. Say I have user X if I do the following any one can login with X's account:
1- Login with X's username and password.
2- Take Session ".ASPXFORMSAUTH" info.
3- Logout from X's account
4- Add the Session ".ASPXFORMSAUTH" with its value using fire fox "add cookie function" for example.
5- type the URL and click enter
the page just opens up and it is really driving me CRAZY!!
Thanks in advance
You also need to call FormsAuthentication.SignOut()
In this case, you have an additional flag in Session (like "ACtive") which can be set to false during logout. Based on this, you can rediect the user to login or any other general page you want to..
I am not sure if there is defined way to handle this, but I would do something like I said.
Scenario where the user is already logged out by using FormsAuthentication.Signout() and is trying to hack the system by using the same cookie (he somehow got access to it) to access a authenticated part of the website.
In such a scenario recommendations from Microsoft also suggests to use a persistence mechanism to log / track the user signout and use the information to redirect him to login page (and clear cookie again) in subsequent fake requests.
Reference: Read bulleted point 3 in Remarks section
Currently, I'm using the FOrmsAuthentication.SetAuthCookie to store an Id so I can use it on the next page that is "Authorized" (using custom authorizeattribute controller). But I'm currently thinking of making a custom cookie using httpcookie so I can store more data, or easily maintainable data. Was wondering if having the kind of cookie will I be able to authorize the current user to access the "Authorized" controllers? If so how do I go about it.
Hope that made sense.
Please let me know your thoughts.
Just put your extra stuff in a different cookie. And if forms auth says the user isn't authenticated, don't read the other cookies. No need to overload the purpose of the auth cookie (and non trivial to do so securely)
There is a UserData property of the FormsAuthenticationTicket. It is a string so you will have to be able to serialize/deserialize any complex data.
Good security design says dont store this information in a cookie - figure out another way (server side). Recently (octoberish) the ASP.Net POET vulnerability taught us that forms auth tickets could be forged because the machinekey could be determined and hence data encrypted as it would be on the server. I know - not exactly what you asked but I think it's important to not store sensitive data on the client side.