「if password == XXXXXXX」で最低限のセキュリティを確保できますか？
セキュリティリスクが中〜低のアプリ（つまり、バンキングアプリではない）のログインを作成する場合、次のように言うだけでユーザーが入力したパスワードを確認できます。
if(enteredPassword == verifiedPassword)
SendToRestrictedArea();
else
DisplayPasswordUnknownMessage();
効果的であるように思えますが、それだけで十分かと思います。ユーザー名とパスワードの組み合わせの簡単なチェックで十分ですか？
pdate：特定のプロジェクトはたまたまWebサービスであり、検証は完全にサーバー側であり、オープンソースではありません。ドメインはこれへの対処方法を変更しますか？
SSLなしではありません
パスワードがネットワークを介してプレーンテキストで送信される場合、これは安全ではありません。パスワードがプレーンテキストでネットワーク経由で送信される場合、サーバー側でのパスワードのハッシュも安全ではありません。
HTMLの_<input type="password"/>_タグはコンテンツをプレーンテキストで送信するため、WebサイトがSSLを使用してパスワードを送信しない限り、サーバーにパスワードを保存する方法に関係なく、これは問題になります。
（ブラウザーでダイアログボックスを表示してパスワードを要求するHTTP認証は、サーバーとブラウザーに共通の認証メカニズムによっては、クリアテキストの場合とそうでない場合があります。これは、 SSL）
サイト管理者が疑わしい場合は不可
ここで、HTTPSを使用してWebサイトを構築している場合、サイト管理者（プレーンテキストのパスワードを読み取ることができる）や、マシンにアクセスして適切に動作する他のユーザーを信頼している場合、これは安全です。これで、彼らがあなたのWebサイトで（彼らが管理しているので）何でもできることは明らかですが、パスワードを読み取れる場合、他の人のサイトで盗まれたログイン/パスワードのペアを使用できる可能性があります。
管理者からパスワードを安全に保つ方法
パスワードを保存および確認する安全な方法の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
_ハッシュ関数については、強力なものを使用し、まだ一般的なRainbowテーブルを備えていないものを使用してください。レインボーテーブルで必要に応じて、塩の長さを変更できます。
現在の環境、ネットワークレイテンシの変動、ユーザー名が公に知られているかどうかに応じて、ユーザーが存在しない場合は別のコードパスhash('0000'+entered_password)を計算することをお勧めします、攻撃者がパスワードが正しくないと判断するのにかかる時間に基づいて有効なユーザー名を判断できないようにするため。
これは、パスワードをオープンテキストで保持することを示唆しています。これは、セキュリティの低いシナリオでも、禁止事項です。
あなたはむしろ持っているべきです：
if(hash(enteredPassword) == storedHash)
たとえばMD5のように単純なハッシュを使用できます
ハッシュを提案する人にも同意しますが、ここであなたが再発明しているホイールもあります。プラットフォームによっては、ユーザーの介入をあまり必要とせずに、ユーザー管理のすべてを安全かつ確実にカバーする役割/ユーザー管理ツールを見つけることができます。
セキュリティは非常に扱いにくいテーマです。特に、ユーザーの不便と情報の安全性の確保のバランスを取る必要があるためです。通常、必要なセキュリティの量の式は、データの重要度の関数です。要するに：
isSecuritySufficient = effortToBreak > rewardForBreaking
悪いことをする人々についての一般的な誤解は彼らが求めているものです。それらのほとんどは破壊するtrustです。ユーザーの信頼を保護するために、できる限りのことを常に行う必要があります。その一部は、彼らのidentityが安全であることを確認するためにあなたのデューデリジェンスを行っています。格納するデータはそれほど重要ではないかもしれませんが、セキュリティの最低しきい値であっても、IDは重要です。
（実装してユーザーに影響を与える）低コストのオプションがいくつかあります。それらの1つは最低限パスワードをハッシュすることです。パスワードと同じくらい機密性の高いものをプレーンテキストで保存するサービスは、ハッキングされる恥ずかしさに値します。
パスワード保護の一般原則
- なしパスワードをプレーンテキストで保存
- SHA-1またはSHA-512のような安全なハッシュ関数を使用したハッシュ（MD5でも一致するハッシュを見つけるのは簡単すぎる）
- アプリケーションソルト値を使用します。 saltはランダムなバイトであり、推測をより困難にするためにパスワードに追加されます。ソルトは、実行時に生成され、マシンに関する情報をシード値として使用する必要があります。格納や参照は一切行われません。
- ユーザー固有のソルト値を使用します。これをアプリケーションソルトと組み合わせて使用します。
- 暗号化ネットワークを経由するすべての認証要求。つまり、SSLをWebアプリケーションに使用します。
認証にSSLを使用するため、少なくともユーザーのアカウントを扱うすべてのページも暗号化する必要があります。これにより、ユーザーのIDを可能な限り保護することができます。
パスワード管理に関する注意：ユーザーは時々パスワードを忘れます。あなたにできる絶対worstことは彼らに彼らのパスワードを電子メールで送ることです。上で概説した原則を実装する場合、とにかくそれを行うことはできません。登録済みの電子メールアドレスに送信されたリンクを使用してパスワードをリセットする方法を提供することをお勧めします。このリセットリンクには、ページにアクセスするユーザーが本人であることを確認するための1回限りの使用コードがあります。
パスワードが他の目的で使用されない限り、それで問題ありません。ユーザーがパスワードを再利用できるとユーザーが判断するリスクはまだあるので、次のようにするとさらに良いでしょう。
if(hash(enteredPassword) == hashOfValidPassword)
自分自身またはパスワードがプレーンテキストで保存されていることに気づいている人のためである場合は、問題ありません。
ソースコードは入手できますか？そうでない場合でも、バイナリが使用可能な場合に備えて、マシンインストラクションでパスワードを見つけることができると確信しています。チェックサムを実行し、代わりにそれを比較することをお勧めします。
あなたの意見ではそれほど重要ではない場合でも、セキュリティを見落とさないでください。
絶対違う。 this を読んで、ハッカーがセキュリティWebサイトをハッキングした方法を説明します。あなたはあなたを鎖の中で最も弱いリンクとして持っていることを計画します。
いくつかの回答では、パスワード自体ではなくハッシュを保存する必要があることが指摘されています。また、SSLを使用する必要があります。
あなたは言うかもしれません、大したことは何ですか？アプリケーションがハッキングされた場合、それはほとんど問題になりません。ユーザーがすべてのサイトで同じパスワードを再利用するのは、ごく一般的なパターンです。あなたのサイトをハッキングしてユーザーのパスワードにアクセスするハッカーだった場合、ハッカーは他のサイトでそれらのユーザーにとってより重要なユーザーの多くになりすますことができます。したがって、サイトをハッキングすることは、ハッカーが銀行情報にアクセスするための最初のステップになる可能性がありますユーザーにとって。
そして、パスワードをハッシュするだけでは十分ではありません。塩でハッシュする必要があります。ハッカーは逆ハッシュルックアップテーブルを持っているため、特定のハッシュについて、一致するパスワードを見つけることができます。
これらの機能を実装しないことを選択した場合は、セキュリティが不足していることをユーザーに通知し、他の場所で使用しているのと同じパスワードを使用しないように促す必要があります。