セキュリティリスクが中〜低のアプリ（つまり、バンキングアプリなどではない）のログインを作成する場合、ユーザーが入力したパスワードを次のように入力するだけで検証できますか。

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

効果的であるように簡単に思えますが、それが必要なすべてであるかどうか私は確かに気にしません。ユーザー名とパスワードのコンボを簡単にチェックするだけで十分ですか？

更新：特定のプロジェクトはたまたまWebサービスであり、検証は完全にサーバー側であり、オープンソースではありません。ドメインは、これに対処する方法を変更しますか？

SSLなしではない

パスワードがプレーンテキストでネットワーク経由で送信される場合、これは安全ではありません。パスワードがプレーンテキストでネットワーク経由で送信される場合、サーバー側でのパスワードのハッシュも安全ではありません。

HTML <input type="password"/>タグの内容はプレーンテキストで送信されるため、WebサイトでSSLを使用してパスワードを送信しない限り、サーバーにパスワードを保存する方法に関係なく、これは問題になります。

（ブラウザでパスワードを要求するダイアログボックスを表示するHTTP認証は、サーバーとブラウザに共通の認証メカニズムに応じて、クリアテキストである場合とそうでない場合があります。 SSL。）

サイト管理者が疑わしい場合ではない

ここで、Webサイトの実行にHTTPSを使用していると仮定すると、サイト管理者（プレーンテキストのパスワードを読み取ることができる）およびマシンにアクセスできる他の人が正しく動作することを信頼する場合、これは安全です。今、彼らはあなたのウェブサイトで彼らが望むことを何でもできることは明らかかもしれません（彼らはそれを管理しているので）が、彼らがパスワードを読むことができれば、他の人のサイトで盗まれたログイン/パスワードのペアを使用することもできるかもしれません。

パスワードを管理者から安全に保つ方法

パスワードを保存および確認する安全な方法の1つは次のとおりです。

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

ハッシュ関数には、強力なものと、まだ良いレインボーテーブルを持たないものを使用してみてください。必要に応じて、レインボーテーブルを回避してソルトの長さを変更できます。

使用している環境、ネットワークレイテンシの変動、およびユーザー名が一般に知られているかどうかhash('0000'+entered_password)に応じて、攻撃者からの攻撃を防ぐために、ユーザーが存在しない場合は別のコードパスを計算することができますかかった時間に基づいて有効なユーザー名を判別すると、パスワードが正しくないと判断されます。

これは、パスワードをオープンテキストで保持していることを示唆しています。これは、セキュリティの低いシナリオであっても、まったく問題ありません。

あなたはむしろ持っているべきです：

if(hash(enteredPassword) == storedHash)

MD5などの単純なハッシュを使用できます

私はハッシュを提案する人々に同意しますが、ここであなたが再発明している車輪もあります。プラットフォームによっては、ユーザーの介入をあまり必要とせずに、すべてのユーザー管理を安全かつ確実にカバーする役割/ユーザー管理ツールを見つけることができます。

特にユーザーの不便さと情報の安全性のバランスを取る必要があるため、セキュリティは非常に扱いにくいテーマです。通常、必要なセキュリティの量の式は、データの重要性の関数です。要するに：

isSecuritySufficient = effortToBreak > rewardForBreaking

悪いことをする人についてよくある誤解は、彼らが何を求めているかです。それらのほとんどは信頼を破壊しようとしています。ユーザーの信頼を守るために、できる限りのことを常に行う必要があります。その一部は、彼らの身元が安全であることを確認するためにデューデリジェンスを行うことです。格納するデータについてはあまり気にかけないかもしれませんが、セキュリティの最低のしきい値であっても、身元については気にします。

多数の低コスト（実装してユーザーに影響を与えるため）のオプションが利用可能です。そのうちの1つは、最低限パスワードをハッシュすることです。パスワードと同じくらい機密性の高いものをプレーンテキストで保存するサービスは、ハッキングされるのは恥ずべきことです。

パスワード保護の一般原則

• パスワードをプレーンテキストで保存しない
• SHA-1やSHA-512などの安全なハッシュ関数を使用したハッシュ（MD5でも一致するハッシュを見つけるのは簡単すぎます）
• アプリケーションのソルト値を使用します。ソルトは、推測しにくいようにパスワードに追加されるランダムなバイトです。実行時にソルトを生成し、マシンに関する情報をシード値として使用して、何らかの方法で保存および参照する必要があります。
• ユーザー固有のソルト値を使用します。これをアプリケーションソルトと組み合わせて使用​​します。
• ネットワークを経由するすべての認証要求を暗号化します。つまり、WebアプリケーションにSSLを使用します。

認証にSSLを使用するため、少なくともユーザーのアカウントを扱うすべてのページも暗号化する必要があります。これにより、ユーザーのIDを可能な限り保護できます。

パスワード管理に関する注意：ユーザーは時々パスワードを忘れます。絶対に最悪のことは、パスワードをメールで送信することです。上記の原則を実装する場合、とにかくそれを行うことはできません。登録済みのメールアドレスに送信されたリンクを使用してパスワードをリセットする方法を提供することをお勧めします。そのリセットリンクには、ページにアクセスする人が彼らであることを保証するための1回限りの使用コードがあります。

パスワードが他に使用されない限り、それは問題ありません。ユーザーがパスワードを再利用できると判断するリスクは依然として存在するため、次の場合にはさらに改善されます。

if(hash(enteredPassword) == hashOfValidPassword)

自分自身またはパスワードがプレーンテキストで保存されていることを知っている人向けの場合は、問題ありません。

ソースコードは利用可能ですか？そうでなくても、バイナリが利用可能な場合は、マシンの指示でパスワードを見つけることができると確信しています。代わりにチェックサムを実行して比較することをお勧めします。

あなたの意見ではセキュリティがそれほど重要ではない場合でも、セキュリティを見落とさないでください。

絶対違う。読んだ本を、それはハッカーがセキュリティのウェブサイトをハッキングする方法について説明します。あなたは、チェーンの中で最も弱いリンクとしてあなたを持っているでしょう。

いくつかの回答で、パスワード自体を保存するのではなく、ハッシュを保存する必要があることが指摘されています。SSLを使用する必要があります。

あなたは言うかもしれません、大したことは何ですか？私のアプリケーションがハッキングされたとしても、それはほとんど問題になりません。まあ、ユーザーがすべてのサイトで同じパスワードを再利用することは非常に一般的なパターンです。サイトをハッキングしてユーザーのパスワードにアクセスするハッカーだった場合、ハッカーはそれらのユーザーにとってより重要な他のサイトで多くのユーザーになりすますことができます。そのため、サイトをハッキングすることは、ハッカーがユーザーの銀行情報にアクセスするための最初のステップになる可能性があります。

そして、パスワードをハッシュするだけでは十分ではありません。塩でハッシュする必要があります。ハッカーは逆ハッシュルックアップテーブルを持っているため、特定のハッシュに対して、一致するパスワードを見つけることができます。

これらの機能を実装しないことを選択した場合は、このセキュリティの欠如をユーザーに通知し、他の場所で使用するのと同じパスワードを使用しないように奨励する必要があります。

これがサーバー側である限り。

もう少しセキュリティが必要な場合は、httpsを使用し、DBでパスワードを暗号化\ハッシュします。