This question is a revised version of the previous one (I deleted that one)
I have a site running (C#) MVC 5 and ASP.Net Identity 2.0. From within the site all user management functions works fine, create, update, delete.
We have a SQL job that created all the accounts in bulk on the previous version of the site, I now need to update this to create the new accounts in Identity 2.0. I can't find any information on how to do this in any of the available forums.
Any information would be appreciated.
I've done some work on it an the last issue I have is figuring out how Identity 2.0 encodes the password. I can't seem to find out what algorithm is used.
This is how Identity 1 encoded the password:
SET #encoded_hashed_password = dbo.fbase64_encode(HASHBYTES('SHA1', Cast(#salt as varbinary(MAX)) + CAST(#ClearTextPassword AS varbinary(MAX))))
I'm looking for the Identity 2.0 equivalent.
It uses the same algorithm you will find in System.Web.Helpers.Crypto to hash and verify the passwords. To hash the password the method HashPassword can be used. The password hash is generated with the RFC 2898 algorithm using a 128-bit salt, a 256-bit subkey, and 1000 iterations. The format of the generated hash bytestream is {0x00, salt, subkey}, which is base-64 encoded before it is returned.
It is not clear to me from the question whether the previous site used SimpleMembership. If it was here is an article that provides detailed steps to migrate to ASP.NET Identity and how you can just use the same hash for your passwords.
Related
(TL;DR: I have two questions at the bottom.)
I have been looking through CouchDB's documentation to learn about its hashing algorithm, but I'm unable to find important details.
The most information I've gathered has been from this page: 1.5.2. Authentication Database
Here's my problem:
I have a bunch of users in a _users database in my CouchDB instance on Cloudant.
I need to be able to migrate users from CouchDB to Firebase.
Firebase offers a super-handy-dandy auth migration tool for this. However, in order to utilize its auth migration tooling, I need to know exactly which hashing algorithm is being used for the "simple" password_scheme.
For every user in my _users database, I have the "salt" and "password_sha" available.
Given the name "password_sha", I assume that the "simple" "password_scheme" uses either SHA1, SHA256, SHA512, PBKDF_SHA1, or PBKDF2_SHA256.
None of the users' docs in my database have a "derived_key". Almost all of them do not have a defined "password_scheme". If any of them do have a defined "password_scheme", it is always "simple" (and never "pbkdf2").
Once I know exactly which hashing algorithm CouchDB uses, I then need to know how many rounds or iterations were used to hash the password.
The Firebase docs say:
"you must provide the number of rounds (between 1 and 8192 for SHA1, SHA256 and SHA512, and between 0 and 120000 for PBKDF_SHA1 and PBKDF2_SHA256) used to hash the password."
However, I cannot find any documentation/information on this.
So my questions are:
What is the hashing algorithm CouchDB uses for the "simple" "password_scheme"? (Is it SHA1, SHA256, SHA512, PBKDF_SHA1, PBKDF2_SHA256, or something else?)
How many rounds or iterations are used to hash the passwords?
I posted this same question to a few chats linked in the CouchDB homepage, and Robert Newson, owner of CouchDB, told me the following in Slack:
"simple" is a one round of SHA-1 (with salt)
https://github.com/apache/couchdb/blob/main/src/couch/src/couch_passwords.erl#L26
So to directly answer these two questions:
The "simple" CouchDB hashing algorithm uses SHA1.
And it is only one round of hashing.
Just for the sake of completeness, this simple scheme is not what more recent versions of CouchDB (for sure not >= 2) use. The current default is to use pbkdf2 with the following values:
iterations = 10
keylen = 20
size = 16
encoding = 'hex'
digest = 'SHA1'
see couch-pwd if you need to generate or validate CouchDB-style passwords.
I have a .net application which uses asp.net identity 2 in order to authenticate users. The users login using username/password and upon successful login an access token (JWT) and a refresh token is produced.
The default implementation of asp.net 2 for hashing the passwords can be found here.
It uses a key derivation function with random salt to produce the hash. The salt is included as part of the output of the kdf. Thus the final produced password hash consists of a first empty byte, then 16 bytes of the salt and then 32 bytes of the hashed password. From the above references we can see that the algorithm used is HMAC-SHA1 with 1000 iterations and the raw password of the user
as key for the HMAC (see here).
I am thinking on migrating to Firebase Authentication and I want to migrate my existing users there. Based on Firebase documentation when migrating HMAC_SHA1 hashed passwords we must include the password hash, the salt and the hmac key. Also, we cannot provide the number of iterations used by the sha1 hashing algorithm (see here).
So, the question is: How can we know the key of the hmac since it is the raw password of the user? This is the default implementation of asp.net identity 2. Since we can never know it this means that we cannot migrate our users to firebase authentication?
Also, even if we knew the key, how could we provide the 1000 iterations of the sha1 algorithm in the payload towards Firebase? This can be done only when the hashing algorithm is sha1 without hmac see here.
I can help on the firebase part of the question.
The SDK does not seem to provide all the functionality supported by the Firebase CLI.
If you take a look here:
https://firebase.google.com/docs/cli/auth
firebase auth:import ACCOUNT_FILE \
--hash-algo=HASH_ALGORITHM \
--hash-key=KEY \
--salt-separator=SALT_SEPARATOR \
--rounds=ROUNDS \
--hash-input-order=HASH_INPUT_ORDER
I think you can define everything you need.
For hash-algo you need to use HMAC_SHA1
For hash-key you need to use the key used to hash the passwords in base64 format
For rounds use 1000 for the iterations you specified
For hash-input-order you need to use SALT_FIRST
Now for where you can get the key, maybe someone else can chip in.
I have trying to implment one time registration verification & daily login using SMS OTP for my app using asp.net core identity implementation.
It is one time token, which should expire in 15 minutes if not used
User should request it again in case its expired or lost
Searching around for it, all the implementation provide details about MFA or Google Authenticator based verification, where this scenario is slightly different.
The Token will not be generated by the Server, and not the Authenticator app.
I need to store token along with its genrated at time.
The token will be 6 digit SMS.
The scenario is more similar to password less auth mentioned here, but then the token in that case is not stored, I need to store it with Validity, not sure how to extend .net core identity to match above requirement.
This is fairly standard way of phone number authentication
I know this is not a standard SO format, but I am at loss from where to start
I know this is an old question, but I found myself here with the same problem, and information about this is surprisingly thin on the ground. Likely as Microsoft recommend using (2FA) authenticator apps, using a Time-based One-time Password Algorithm (TOTP) rather than an OTP with SMS/Email.
Not the intended purpose, but nevertheless the following will allow you to generate and save a time limited (3 minutes) 6 digit OTP, associate it with a user and then use it to verify them using ASP.NET Core Identity.
GenerateChangePhoneNumberTokenAsync
var code = await _userManager.GenerateChangePhoneNumberTokenAsync(user, model.PhoneNumber);
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.usermanager-1.generatechangephonenumbertokenasync
and
VerifyChangePhoneNumberTokenAsync
bool valid = await _userManager.VerifyChangePhoneNumberTokenAsync(user, code, model.PhoneNumber);
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.usermanager-1.verifychangephonenumbertokenasync
This can be seen being implemented in the documentation posted by Erik & paulsm4
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/2fa?view=aspnetcore-1.1&viewFallbackFrom=aspnetcore-3.1
A link to the code
https://github.com/dotnet/AspNetCore.Docs/tree/master/aspnetcore/security/authentication/2fa/sample/Web2FA
A link to the controller where this is implemented
https://github.com/dotnet/AspNetCore.Docs/blob/master/aspnetcore/security/authentication/2fa/sample/Web2FA/Controllers/ManageController.cs
I am considering using ASP.NET Core Data Protection to protect long living tokens. The default Data Protection key lifetime is 90 days, which is enough in this case.
Is it a good idea to use Data Protection for this scenario or should I rather use something else?
As from the documentation (https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/default-settings?view=aspnetcore-2.1#key-lifetime) you can use this API to protect also long living tokens.
Only newly encrypted tokens will use the newest key. You are able to decrypt all your old encrypted tokens, also if they were encrypted longer then 90 days ago. All the old keys are saved on your system for decryption purpose.
I'm reading up on how to implement single sign on between two sites and came across this example http://dev.assistly.com/docs/portal/multipass. Basically one site passes an encrypted JSON hash containing user id, login expiration and some other customer info. The hash is created using a site key as password and api key as the salt.
As I understand it, hashing algorithms work one way. For example, site #2 could hash the same values and compare the result against the hash passed by site #1 to determine if it is authentic & valid. However, site #2 can't reverse the hashed value passed by site #1 to determine what values were used.
Here's my question. In the SSO example I linked to and described above, all of the information is presumably shared between the two sites in advance of the sign-on. For example, both sites presumably know the user id, password, salt, etc. However, I assume that the expiration datetime value is different for each login occurrence. If the expiration datetime changes with each login and if it is not something that can be shared beforehand between the two sites, wouldn't it be impossible for site #2 to validate the hash it receives from site #1?
I must be missing something in my understanding of how this works. Or perhaps I'm making faulty assumptions. Please explain. Thanks!
Assistly's terminology is a bit confusing. When they talk about hashes they are actually referring to JSON hashes which are just maps of values ... not cryptographic hashes. You'll see they also refer to AES encryption which is two-way so you would encrypt the data and they would decrypt it.