間違った検証で、ほとんどのアカウント作成フォームがパスワードフィールドをクリアするのはなぜですか？
私が使用したほとんどのCreate Accountフォームでは、何かを間違って入力した場合（ユーザー名が短すぎる、パスワードが一致しない、無効な電子メールなど）、すべてのフィールドは保持されますが、パスワードフィールドは消去されます）。これの背後に本当の理由はありますか？パスワードが無効化の原因である場合は理解できますが、メールアドレスに問題がある場合は、なぜパスワードをクリアするのですか？
単純なルールは、パスワードを取得可能な形式で保存しないことです。
パスワードフィールドをそのままにしておくには、パスワードをブラウザーのキャッシュやCookieなどのどこかに、読み取り可能な形式でローカルに保存する必要があります。後で誰かがこれらのソースの1つからパスワードを取得する可能性があるため、セキュリティは不十分です。
Jeff Atwoodが何年も前に優れたブログ投稿を執筆しました： おそらくパスワードを正しく保存していません 。主にデータベースにパスワードを保存する方法を扱っていますが、同じ規則がすべてのストレージシステム（一時ストレージを含む）にも適用されます。彼の重要なポイントは次のとおりです。
- 独自の「巧妙な」パスワード保存スキームを発明しないでください。
- パスワードをプレーンテキストとして保存しないでください。
- 保存する各パスワードに、長くてユニークなランダムソルトを追加します。
- 暗号的に安全なハッシュを使用します。
JohnGBが言ったように、これは本当にセキュリティ上の予防策です。ただし、同時に使用可能で安全な代替方法があります。パスワードmypasswordを返送する代わりに、次のことができます。
- パスワードがサーバーに保存されていることを示す隠しフィールドを送り返します（もちろんハッシュ化されています）。
- パスワードフィールドで、値
********を割り当てます。 - ユーザーのパスワードフィールドには
********が表示されます。ユーザーがパスワードを変更しようとした場合は、フィールドをクリアして、新しいパスワードの入力を求めます（非表示フィールドインジケーターを変更します）。
これには明らかにクライアント側のスクリプトが必要です。または、パスワードフィールドをPassword: ********に置き換え、New PasswordおよびConfirm New Passwordの新しいフィールドを追加することもできます。次に、ユーザーが新しいパスワードを入力した場合にのみ、サーバーに保存されたパスワードを更新します。
パスワードの長さが異なることを除いて、ユーザーには難読化されたフォームのみが表示され、実際のパスワードはフィールドにあると想定されます。この点で、彼らの行動は変わらない。
このアプローチの1つの問題は、ユーザーが自分のパスワードを表示できないため、 show password オプションを使用できないことです（指定した場合）。 1つの可能性は、「パスワードの変更」ボタンを使用してフィールドを無効にし、ユーザーが新しいパスワードを入力できるようにすることです。