I have created a self-hosting site using Nancy and Owin. I used Nancy.BasicAuthentication for authentication. Everything works fine until I change the current logged in user's password.
Once the password is changed, if the user creates a request then they are redirected to the 404 error page and the window pops up asking for a username and password.
How can I update the user's credentials after a password change to stop them from losing authentication?
Thanks!
a) Basic auth is very easy to listen in on - consider digest auth instead.
b) Both basic auth and digest auth work on a page by page basis - every request is authenticated individually (the browser just automates the authentication if it already has the credentials)
c) Hopefully a 401 Authentication Required, not a 404 Not Found is returned?
d) I suspect doing anything to allow a previously authenticated user to continue using a site after the password is changed (e.g. cookies) would require code changes to the authentication handler. You could for example set a cookie (crypto required) when a page is successfully authenticated, then not require authentication for further pages if the cookie is available (with a timeout on the cookie).
Related
I've a sub-application that I want to use windows authentication.
I want that login box pops up even in the domain when the person first reaches the page.
When I turn off Kernel-mode authentication, the login box pops up, but fails with error 401 Not Authorized after 3 login attempts.
If I turn this on, It doesn't even asks for the password,I believe this is due the computer is in the servers domain and the credentials are passed automatically.
Is there any possibility to show login form for all users, including domain users?
In the image below are my server configs.
Windows Authentication is normally handled by IIS. This is the way it works:
Client requests the page.
IIS returns a HTTP 401 response, with a header saying that it accepts Windows auth.
The client's browser automatically resends the request with the users credentials (as long as the site is trusted).
IIS verifies the user and passes the credentials to the application.
This is all designed to be seamless.
If you want the user to be prompted for credentials all the time, then either:
Make sure your site is not trusted (not in the Internet Options Trusted Sites or Intranet Sites). But you may not be able to do that.
Don't use Windows authentication. Uses Forms authentication and make a login page where the users can enter their credentials. But that means that you will have to verify the credentials against Windows or Active Directory yourself in your code.
If you use #2, then also make sure to use SSL on your site since passwords will be sent in plain text.
You can use Basic authentication. It will prompt the user for credentials and once entered, it will give you a seamless experience.
However, the disadvantage with basic auth is that it sends the password in plain text to the server. You can use SSL certificate to encrypt this information.
Is there a way to remove the authentication cookie, or sign a user out once they are removed from the asp.net membership database? By default if a user is removed from the database, the user can still browse the website since they still have a valid authentication cookie.
I've tried different things within global.asax but nothing seems to work. Is something like this even possible?
See here: FormsAuthentication.SignOut Method. Although this refers to users not being logged out server side, a similar approach can be used for managing deleted users.
Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie. To improve security when using a forms authentication cookie, you should do the following:
Use absolute expiration for forms authentication cookies by setting the SlidingExpiration property to false. This limits the window in which a hijacked cookie can be replayed.
Only issue and accept authentication cookies over Secure Sockets Layer (SSL), by setting the RequireSSL property to true and by running the entire Web site under SSL. Setting the RequireSSL property to true ensures that ASP.NET will never send an authentication cookie to the browser over a non-SSL connection; however, the client might not honor the secure setting on the cookie. This means the client might send the forms authentication cookie over a non-SSL connection, thus leaving it vulnerable to hijack. You can prevent a client from sending the forms authentication cookie in the clear by running the entire Web site under SSL.
Use persistent storage on the server to record when a user logs out of the Web site, and then use an application event such as PostAuthenticateRequest event to determine whether the current user was authenticated with forms authentication. If the user was authenticated with forms authentication, and if the information in persistent storage indicates the user is logged out, immediately clear the authentication cookie and redirect the browser back to the login page. After a successful login, update storage to reflect that the user is logged in. When you use this method, your application must track the logged-in status of the user, and must force idle users to log out.
The third option is the most secure but requires the most effort. IMO, the first two do not resolve the issue adequately.
It is also possible to store custom information in the Forms Authentication Ticket. You could store the last explicit logout time in this ticket, and check it against your server side database record. Please note that if this record is at user level instead of session, then all logins under that account would be logged out at the same time.
In your case, if you are deleting server side user and session records, as the record does not exist you will be able to also fail the authentication request.
I'd advise also storing and checking the last date/time the password was changed - that way if a user updates their password then all existing sessions are logged out.
I have configured thinktexture identity server which is connected with my database for authentication and returning the claims in response.
Now I am able to use STS in my website. Behavious of STS is, user is getting redirect to STS website login page for authentication and response is getting retun to my website after successfull login.
I want to implement a little bit different. I want to use Login page from my website itself instead of using this from STS so that stsyle and theming can be displayed as per my website.
Also want to implement many other password control features ie Password expiry warning, force change password etc can be implemented within the website.Please suggest the approach
Look into the WS-Trust endpoints that IdentityServer supports.
After a lot RnD, we finally reach at conclusion that it cannot be achieved.
It will always redirect to identity server URL for authentication.
In asp.net, I am able to login using forms authentication as usual, copy our auth cookie value, log out, add the cookie artificially to the client using the 'Edit This Cookie' addon for Chrome, refresh the (anonymous) landing page and hey presto i'm logged in again. This seems to be a vulnerability - is there any way of fixing it using the the standard forms auth or will I have to do something like use a custom Authorize attribute which overrides the existing one in asp.net mvc?
I don't think this is a bug per se. The following happens during forms authentication
You provide a username/password to the server
Server validates username/password
If valid, the server then sends an encrypted authentication ticket (cookie) to the client with the expiration time (set in the web.config forms authentication section) and username (all encrypted)
On each request that requires authorization, the cookie is decrypted on the server, expiration time is checked and username is used to see if authorized (or getting that role for the requested resource).
When you logout, the expiration time on the cookie is set in the past, therefore, it is not longer a valid cookie
Now, as to why you are seeing what you are seeing... You are copying the cookie before you logout. Thus your copied cookie never registers the logout (moved expiration time). When you reattach, you still have a valid auth cookie. Now, if your forms authentication timeout is set to...let's say 20 minutes...this method would fail if you copy the cookie and wait 21 minutes as by that time, it has expired.
Cookies are always vulerable and we can't do much about that. What we can do is prevent someone from stealing the cookies.
Regarding ASP.NET MVC it does a good job to avoid stealing cookies. Some of the main things it does by default as part of security are:
Encode the strings that are rendered to the view (if you are using Razor don't know about others) to prevent from XSS attacks.
Request validation (stop potentially dangerous data ever reaching the
application).
Preventing GET access for JSON data.
Preventing CSRF Using the Antiforgery Helpers
Regarding cookies Microsoft provides HttpOnly feature and this helps to hide the cookies from javascript. The Forms authentication that you are talking about is a HttpOnly cookie means someone can't steal that through JavaScript and it's more safe.
You can do that with any cookie/s. You can inspect/copy all the cookies from any given domain, and spoof if you want. You can do that to yourself (only) because its your PC (or user logged in to PC). Obviously if you're on a shared PC, that is a problem (across all your info).
The act of "copying your cookie" is in fact one way malware attempts to steal/hijack your identity (or current session on some web site). That said, unless you have some malware, you can't just "copy cookies" of someone else.
Assuming logout is done, you can ask users to close their browsers so the expired cookie is removed from the (file) system.
I'm trying to add LDAP support to an existing ASP.NET website that uses Form Authentication. This is not a big problem, I just build a simple login dialog (ordinary HTTP POST), query the LDAP directory and log the user in via Form Authentication ticket.
It would be extremely nice to automatically get the users credentials via NTLM (Integrated Windows Authentication) without the need for a login dialog (like what you get when using ASP.NET Windows Authentication with computers in the same Active Directory). Is there an easy way to do this (keep in mind, I can't use Windows Authentication for my ASP.NET app and the server is not in an Active Directory Domain, I need to be able to query LDAP directory manually)? Or would I have to manually do all the LDAP handshaking / challenge/response thingy?
Thanks for your help,
~ saxx
I do just this on my intranet here. These are the steps I use...
Create a login page (login.aspx seems good) & set the web app up for forms authentication. Set authorisation as deny anonymous. These means any attempt to use your app will cause the user to be redirected to your login page if they don't have a auth ticket.
Now the important step. In IIS, set the app to allow anonymous only. On your login page change this to only be Windows Integrated. Now what happens is when the user is bounced to your login page, IIS forces an NTLM authentication. We now have the users name in the headers.
2nd important step. in the page_load method add:
FormsAuthentication.RedirectFromLoginPage(Request.ServerVariables["Logon_user"], false);
What this does is take the username IIS will always give us and put into a forms auth ticket.
There's of course a certain amount of tidying up you may want to do, perhaps adding a logout feature, or stripping the domain name of the username.
Simon