パスワードリセットなしでのユーザー移行

アイデンティティ移行のガイドには、いつも決まって同じことが書かれています。ユーザーはパスワードをリセットしなければならない、と。しかし、これはルールではなく、選択肢の一つに過ぎません。ほとんどのツールは、正しい方法ではなく、簡単な方法を選びます。

リセットなしでユーザーを移行することは可能です。既存のパスワードハッシュを検証するだけで済みます。旧システムのハッシュがあり、新システムがそれを読み取れるのであれば、移行はユーザーに気づかれることなく完了します。

パスワードハッシュは秘密ではありません。BcryptはBcryptです。それ自体にソルト（salt）とコスト係数（cost factor）が含まれています。Bcryptを使用しているシステムであれば、どのようなものでも検証可能です。PBKDF2も同様に動作します。ハッシュさえあれば、実際のパスワードを知ることなく、パスワードが正しいかどうかを照合できます。

時間を節約するために、レイジー・マイグレーション（lazy migration）を活用しましょう。

• 旧ハッシュを新システムに引き継ぐ。
• ユーザーがログインした際にハッシュを検証する。
• 検証後、すぐに新しい形式に置き換える。

数週間もすれば、データベースは自然に更新されます。パスワードリセットのメールを送る必要も、サポートチケットに対応する必要もありません。

ソースによって、提供される形式は異なります。

セルフホストのDuendeまたはASP.NET Identity: これらはV3 PBKDF2またはbcryptを使用しています。新システムで簡単に検証と再ハッシュが可能です。これは非常にクリーンなプロセスです。

Auth0: これらはbcryptを使用しています。直接インポートが可能です。ただし、標準的なAPI経由で取得することはできません。Auth0はセキュリティ上の理由から、API経由でハッシュを返さないようになっています。サポートに連絡して、一括エクスポートファイル（bulk export file）をリクエストする必要があります。このファイルにはbcryptハッシュが含まれています。このファイルを利用することで、移行をユーザーに意識させずに進めることができます。

ハッシュが取得できない場合は、ユーザーに新しいパスワードを設定してもらう必要があります。これは避けられない現実的な代替案（fallback）です。回避できるのであれば、ツールの都合で強制的にリセットを行わせるようなことは避けましょう。

強制的なリセットは、以下のような問題を引き起こします：

• サポートへの問い合わせが急増する。
• ユーザーがフィッシングメールを信じてしまう習慣がついてしまう。
• 静かな変更であるはずが、騒がしい問題へと変わってしまう。

優れた移行とは、何も起きていないかのように感じられるものです。ユーザーにパスワードリセットを促す前に、旧ハッシュが取得可能かどうかを確認してください。

Source: https://dev.to/authagonal/importing-users-without-a-password-reset-5h1j