ランダムパスワードvs nullパスワード？
一部のユーザーをレガシーアプリのデータベースから新しいデータベースに移行し、ユーザーとそのすべてのデータを既存のデータベースからプルするスクリプトを作成しました。
ユーザーのパスワードはハッシュ化されているため、これらをプルすることはできません。これは問題ありませんが、リセットを実行する前に、これを行う最も安全な方法は何であるかを考えていました。
- パスワードフィールドをNULLにして、リセット時にフィールドに入力します
- ユーザーのランダムパスワードを生成し、パスワードフィールドをNOT NULLのままにし、リセット時に入力します。
ランダムなパスワードの生成は余分で不要な作業のように見えますが、通常の状況ではすべてのユーザーがパスワードを持っているため、NULLパスワードはセキュリティホールになる可能性があるので、これがNULLになることはありません。
誰かがいくつかのガイダンスを提供できますか？
既存のパスワードハッシュと残りのデータをインポートし、「ダーティビット」フラグを新しいデータベースに追加して、これらのインポートされたユーザーに対してtrueに設定します。
ユーザーがログインすると、レガシーアプリ/コードで使用されていたハッシュメカニズムを使用して検証されます。次に、現在の方法を使用してパスワードを更新し、新しいハッシュを保存して、フラグをオフにします。
バックエンドでの作業は少し増えますが、時間をかけて正しく設定すると、将来の切り替えが容易になり、エンドユーザーの移行がよりスムーズになります。
編集：さらに、ユーザーのパスワードをNULLまたは空白に設定する潜在的な（surefireとして読む）混乱を回避します。エンドユーザーが「実際の」ユーザーであることを誰が確認するはずですか？
ここでの問題は、ログインロジックがパスワードハッシュの代わりに未定義の値をどのように解釈するかです。未定義の値として、SQLの意味でのNULLを意味すると思います。
システムが、ユーザーが入力したパスワードのハッシュを保存されているハッシュと比較する場合、必要に応じて、未定義の値（または空の文字列）は決して一致しません。同様に、保存されたハッシュは、有効なパスワードハッシュと一致しない他の文字列に設定できます。 Linuxシステムでは、/etc/shadowのシステムアカウントをパスワードハッシュの代わりに*で確認できます。ユーザーをusermod -Lでロックすると、ハッシュは!に設定されます。どちらも有効なパスワードハッシュではないため、パスワードを使用したログインは成功しません。
ただし、ログインシステムが未定義（または空）の値を空のパスワードと一致するものと解釈するリスクがある場合は、それらを使用しないようにしてください。未定義の値もエラーの原因となる可能性があり、少なくともナイスに見えない可能性があります。
システムが既知であり、未定義のパスワードで動作するようにテストされているか、またはアカウントを使用不可またはロック済みとしてマークする他の方法があるかどうかを確認する必要があります。どこにも保存されていないランダムに生成された長いパスワードに一致する有効なハッシュを生成すると、システムがそれを処理できる可能性が高いため、安全です。
私は個人的には「ユーザーごとにランダムなパスワード」のアプローチを好む傾向があります。そうしないと、特定のユーザー名で最初にログインしてログインしようとするだけでアカウントが「盗まれる」可能性があるためです。
ただし、これにはユーザーが移行を認識している必要があるため、新しいパスワードと新しいURL（またはケースが何であれ）が記載された電子メールがどこからともなく出てくることはありません。
しかし、現在のパスワードが暗号化されていると言うとき、正確にはどういう意味ですか？
それらが暗号化されているのではなくハッシュされている場合、私はそれらがどのようにハッシュされているかを考え出し、単に他のデータと一緒にプルする価値があると思う傾向があります。
ユーザーが初めてログインするときは、次のいずれかを実行できます。
- パスワードを強制的に変更し、新しいアプリで使用することを目的としたもので新しいパスワードをハッシュする
- または、「通常の」パスワードを使用してユーザーを認証し、パスワードチェックに合格した場合は、パスワードを再ハッシュして保存します。
両方のアプリが同じメッセージダイジェストアルゴリズムを使用していない限り、保存され、ハッシュされたパスワードの長さを簡単にチェックすると、どのパスワードが目的のハッシュアルゴリズムを使用していないかがわかります。
パスワードが実際に暗号化されている場合は、それらがどのように暗号化されているかを確認し、上記の2つの方法のいずれかを選択して独自のDBを更新することも有効です。
とにかくランダムなパスワードを生成する場合は、なぜパスワードハッシュも移行しないのですか？次に、古いハッシュアルゴリズムを維持している場合は、最初のログイン時にパスワードを変更するように強制するか、同じハッシュアルゴリズムを維持していない場合は、ランダム/ nullパスワードを使用して計画していることを実行できます。
パスワードがプレーンテキストであったか、以前にハッシュ化が不十分だった場合を除いて、ハッシュを移行するだけの3番目のオプションがなぜ問題になるのかはわかりません。