web-dev-qa-db-ja.com

このパスワードなしシステムは安全ですか?

人は名前とパスワードを尋ねるフォームを持っています。パスワードはサーバーに送信され、そこで名前とパスワードのハッシュからハッシュが作成されます。このハッシュは、ASCII値を使用して数値に変換されます。数字は10桁に制限されており、乱数ジェネレータのシードに使用されます。 1-77616から3つの乱数が生成されます。これらの数字は、77616英語の単語のリストから単語を選択するために使用されます。形成された3つの単語が人物のユーザー名として使用されます。

77616 ^ 3はおよそ2 ^ 48であるため、100万回のユーザー名生成後の衝突の確率は、0.001774778278169853になるはずです。

これは、ユーザーを管理する安全な方法のように見えますか?そのようにして、ログイン/登録システムを実装する必要はありませんか?この種のシステムを従来のログイン/登録システムよりも使用する利点はありますか?

14
klenex

いいえ、これは安全ではないようです。

衝突

Mersenne Twisterは決定論的なRNGであるため、ほとんどの暗号化タスクには適していません(使用法は理にかなっていますが、それが決定論的でなければ、アプローチは当然機能しません)。

この場合、想定し計算の基礎となる段階では衝突は起こりません。代わりに、ASCII値を10桁に制限すると発生するため、衝突の確率は想定よりもはるかに高くなります。

アプローチに関するコメント

あなたが持っているものは基本的に自家製のハッシュ関数です。入力を受け取り、それに関数を適用して、固定長(3ワード)の出力を受け取ります。入力スペースは出力スペースよりも大きく、手順を逆にすることはできません(保存されている3つの単語からパスワードを取得)。

Do n't roll your own および Do n't be a Dave が適用されます。パスワードを適切にハッシュするには、 パスワードを安全にハッシュする方法 を参照してください。

あなたはまだログインと登録システムを実装しています(ユーザーはユーザー名とパスワードを入力する必要があり、何らかの形式で保存し、後で保存された値を新しく入力した値と比較してユーザーを認証できます)。

このステップで停止する場合:「パスワードはハッシュが作成されるサーバーに送信されます」、通常のプロセスになります。しかし、代わりに、セキュリティを向上させるが低下させる追加のステップを追加します。

35
tim

ユーザー名とパスワードのハッシュから始めます。後者は、少なくとも256ビットの暗号化ハッシュであることが望まれます。次に、それを10桁の数値に変換し、33ビットを除くすべてを破棄します。次に、これを疑似乱数ジェネレータのシードとして使用して、48ビットの単語のキーを計算しますが、情報はすでに失われています。33ビットを48ビットに拡張することはできません。 ^ 3つの単語の10の選択肢。したがって、メソッドは、適切に実装されていても、多くのエントロピーを放棄して何の利益ももたらしません。また、ユーザーに大文字や記号を含まない7文字のパスワードを要求することもできます。

6
Charles

数学を除いて、システムはユーザーの想定により安全ではありません。通常のユーザーは通常、ユーザー名を秘密として扱いません。ほとんどのシステムでは、他のユーザーから非表示になりません(たとえば、このサイトでは、お互いのユーザー名をすべて見ることができます)。ユーザーはそれを共有しない傾向がなく、このユーザー名を使用してログインしていることを理解しません(単純にCookieや証明書、または自動ログインを実行しているものがあると想定します)。

3
Tom

いいえ、パスワードを削除していません。ユーザー名を削除し、パスワードの名前を「ユーザー名」に変更しました。あなたはそれを「ユーザー名」と呼んでいるので、ユーザーは「これは私のユーザー名です。オンラインで友達と共有できます」と想定し、彼らのアカウントがハッキングされます。

セキュリティを「ユーザー名」の秘密に依存させないでください。

3
Buge