Migrating from another provider

Bring your users across with their password hashes intact. Nobody resets anything, and nobody notices the change.

Why this matters

An export that omits password hashes forces every user to reset. A measurable fraction never come back, which is why several providers restrict hash export: it keeps customers by making departure expensive rather than by being better.

We accept the common formats, verify against them on first sign-in, and replace the stored value with Argon2id at that moment. After one login the foreign hash is gone.

Supported formats

Detection is by shape, so your export needs one column of hashes and no metadata about which algorithm produced them.

The import

[
  {
    "email": "anna@example.com",
    "display_name": "Anna Muster",
    "password_hash": "$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy",
    "email_verified": true
  }
]

The batch is validated in full before anything is written, and rejected as a whole if any row fails. A partially imported user base is worse than a failed import, because you cannot tell which half is missing without comparing row by row against the source.

The report names the row and the reason:

import rejected:
  - row 4: "not-an-email" is not an email address
  - row 9: "anna@example.com" already appeared on row 2
  - row 17: unrecognised hash format, supported are argon2id, bcrypt,
    scrypt and pbkdf2-sha256

One note on bcrypt

bcrypt silently truncates at 72 bytes. A user whose password is longer has been authenticating on its first 72 bytes at your previous provider, and will continue to until their first sign-in here, at which point the full password is hashed with Argon2id. That is a small security improvement they get for free.

Leaving again

The same door works outwards. Your export contains Argon2id hashes in the standard PHC string format, which any provider accepting Argon2id can import.

We would rather you could leave than keep you because you cannot.