web-dev-qa-db-ja.com

ログインフォームでのパスワード検証

登録フォームでは、クライアント側でパスワードの強度を検証しています。たとえば、パスワードは6文字以上で、1桁以上、1文字以上で構成する必要があります。

例えば: hello1およびdk43doは有効なパスワードですが、difmbfdおよび3242354ではありません。

このような検証を認証(ログイン)フォームでも行うのは正常ですか?したがって、ユーザーがログインを試みてパスワードを入力した場合、それは簡単でパスワードにはなりえません。つまり、ユーザーが間違っていたため、Submitを押す前にそのことをユーザーに知らせる必要があります。

6
Larry Cinnabar

まず第一に、あなたはそのような複雑で複雑なパスワードを要求すべきではありません。代わりに、単純に パスワード強度メーターを入力する をパスワードフィールドの横に配置し、ユーザーに強力なパスワードを使用するか弱いパスワードを使用するかを決定させます。

第2に、システムには、間違ったパスワードや無効なパスワードを処理する2つの異なる方法があってはなりません。すでに無効なパスワードをログイン試行として検証しようとするだけです。そうしないと、送信アクションを実行せずに間違ったパスワードの警告を予期するようにユーザーをトレーニングする可能性があります。さらに、このようなパターンはユーザーエクスペリエンスを向上させるものではありません。痛みやプロセスを軽減するものではありません。

18
dnbrv

他の回答に加えて、2つの異なるエラーメッセージ(パスワードの形式が正しくない/パスワードが間違っている)がセキュリティの問題になる可能性があることよりも、事実を強調したいと思います。これは、ハッカーがユーザーのパスワードを見つけるために使用する文字列の種類を知るのに役立ちます。

5

パスワードのテストを最適化するべきではありません。その逆です。パスワードを間違えたとしても、パスワードを試すことができる速度が遅くなるため、少しの時間のペナルティは悪いことではありません。一部のUNIXシステムでは、ログインパスワードを間違って取得した後、ブルートフォース攻撃を遅くするために数秒間一時停止します。

クライアント側のチェックを行わないもう1つの理由は、パスワードが間違っているかどうかをサーバーに知らせたいためです。これにより、失敗をログに記録し、正当なユーザーに誰かが自分のアカウントにアクセスしようとしたことを警告できます。クライアント側のチェックを行うと、その貴重な情報の一部が失われます。

2
Peter Bagnall

ユーザーとして、パスワードではないはずのパスワードを入力したことは気にせず、間違ったパスワードを入力したことだけが気になります。前者の説明をユーザーに提供するのは冗長であり、混乱を招く可能性があります。私はログインフォームでその検証をするために余計な努力をしないでしょう。

1
Felix Thea