2

I'm looking at ASP.NET Identity for a website but the user administrative panel will not be part of the website, but rather rolled into a separate desktop application.

Boilerplate code for using ASP.NET Identity seems to involve:

    var dataProtectionProvider = options.DataProtectionProvider;
    if (dataProtectionProvider != null)
    {
        manager.UserTokenProvider = 
            new DataProtectorTokenProvider<ApplicationUser>(dataProtectionProvider.Create("ASP.NET Identity"));
    }

where options is passed in from the OWIN framework, and manager is the UserManager. The point seems to be to generate an implementation of IDataProtector that implements some sort of reversable encryption.

The default implementation here relies on a machine key which won't be the same across all machines. I would strongly prefer not to get into doing a self-signed cert and getting it trusted among all client machines.

What is this for? Presumably it has nothing to do with one-way hashing of passwords. Other googled references seem to indicate it has something to do with resetting passwords, but I can't find any detailed reference as to what exactly is being encrypted.

It's hard to figure out what an appropriate implementation of this interface would be if I can't find documentation on what exactly it is trying to protect. Any ideas?

Clyde
  • 8,017
  • 11
  • 56
  • 87

1 Answers1

2

IDataProtector is implementing encryption that generates tokens for password reset and email confirmations. And default implementation does not depend on MachineKey.

You are correct, this is nothing to do with password hashing. This generates a token, token has some data in it and the token is encrypted and signed to avoid tampering. Once to the token is back to the server, it is decrypted and signature is checked, if everything is correct user is allowed to reset password or confirm email.

I'm not sure how you are going to use that on desktop app and what are the machines you are talking about. Are these servers or desktops?

trailmax
  • 34,305
  • 22
  • 140
  • 234
  • Desktops -- line of business application where they can manage users among other things – Clyde Feb 02 '15 at 16:17
  • It's not clear to me what's being gained by this encryption and decryption. If the encrypted token is sent out in the email, then the encrypted content is itself the 'password'/anti-tampering token. The decrypted content is basically irrelevant and proves nothing. – Clyde Feb 02 '15 at 16:20
  • Or to put it another way, if I implement an IDataProtector that implements the Protect and Unprotect methods as straight pass-throughs, what attack vector would be opened up? – Clyde Feb 02 '15 at 16:21
  • Password is never sent out even in encrypted way. Usually `SecurityStamp` is encrypted with extra data. And `SeciryStamp` is just a random GUID. If you open-up Protect and Unprotect then vector of attack would be to guess password resetting token and reset the password. – trailmax Feb 02 '15 at 16:22
  • also tokens do have expiry time. If you remove the encryption, your tokens will be indefinite. – trailmax Feb 02 '15 at 16:23
  • Regarding desktops, are you going to run IIS on users desktops to manage users? I'm not sure how this is all tied together. What is the topology of your solution? – trailmax Feb 02 '15 at 16:25
  • I'm missing something about this SecurityStamp. If the user is parroting back the encrypted GUID from the registration email, then the encrypted GUID itself is their token -- the actual GUID content is irrelevant. Nothing is being protected here. I'll look into the expiry time, though it would shock me that the expiration would be embedded in the token sent out rather than on the user record in the db. – Clyde Feb 02 '15 at 16:27
  • No the clients should just need an implementation of UserManager which can be shared between the apps. The design of ASP.NET Identity seems to do a good job separating this so the user management code doesn't actually depend on an OWIN or IIS runtime (I'm still proving this out for sure) – Clyde Feb 02 '15 at 16:29
  • I'm looking on the source code just now. `DataProtectorTokenProvider` is feeding `purpose` (which is a string of "PasswordReset" or "EmailConfirmation"), Utc time, `user.Id`, `SecurityStamp` if storage supports this. This is all encrypted and creates a token. Actual expiry is not set in the token, but token contains date of creation. On the validation process, it checks if token is not older than allowed lifespan. And token lifespan is set on server. – trailmax Feb 02 '15 at 16:33
  • Purpose for all this ceremony - the token is not stored on the server. All is crypto-cleverness. I'm not sure about the reasons, but there are a good security reasons to do it that way. – trailmax Feb 02 '15 at 16:36
  • can you post the link to that source code? Is that on github? – Clyde Feb 02 '15 at 16:37
  • Code is in decompiler. Current version is not open source yet. – trailmax Feb 02 '15 at 16:38
  • See this link http://stackoverflow.com/a/23661872/809357 for sample of data protection. You can pretty much implement something very similar, but not depending on Machine Key. – trailmax Feb 02 '15 at 16:39
  • Also see comments to this answer: http://stackoverflow.com/a/28096811/809357 - using DpapiDataProtection with supplied AppName. Not sure if it'll work for you, but worth a try. – trailmax Feb 02 '15 at 16:42
  • I had seen that -- options seem to be to either to use a certificate to encrypt and decrypt, which would mean pushing a cert into the local machine store on all current and future workstations, or just embedding a symmetric key in the app or app config itself which would leave it open to disassembly – Clyde Feb 02 '15 at 16:43
  • I'll dig into the source of DpapiDataProtection too, though my impression has been that it also depends on the local MachineKey – Clyde Feb 02 '15 at 16:44
  • Not a problem. I'm sure I've used Dpapi thing without machine key specified anywhere. Worth a dig anyway. – trailmax Feb 02 '15 at 16:48