Bulk Import of users with hashed passwords using Java BCrypt - import succeeding but password not carrying over

Get Help
, ,
1

I am currently trying to bulk-import users with hashed, pre-existing passwords from a ColdFusion application into Auth0 via the management API (or with the Bulk Import/Export extension).

I have built an export script/endpoint that hashes the passwords with the Java jBCrypt library, using a salt strength of 10, as specified in the schema documentation. The resulting password-hash appears to be properly formatted, and there are no errors thrown by the import job - however, I am unable to log in through Universal Login with new users imported through the job, receiving a “Wrong Username or Password” error.

Here is an example of one of the users in the payload that I am attempting to import.

{"email_verified":true,"app_metadata":{"userType":"01"},"password":"$2a$10$i97dI8fT8FCrJX8xkXmImuoueYgCLoiAd.FFC9a0Fx.dDpDDjeDMO","user_id":"passwordtester","username":"passwordtester","email":"pwtester@gmail.com","name":"passwordtester"}

I am importing into the same Username-Password-Authentication database that I have my “normal” users in, so I know it is the same connection that works otherwise.

I am curious for any insight anyone can offer about how to progress with this or alternative approaches for hashing the passwords that might produce output more agreeable to Auth0.

Thanks.

3

You can’t import unhashed passwords, but since fairly recently, you can import hashed ones! There’s pretty tight restrictions, though:

Two other fields are not technically part of the user profile, but may be of interest when importing users:

  • password_hash (text): Hashed password for the user’s connection. When users are created, Auth0 uses bcrypt to secure the password. Importing compatible hashed passwords allows users to retain their passwords, thereby providing a smoother experience. Compatible passwords should be hashed using bcrypt $2a$ or $2b$ and have 10 saltRounds.
  • password_set_date (date time): Timestamp indicating when the password for the user’s connection was set. At user creation, this field exists, and last_password_reset does not. If the user has reset their password, this field and last_password_reset are identical.
4

Thanks a lot for sharing that knowledge here @thijmen96!

5

Using password_hash instead of password did the trick, I had been hashing everything else properly. I am not sure if the schema example was incorrect at the time I filed this issue, or if I somehow misread the name of the field. Thanks very much for the guidance here @thijmen96 @tswallen

–adam