1

Topic: Built in in ASP.NET Identity vulnerability

I understand here with asp.net core As it is known, in ASP.NET it is possible to use authorization embedded system - Identity, it is possible to manage and without it, using authorization on the basis of Cookies and most to implement all logic Identity. But also in that and in that case the dirty trick is covered - there is a serious vulnerability, think it is not especially critical for serious developers, but anyway, it is necessary to understand that happens to find a method it to eliminate. In general, an essence such that for authorization at an input on a site, simply enough to have saved . It is finite, logical also all so do. But in these  the password, and  is not considered in any way, middleware authentification does not check  the password to a hash in a DB. It simply deciphers  in which login and all rights of the user on a site contains. So, if certain Vasja climbed on a site from a computer If, then came home, recalled that saved there the password and consequently decided it to replace. . Kohl nevertheless can enter on a site under  Vasi. Probably, this problem not only ASP.NET, but also more the general. Who as with it struggles?

2

Re: Built in in ASP.NET Identity vulnerability

Hello, vl690001x, you wrote: V> it is possible, this problem not only ASP.NET, but also more the general. V> who as with it struggles? Well to begin with, as you told, the problem (if it generally a problem) is not connected with ASP.Net Identity. And even with Cookies it is connected . If to look at a situation in general authentication protocols can be broken into 2 groups conditionally: - credentials the user are transferred from the client to the server at each reversal. For example, so authentification of the user in HTTP (when credentials are transferred at transport level) works. - credentials 1 time are transferred at session establishment, and then at each reversal the so-called sessional token, in which credentials, as a rule,  is used. The second approach has a mass of arguments pro: 1. The server which immediately fulfills request, can not have access to credentials the user that them to check up. It, actually the extremely widespread situation, all variants of authentification by the third party (through OpenID/OAuth/WS-Federeation/here get...) Authentifications by the uniform central server (when NTLM/Kerberos/HTTP Digest/protocols are used... - i.e. when the password is accessible only on the side  servers and on the client, and all intermediate servers see only result  which also changes in a random way). How check credentials in this case? 2. The algorithm of authentification can be where more difficult "simply password". Such cases as multifactor authentication, authentification on one-time (or to the temporal password), authentification on the basis of certificates, biometrics Here get... As how to store in this case and how to check? 3. No means always there is a possibility simultaneously to replace credentials on all clients where they are used. For example, service which works from user name. How correctly to update credentials for it (if, of course, we want to avoid a situation, what the service started to strew errors because of impossibility to reach the server)? To stop-> to change credentials on the server-> to change credentials in service adjustments-> to launch? And if it is a lot of such services? 4. If to transfer credentials together (or inside) with a sessional token, that, theoretically, at opening of a token we get access to credentials so it will be discredited not only current session, but also  the user account. I.e. in case of usage of a sessional token we need to undertake certain steps to eliminate interception of session and a sessional token. That normally do: 1. Restrict lifetime of a sessional token. Truth here rises a problem - and what time to expose. You will deliver small -  the user requirements  Credentials, you will deliver big - more chances at the malefactor. 2. Keep account sessions on the server and offer  for: closings of current session (for example, when explicitly ), closings of all sessions (when there is a danger of discrediting). 3. Use additional (not so reliable, but nevertheless)  - for example, removal  at browser closing on "another's" computer. 4. In every possible way notify the user - not  on resources from unreliable computers and especially not to save there passwords.

3

Re: Built in in ASP.NET Identity vulnerability

Hello, Michael Romanov, you wrote: > Well to begin with as you told, a problem (if it generally the problem) is not connected with ASP.Net Identity. > And even with Cookies it is connected . It certainly problem because built in template MVC of a site with usage Identity, without the additional undertaken measures (what, I yet did not understand), has serious vulnerability. There there is a system of change of the password. But it is actually useless. Unless it not a problem? What sense to me to change the password on the computer if all the same from those places where I entered earlier and saved , it will be possible to come on a site under mine ? > That normally do: > 1. Restrict lifetime of a sessional token. Truth here rises a problem - and what time to expose. You will deliver small -  the user requirements  Credentials, you will deliver big - more chances at the malefactor. > 2. Keep account sessions on the server and offer  for: Closings of current session (for example, when explicitly ), closings of all sessions (when there is a danger of discrediting). > 3. Use additional (not so reliable, but nevertheless)  - for example, removal  at browser closing on "another's" computer. > 4. In every possible way notify the user - not  on resources from unreliable computers and especially not to save there passwords. From my point of view, all is easier. It is necessary to store in  a hash from a password hash, and at an input on a site, to compare it to a hash in a DB. Let it demands additional reversal to a DB on each request, I do not think that it will beat on speed strongly, it is possible to use . Why so do not do? And whether it is possible to adjust such behavior somehow? Or another but that it solved the specified problem?

4

Re: Built in in ASP.NET Identity vulnerability

Hello, vl690001x, you wrote: V> It certainly problem because built in template MVC of a site with usage Identity, without the additional undertaken measures (what, I yet did not understand), has serious vulnerability. I do not see vulnerability in such behavior. V> there there is a system of change of the password. But it is actually useless. Unless it not a problem? Why it is useless? Password change does not allow  again. There, where you already , session will continue to operate V> What sense to me to change the password on the computer if all the same from those places where I entered earlier and saved , it will be possible to come on a site under mine ? Well so you do not enter or clean . Actually, if you entered on the unfamiliar computer on any resource, you already potentially gave to the malefactor chance to steal everything that it was necessary for it: - It could intercept all traffic  the browser and the server - it could implement scripts which collected on page and transferred outside all necessary data - it could intercept credentials, especially, if you used normal forms-based authentication.... That could remain  (depends on how it has been implemented, and on how many the "standard" browser was used), it, , most it is small from possible problems of operation on "another's" computer. V> from my point of view, all is easier. It is necessary to store in  a hash from a password hash, and at an input on a site, to compare it to a hash in a DB. Well store, if consider that it is necessary to do it. The mechanism to check most and if needed to change the data in Cookies is. V> let it demands additional reversal to a DB on each request, I do not think that it will beat on speed strongly, it is possible to use . Only do not forget to drop a cache when the user changes the password, and that receive the same is equal + the user cannot  itself. V> why so do not do? Can and do, for any private scenarios it can quite be the useful decision. Probably. And why the such do not do in the general mechanisms, I like accurately enough described: at least because "password" can not be at all. As on me so sites with own storage credentials it is fast  does not remain. V> And whether it is possible to adjust such behavior somehow? Directly to "adjust", probably is not present. And here a few to add - quite. It becomes approximately so: services. ConfigureApplicationCookie (co => co. Events = new MyEvents ()); Where MyEvents it is the successor from CookieAuthenticationEvents in which the methods of events necessary to you are redefined. If it is very schematical, approximately so: private class MyEvents: CookieAuthenticationEvents {public override Task SigningIn (CookieSigningInContext context) {//Here it is necessary to save the real password context. Properties. Items ["password"] = "123"; return base. SigningIn (context);} public override Task ValidatePrincipal (CookieValidatePrincipalContext context) {var t = context. Properties. Items ["password"];//Here it is necessary to get and compare to the real password if (t! = "123") context. RejectPrincipal (); return base. ValidatePrincipal (context);}} But, , you in vain spend here forces. Moreover, for certain there will be cases when it would be better, that at the user  it would be necessary to hang session, even after password change.

5

Re: Built in in ASP.NET Identity vulnerability

Hello, vl690001x, you wrote: V> But in these  the password, and  is not considered in any way, middleware authentification does not check  the password to a hash in a DB. It simply deciphers  in which login and all rights of the user on a site contains. There still should be SecurityStamp which  it is casual after each operation with the registration data, such as password change. And it too is checked.

6

Re: Built in in ASP.NET Identity vulnerability

Hello, Michael Romanov, you wrote: > But, , you in vain spend here forces. > Moreover, for certain there will be cases when it would be better, that at the user  it would be necessary to hang session, even after password change. Thanks for a detailed explanation. I simply try to understand, and consequently there are questions. There can be it not the greatest problem, but she helps me to understand device Identity.

7

Re: Built in in ASP.NET Identity vulnerability

Hello, the Daisy wheel, you wrote: There still should be SecurityStamp which  it is casual after each operation with the registration data, such as password change. And it too is checked. The matter is that I checked. I do not know that there it is checked or it is not checked, but the scenario described by me we implement, to be convinced of it it is possible creating sample applications with Identity, and used two different browsers for check.

8

Re: Built in in ASP.NET Identity vulnerability

Hello, vl690001x, you wrote: V> The matter is that I checked. I do not know that there it is checked or it is not checked, but the scenario described by me we implement, to be convinced of it it is possible creating sample applications with Identity, and used two different browsers for check. Well so on a default just should turn on. In Startup should be approximately following: app. UseCookieAuthentication (new CookieAuthenticationOptions {AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, LoginPath = new PathString ("/Account/Login"), Provider = new CookieAuthenticationProvider {//Enables the application to validate the security stamp when the user logs in.//This is a security feature which is used when you change a password or add an external login to your account. OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser> (validateInterval: TimeSpan. FromMinutes (30), regenerateIdentity: (manager, user) => user. GenerateUserIdentityAsync (manager))}}); Is?

9

Re: Built in in ASP.NET Identity vulnerability

Hello, the Daisy wheel, you wrote: Is? No, in Identity it is used simply app. UseAuthentication ();

10

Re: Built in in ASP.NET Identity vulnerability

Hello, vl690001x, you wrote: V> Is not present, in Identity it is used simply V> V> app. UseAuthentication (); V> For Core as I understand, the same approach with determination of the events as I resulted above should be used. I.e. the event class will look so: private class MyEvents: CookieAuthenticationEvents {public override Task ValidatePrincipal (CookieValidatePrincipalContext context) {return SecurityStampValidator.ValidatePrincipalAsync (context);}} However, I suspect,  all the same to use Generic-version SecurityStampValidator <>. Look at it more attentively.

11

Re: Built in in ASP.NET Identity vulnerability

Hello, vl690001x, you wrote: V> I Understand here with asp.net core V> As it is known, in ASP.NET it is possible to use authorization embedded system - Identity, it is possible to manage and without it, using authorization on the basis of Cookies and most to implement all logic Identity. V> But also in that and in that case the dirty trick is covered - there is a serious vulnerability, think it is not especially critical for serious developers, but anyway, it is necessary to understand that happens to find a method it to eliminate. V> in general, an essence such that for authorization at an input on a site, simply enough to have saved . It is finite, logical also all so do. V> but in these  the password, and  is not considered in any way, middleware authentification does not check  the password to a hash in a DB. It simply deciphers  in which login and all rights of the user on a site contains. Well already 100 times about it told it:" To give access only on the basis of the input data - a mortal sin of the programmer ". And a problem not only in passwords, the user could  or how differently to change its rights in system, but it still has former rights while it does not clean . From here as it is necessary to do outputs.

12

Re: Built in in ASP.NET Identity vulnerability

Hello, vl690001x, you wrote: V> So if certain Vasja climbed on a site from a computer If, then came home, recalled that saved there the password and consequently decided it to replace... Kohl nevertheless can enter on a site under  Vasi. V> it is possible, this problem not only ASP.NET, but also more the general. V> who as with it struggles? It not vulnerability so the heap of services works. By Design. Dares small lifetime of a token, and mandatory https. In a template asp.net by default it is half an hour (security stamp) if to me does not change storage. , in google (gmail, docs, etc), microsoft (sharepoint, office online) is an hour. That is, in your scenario, Kohl can easy read mail of Vasi during a half an hour-hour after Vasja replaces the password, and anybody it especially does not soar.

13

Re: Built in in ASP.NET Identity vulnerability

Hello, bnk, you wrote: bnk> Dares small lifetime of a token, and mandatory https. bnk> In a template asp.net by default it is half an hour (security stamp) if to me does not change storage. , in google (gmail, docs, etc), microsoft (sharepoint, office online) is an hour. bnk> that is, in your scenario, Kohl can easy read mail of Vasi during a half an hour-hour after Vasja replaces the password, and anybody it especially does not soar. Normally all is hardly more difficult. There is a sessional token, and is continuation token. When turns sour sessional the server tries to update it without involvement of the user, through the same authority, whence took a token for the first time. If everything is all right for the user simply there is a small time delay in interaction; sometimes - with observable effects in GUI (type "specify once again an account under which want to continue operation"), but without request Credentials. If is not present (something changed in an account of the user) it force repeatedly . It allows to save the comprehensible compromise between comfort (on some sites I not  the password months), and safety (password change normally  the requirement  within the next hour).

14

Re: Built in in ASP.NET Identity vulnerability

Hello, Sinclair, you wrote: S> Hello, bnk, you wrote: bnk>> Dares small lifetime of a token, and mandatory https. bnk>> In a template asp.net by default it is half an hour (security stamp) if to me does not change storage. , in google (gmail, docs, etc), microsoft (sharepoint, office online) is an hour. bnk>> that is, in your scenario, Kohl can easy read mail of Vasi during a half an hour-hour after Vasja replaces the password, and anybody it especially does not soar. S> all is normal hardly more difficult. There is a sessional token, and is continuation token. S> When turns sour sessional the server tries to update it without involvement of the user, through the same authority, whence took a token for the first time. S> if everything is all right for the user simply there is a small time delay in interaction; sometimes - with observable effects in GUI (type "specify once again an account under which want to continue operation"), but without request Credentials. S> If is not present (something changed in an account of the user) it force repeatedly . S> It allows to save the comprehensible compromise between comfort (on some sites I not  the password months), and safety (password change normally  the requirement  within the next hour). In standard Oauth2 for example it is called access token and refresh token accordingly. An essence that during the validity period access token - (that half an hour-hours) nothing stops to Kohl from reading of mail of Vasi. Even if Vasja replaced the password

15

Re: Built in in ASP.NET Identity vulnerability

Hello, bnk, you wrote: bnk> In standard Oauth2 for example it is called access token and refresh token accordingly. bnk> an essence that during the validity period access token - (that half an hour-hours) nothing stops to Kohl from reading of mail of Vasi. bnk> Even if Vasja replaced the password It depends from  Petja whom Vasinu mail administers. Because there are no problems to add in tokens client IP, sharply complicating token stealing (and providing Vase cheerful life if he reads mail from a notebook in a train, and it IP changes chaotically)

16

Re: Built in in ASP.NET Identity vulnerability

Hello, Sinclair, you wrote: S> It depends from  Petja whom Vasinu mail administers. Because there are no problems to add in tokens client IP, sharply complicating token stealing (and providing Vase cheerful life if he reads mail from a notebook in a train, and it IP changes chaotically) Under the scenario above, Kohl reads Vasinu mail from the house, from the computer to which before it gave  Vase (client IP the same?) IMHO, such scenario gets to discharge ' to itself spiteful Buratino ', instead of vulnerability.

17

Re: Built in in ASP.NET Identity vulnerability

> 3. Use additional (not so reliable, but nevertheless)  - for example, removal  at browser closing on "another's" computer. > 4. In every possible way notify the user - not  on resources from unreliable computers and especially not to save there passwords. Still in every possible way recommend to use button Logout. But it not on all operates...

18

Re: Built in in ASP.NET Identity vulnerability

Hello, bnk, you wrote: bnk> Hello, Sinclair, you wrote: S>> It depends from  Petja whom Vasinu mail administers. Because there are no problems to add in tokens client IP, sharply complicating token stealing (and providing Vase cheerful life if he reads mail from a notebook in a train, and it IP changes chaotically) bnk> Under the scenario above, Kohl reads Vasinu mail from the house, from the computer to which before it gave  Vase (client IP the same?) bnk> IMHO, such scenario gets to discharge ' to itself spiteful Buratino ', instead of vulnerability. Quite right. I about that in the original (without client IP affinity) Kohl Vasin steals a token (through, for example, free vaj-faj with the same title, as favourite Vasin), and use it from the computer. It is much wider class , than "to get physical access to Vasinomu to a computer and so that Vasja did not note"

19

Re: Built in in ASP.NET Identity vulnerability

Hello, Michael Romanov, you wrote: > If to look at a situation in general authentication protocols can be broken into 2 groups conditionally: > - credentials the user are transferred from the client to the server at each reversal. For example, so authentification of the user in HTTP (when credentials are transferred at transport level) works. > - credentials 1 time are transferred at session establishment, and then at each reversal the so-called sessional token, in which credentials, as a rule,  is used. A sessional token it too credentials, only the temporal. And HTTP  at once does not cancel their usage. The difference in  at level of transport and in  differs only a variable  in which are transferred credentials. > 1. Restrict lifetime of a sessional token. Truth here rises a problem - and what time to expose. You will deliver small -  the user requirements  Credentials For this purpose invented refresh token.... <<RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>