ランダムパスワードとnullパスワード?

一部のユーザーをレガシーアプリのデータベースから新しいデータベースに移行し、既存のデータベースからユーザーとその全データを取得するスクリプトを作成しました。

ユーザーのパスワードがハッシュ化されているため、これらを引き出すことはできませんが、これで問題ありませんが、リセットを実行する前に、最も安全な方法は何だろうと思いました。

  • パスワードフィールドをNULLにして、リセット時にフィールドに入力します
  • ユーザーのランダムなパスワードを生成し、パスワードフィールドをNOT NULLのままにしてリセット時に入力します

ランダムなパスワードを生成することは余分な、不必要な仕事のように見えますが、私は通常の状況下ではすべてのユーザーがパスワードを持っているのでNULLパスワードを持つことはセキュリティホールかもしれないと思います。

誰かが何か手引きを提供できますか?

3
ru de
私は興味があるので、なぜあなたはパスワードを移行することができないのですか(私はあなたが暗号化されるよりむしろハッシュされることを意味すると思います)?あなたは必ずしも平文を必要としません。新しいハッシュアルゴリズムに変わりますか?
追加された 著者 Denis,
空のパスワードはシステムによってNULLとして解析されますか?
追加された 著者 schroeder,
空の文字列ですか?これはNULLではなく、単に空の文字列になります。
追加された 著者 PacificNW_Lover,
現在のハッシュ方式が何であるか知っていますか。大きな違いを生む
追加された 著者 ste-fu,

4 答え

既存のパスワードハッシュを残りのデータと共にインポートし、新しいデータベースに「ダーティービット」フラグを追加して、これらのインポートされたユーザーに対してtrueに設定します。

ユーザーがログインしたら、レガシーアプリ/コードで使用されていたハッシュメカニズムを使用して検証し、現在の方法でパスワードを更新するようにユーザーに強制し、新しいハッシュを保存してフラグをオフにします。

バックエンドではもう少し作業が必要ですが、時間をかけて正しく設定すると、将来の切り替えが容易になり、エンドユーザーの移行がスムーズになります。

編集:加えて、あなたはユーザーのパスワードをNULLまたは空白に設定している可能性がある(確かに読む)混乱を避けます。エンドユーザーが「実際の」ユーザーであることを誰かが検証することになっていますか?

3
追加された

ここでの問題は、ログインロジックがパスワードハッシュの代わりに未定義の値をどのように解釈するかです。私はあなたがSQLの意味でのNULLを未定義の値として意味すると思います。

システムがユーザーが入力したパスワードのハッシュと保存されているハッシュを比較すると、未定義の値(または空の文字列)でも一致することはありません。同様に、格納されたハッシュは、有効なパスワードハッシュとして決して一致しない他の文字列に設定することができます。 Linuxシステムでは、パスワードハッシュの代わりに * を付けて/etc/shadow にシステムアカウントを表示し、 usermod -Lを使ってユーザーをロックすることができます。 はハッシュをに設定します。どちらも有効なパスワードハッシュではないため、パスワードでログインしても成功しません。

ただし、ログインシステムが未定義の(または空の)値を空のパスワードと一致すると解釈する危険性がある場合は、それらを使用しないことを真剣に望んでいます。未定義の値もエラーにつながる可能性がありますが、少なくとも見栄えはよくないかもしれません。

システムが未定義のパスワードで動作することが確認されテストされていること、またはアカウントに使用不可またはロック済みのマークを付ける方法が他にあるかどうかを確認する必要があります。どこにも保存されていない、ランダムに生成された長いパスワードに一致する有効なハッシュを生成することは、システムがどのような場合でもそれを処理できる可能性が高いという点で安全です。

2
追加された
@さて、あなたもそうすることができます。理論的には、システムは本当にパスワードハッシュフォーマットについてうるさいので、通常の方法でパスワードからハッシュを生成することは、システムについて何も知らなくても(使用されるハッシュさえ)安全であるべきです。おそらく賢明なシステムではありそうもない問題です。
追加された 著者 user118457,
いい答えだ! 1つの詳細:ランダムなパスワードのハッシュを保存する代わりに、ランダムなハッシュを使うことをお勧めします。実際にはハッシュに対応する印刷可能なパスワードではないかもしれませんが、使用されることは想定されていないので問題ありません。
追加された 著者 Anders,

個人的には「ユーザーごとにランダムなパスワード」のアプローチを好む傾向があります。そうしないと、アカウントが特定のユーザー名で最初にログインしようとするという単純な理由で「盗まれる」可能性があるからです。

ただしこれには、新しいパスワードと新しいURL(または場合にかかわらず)が記載された電子メールがどこからも出てこないように、ユーザーに移行を認識させる必要があります。

しかし、あなたの現在のパスワードが暗号化されていると言うとき、あなたは正確にはどういう意味ですか?

それらが暗号化されているのではなくハッシュされているならば、私はそれがどのようにハッシュされているかを考え出し、そして単に他のデータと共にそれらを引き出す価値があると思う傾向があります。

ユーザーが初めてログインしたときは、次のいずれかを実行できます。

  • パスワードの変更を強制し、新しいアプリで使用しようとしているもので新しいパスワードをハッシュします。
  • または「通常の」パスワードでユーザーを認証し、パスワードチェックに合格した場合は、パスワードを再ハッシュして保存します。

両方のアプリが同じメッセージダイジェストアルゴリズムを使用していない限り、格納されハッシュされたパスワードの長さを確認するだけで、どのパスワードが目的のハッシュアルゴリズムを使用していないかがわかります。

パスワードが本当に暗号化されている場合は、それらがどのように暗号化されているのかを調べて、上記の2つの方法のいずれかを選択して自分のDBを更新することもできます。

1
追加された

もしあなたがとにかくランダムなパスワードを生成しようとしているのなら、なぜパスワードハッシュも移行しないのですか?古いハッシュアルゴリズムを使用している場合は初回ログイン時にパスワードの変更を強制することができます。同じハッシュアルゴリズムを使用していない場合はランダムパスワードまたはnullパスワードを使用して今すぐに行うこともできます。

あなたのパスワードが平文であった/非常に貧弱にハッシュされたことがない限り、ハッシュを単に移行するという3番目の選択肢が問題になる理由は分からない。

1
追加された