I have implemented ASP.Net Identity after following the sample code here:
https://github.com/rustd/AspnetIdentitySample
In my implementation I check if a user is authenticated - this is called from a FilterAttribute on my MVC Controllers; the idea is i want to confirm they are still auth'ed before serving up the page.
So in my filter, the following code eventually gets called:
_authenticationManager.User.Identity.IsAuthenticated;
_authenticationManager is here:
private IAuthenticationManager _authenticationManager
{
get
{
return _httpContext.GetOwinContext().Authentication;
}
}
The _httpContext is passed into the constructor of my identityProvider class.
Now - once I have logged in, _authenticationManager.User.Identity.IsAuthenticated; returns true as expected.
However, during development, i dumped and re-seeded my database, without adding a user. So effectively, I have deleted the IdentityUser - yet _authenticationManager.User.Identity.IsAuthenticated; STILL returns true
any idea why this is? I can only assume it's somehow checking a cookie, rather than actually looking at the DB. is this correct?
Or have i messed up my implementation.....
This does not make IsAuthenticated a security hole. Let's look at the actual authentication process.
You setup some stuff in your web.config around where the login page is, how long the login is good for and whether or not to use sliding expiration (should the time be extended if the user is active on your site)
User comes to your site, enters their username and password.
That information is posted to your server. You take that information, verify that it is correct (authenticate). If it is correct, the server then issues an encrypted cookie known as the FormsAuthenticationTicket Note - this could have a different name in the new Identity stuff, but the same principle.
The cookie's contents includes items such as the user name and expiration date of the login.
On each request, the server looks at the cookie collection for the authentication cookie. If found, it decrypts it, reads the values and determines if this is still a valid cookie (expiration time). Once it has the user information from the cookie, the server can use this information to determine if the user is authorized for the resource requested (look up by username).
5a. If the cookie is not present, or has expired, then the user is redirected back to the login page.
6.When the user logs out, the cookie is deleted from the cookie collection. Now, if the user tries to go to a resource that is for authorized users only, then the server ends up at 5a above.
So, in your case, you deleted a user manually. This does not change the fact that this user has previously been authenticated with a still valid cookie. Therefore, IsAuthenticated is returning the expected value. The user has authenticated before you changed his user status. IsAuthenticated does not mean, is this user still valid in my database.
If you are going to be running a site where you are constantly deleting/deactivating users, then override the OnRequestAuthorization method of the AuthorizeAttribute to look and see if the user is actually still in the database. Also, note that if the username is not present (because you deleted it), then any look ups for role / userId will fail. You can catch that exception / failure and return the property unauthorized response.
Related
I am using Identity Server 4 with the quickstart UI and a client using Cookie Authentication.
Lets say I have user A on machine A who is currently logged in via the browser. Then user A decides to go on machine B and logs into that one. As it stands, a new session cookie will be issued for user A on machine B as well as machine A.
This is fine, but I want the option to mark particular users with a flag e.g. IsConcurrent and if it is set to true, they will be given the option to either keep their existing session on machine A, or terminate it and start a new session on machine B.
I have done some reading and found references here to updating the security stamp for a user and setting the interval to zero, so it checks the security stamp in the cookie against the stored version. However, this code didn't seem to be inline with Identity Server's code. Also, it it a valid option in this case?
I also found here which mentions storing and checking the value of session IDs, but I'm not sure if this is valid either?
An initial idea was to implement some middleware that obtained the Machine ID and stored it in a table along with the user, but then I was unsure how to take something like this any further.
Any help or advice would be much appreciated.
Assuming cookie based authentication, you can extend the client to validate the user session provided that the client keeps track of user sessions.
For that you can create a session manager where you add a session for the user (sub) after login, this also includes automatic login sessions (SSO). Remove one or all sessions on logout, which should also be updated on back channel logout (LogoutCallback).
Assuming you use middleware, you can consult the session manager there and decide what to do. Make sure that the current session isn't already activated after login. It has to step through the middleware at least once. Some pseudo code to illustrate the idea:
public Task Invoke(HttpContext context, SessionManager sessionManager)
{
if (context.Principal.Identity.IsAuthenticated)
{
var sub = context.Principal.FindFirst("sub")?.Value;
var sid = context.Principal.FindFirst("sid")?.Value;
// User is allowed when the current session is active.
if (!sessionManager.CurrentSessionIsActive(sub, sid))
{
// Rewrite path if user needs and is allowed to choose: redirect to session selector or
// Activate the current session and deactivate other sessions, if any.
if (sessionManager.HasMultipleSessions(sub) && sessionManager.CanSelectSession(sub))
context.Request.Path = new PathString("/SelectSession");
else
sessionManager.ActivateCurrentSession(sub, sid);
}
}
return _next(context);
}
On post of the SelectSession form you can mark in the session manager which sessions are active. If the old session should be preserved, then ignore the old session (remains active) and mark the current session as active.
Make sure to add the middleware after authenticating the user.
Please note that for access tokens you'll need a different strategy.
I have added the Asp.Net identity framework to a WebAPI which I call from a front end.
After registering an account (and seeing it appear correctly in the database) I sign in with that users username and password, the result is success but the user is not signed in according to the sign in manager?
I've tried using cookie authentication using this example: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/cookie?tabs=aspnetcore2x (adding the code snippets to the webapi) and running this on sign in which happens in a WebAPI controller action:
var result = await signInManager.PasswordSignInAsync
(username, password,
true, false); //succeeded
await HttpContext.SignInAsync("MyCookieAuthenticationScheme", User);
The documentation for BaseController explains that the User property:
Gets or sets the System.Security.Claims.ClaimsPrincipal for user associated with the executing action.
This suggests that User is determined ahead of the action being executed and therefore simply represents the user that first initiated the request (which most likely will be an authenticated user if you're using password sign ins).
In a Github issue that revolves around a similar scenario, David Fowler explains that:
...the sign in operation doesn't change the current request user principal. That only happens on incoming requests once the cookie or bearer token (or whatever thing the type of auth requires to create an identity) is set.
The fact that IdentityResult.Succeeded is true should be enough to verify that the user has been signed in, as this will only be false when the sign in operation fails. If you want to do further processing using the User property after a successful sign in, I suggest you redirect to another action, whereby this next request would include the user's sign-in information.
In my case, a call to app.UseAuthentication() was missing.
I'm using FormsAuthentication mechanizm and auth users via
FormsAuthentication.SetAuthCookie(...);
Can I logout current user from all browsers somehow?
Add a guid parameter inside to authentication parameters. Also save guid to a session table for example like this;
public class sessionLog
{
public int UserID { get;set;}
public string Guid {get;set;}
// ... may be you can add IP, datetime or isSessionClosed etc
}
When login add a row into table, save guid inside the cookie.
Check the user authentication with userID and guid is enabled.
Remove row logout with the guid or remove all with userID for close all sessions.
Technically, that's impossible. The user is authenticated via an encrypted cookie set within the browser. Logging the user out merely invalidates that cookie. There's no way to then invalidate cookies that may exist in other browsers or even other machines.
The only way you could potentially achieve something like this is to indicate in some way, tied to the user's account, that they have been logged out. This could be an additional column on your profile table or some other type of persistent storage medium. Whatever you do, you would then need to look at this when an authenticated user accesses some portion of your site. If they have been previously logged out, you would then log them out again on that browser/machine instance. When they log in again, you would clear whatever you previously set, so that they would remain authenticated. In other words, you have to check and invalidate the auth cookie in each browser when the user attempts to access the site from that browser. There's no way to do anything until the user accesses your site from that particular browser.
You need to store a list of users logged in on an application variable. If a user with that Guid tries to login again you can display a message that they are already logged in elsewhere....
I don't think you can control users session once it has been granted, but you could add logic to deny access to functionality if an attempt to login from elsewhere (I'm not sure why you would want to do it though because logging in from different devices is not always done maliciously).
I'm working on a project with Asp.Net MVC 5 and Asp.Net Identity and I'm using two factor authentication. For the login I use:
var result = await SignInManager.TwoFactorSignInAsync(model.Provider, model.Code, isPersistent: model.RememberMe, rememberBrowser: model.RememberBrowser);
which is the default code that came with the new project. However, I also need the ability for a user to "trust" or "remember" a browser, similar to how banks can indicate if this was the first time you have signed in from a particular browser/pc.
My question is around the RememberBrowser property on the sign in method and what .NET Identity does with this data. I want the list of saved browsers and the ability to revoke access to one/and-or all of them. Is that possible within the Identity framework? Also, can I tell if a browser has been "trusted" before by some type of lookup?
Edit:
Maybe it's a good idea to save the browser info in the database and check on login instead of the cookie? That way it can be shown as a list with the ability to delete it. What I'm looking for is what to save and how to integrate it with the Asp.Net Identity without having a security risk.
Edit 2
Here's an example from a website that is already using this:
Edit 3
Maybe this can be implemented as another step for authentication. So basically we'll have a 3 factor authentication:
First user logs in with user/pass
Then we'll check if the 2FA is enabled and get the code if necessary
We get the user's aser agent and IP and check the database if it's new. Then notify if necessary.
So I'm guessing an new cookie should be added to save browser's info. However, we should be able to invalidate this cookie along with the 2FA cookie.
RememberBrowser sets a cookie that allows the 2FA step to be skipped. There is no central way to track this though it would be easy enough to log, however the results may not be accurate because people can delete cookies manually. There's no way to invalidate it I believe but it doesn't really matter as you can invalidate their session and the user is will be required to login with their password again.
Not sure whether saving browser info adds value as browser info is gonna be same for different users (using same browser and version) unless you save requestor IP as well; and saving requestor IP has too many complications.
How about adding a custom claim to the token if user has set RememberBrowser and then do your logic based on this custom claim? For eg, set a custom claim your_claim_name and set a Guid.NewGuid() to it if RememberBrowser is true. Also save the username, this guid and status flag in database . When a request comes, check whether your custom claim is present, if yes query the table with the custom claim value and username to check whether the entry is still active.
You can either delete the entry or soft delete (set the status) the entry for an user so that when next request comes you can perform your required logic.
I have an asp.net web form. when a user authenticate, it create a Secured cookie called .aspxauth
uppon logout, I call these 2 methods
FormsAuthentication.SignOut();
Session.Abandon()
Problem is that we had penetration test and if I steal the cookie, logout and manually reinsert the cookie, I become loggued in again. So the .aspauth isn't invalidated server side.
I've googled it and I can't find the answer to that security breach.
Microsoft has acknowledged this issue here: https://support.microsoft.com/en-us/kb/900111
They offer several ideas for mitigating this vulnerability:
protect the application by using SSL
Enforce TTL and absolute expiration
Use HttpOnly cookies and forms authentication in ASP.NET 2.0
Use the Membership class in ASP.NET 2.0
Regarding the last one, I'll paste the contents from the site for convenience/preservation:
When you implement forms authentication in ASP.NET 2.0, you have the option of storing user information in a Membership provider. This option is a new feature that is introduced in ASP.NET 2.0. The MembershipUser object contains specific users.
If the user is logged in, you can store this information in the Comment property of the MembershipUser object. If you use this property, you can develop a mechanism to reduce cookie replay issues in ASP.NET 2.0. This mechanism would follow these steps:
You create an HttpModule that hooks the PostAuthenticateRequest event.
If a FormsIdentity object is in the HttpContext.User property, the FormsAuthenticationModule class recognizes the forms authentication ticket as valid.
Then, the custom HttpModule class obtains a reference to the MembershipUser instance that is associated with the authenticated user.
You examine the Comment property to determine whether the user is currently logged in.
Important: You must store information in the Comment property that indicates when the user explicitly signed out. Also, you must clear the information that is in the Comment property when the customer eventually signs in again.
If the user is not currently logged in as indicated by the Comment property, you must take the following actions:
Clear the cookie.
Set the Response.Status property to 401.
Make a call to the Response.End method that will implicitly redirect the request to the logon page.
By using this method, the forms authentication cookie will only be accepted if the user has not been explicitly signed out and the forms authentication ticket has not yet expired.
Read this article about Session fixation and how to get rid of it once and for all:
http://www.dotnetfunda.com/articles/show/1395/how-to-avoid-the-session-fixation-vulnerability-in-aspnet
This remains an issue in .NET Framework. Everyone seems to think Session.Abandon() is the answer, but the sad truth is that command does not invalidate the session on the server's side. Anyone with the right token value can still resurrect a dead session, until the session expires based on the Web.config settings (default = 20minutes).
A similar questioner posed this question a long time ago here:
Session Fixation in ASP.NET
Most of those links are dead, and Microsoft has no new news on the topic.
https://forums.asp.net/t/2154458.aspx?Preventing+Cookie+Replay+Attacks+MS+support+article+is+now+a+dead+link
Worse still, you're still vulnerable to this cookie replay attack even if you're implementing a completely stateless MVC application and don't use the Session object to store data between views. You can even turn off session state in the web.config settings and still replay cookies to gain access to a logged-out session.
The true solution is hack-y and described here, and you need to have session data enabled InProc to use it.
When the user logs in, set a boolean value in the session data, like Session["LoggedIn"] = true;, which is stored on the server side.
When the user logs out, set that value to false.
Check the session value on every request--an attacker trying to replay a session isn't going to be nice to you and come in through the Login page only. It's probably easiest to do this using a custom filter and registering it globally in the global.asax file (so you don't have to duplicate the code everywhere, or attribute every controller/method).
Even if the attacker has all the cookie values, they won't be able to re-use that same session ID, and the server will automatically delete it once it reaches the specified timeout.
if you are using the FormsAuthentication, you can use this code. By using this code you can destroy the created cookies by setting the Expire property of HttpCookie. It will help you:
FormsAuthentication.SignOut();
Session.Clear();
Session.Abandon();
Session.RemoveAll();
// clear authentication cookie
HttpCookie httpCookie = new HttpCookie(FormsAuthentication.FormsCookieName, "");
httpCookie.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(httpCookie);