このログインセキュリティで十分ですか？
EコマースWebサイトの管理者向けの次のログインシステムを考えています。
- ログインフォームはSSLで保護されています
- パスワードは送信される前にSHA-256に変換されます（JS /ブラウザクライアントに対してbcryptはまだ遅すぎます）
- bcrypt格納されたハッシュ（盗まれた場合にデータベースが簡単に破壊されることを望まない）
- ハッシュされたパスワードは、アプリまたはファイルに定数として保存された秘密鍵で暗号化されます
- そのユーザーのすべての重要なログインデータベース値のハッシュ。インジェクションによって変更された場合、ハッシュが一致せず、アカウントがロックアウトされます。
- 最初のログイン失敗時の再キャプチャ
- デバイスごとにログインストライクシステム。したがって、ユーザーが5つの異なるログインを試み、それらがすべて間違っている場合、彼は不在です-ログインごとに5ではありません
- 2番目のステップの認証。 SMS、電子メール、またはAlterEgoを使用-多分デバイス+場所ごとに1回、パスワードを変更する場合に使用
- 履歴とは異なる場所からログインする場合は、SMSまたはメールでユーザーに送信します
- ログイン中にデバイスまたは位置情報が変更された場合は、セッションを強制終了します（セッションの盗用を防止するため）
- ログイン履歴を古いデバイスから削除できるようにします（ユーザーは使用しなくなったデバイスを削除できます）
- ログインデバイスと場所を履歴に保存するオプションがあります（ネットカフェやパブリックネットワークなどでこのオプションを使用しないでください）。これにより、常に2番目のステップが要求されます。
このログインセキュリティで十分ですか？私はやり過ぎだと思いますか？
やり過ぎには注意してください。逆効果です。ログインシステムが不便または煩わしい場合、ユーザーは積極的にそれを回避しようとします。ここでの「ユーザー」には、アプリケーション開発者とサーバー管理者が含まれます。
ログインフォームはSSLで保護されています
これは最も重要ですが、「単独」ではありません。理論的には、ログインフォームだけでなく、サイト全体をSSLで保護する必要があります。 SSLは盗聴者に関する機密性を提供しますが、セッションを維持するために後でクリアテキストで送信するCookieが生成される場合、盗聴者は同じCookieを送信してセッションをハイジャックする必要があります。ログインフォームのみがSSLで保護されている場合、ここで得られる唯一のセキュリティは、完全なフィッシング対策トレーニングと組み合わせたものです。あなたeducateを持たないサイトへのパスワードの送信をユーザーが控えますSSLがアクティブであるため、自分でSSLサイトが必要です。しかし、それは限界です。
パスワードは送信される前にsha256に変換されます（JS /ブラウザークライアントに対してbcryptはまだ遅すぎます）
これは役に立たない。これは、SHA-256の結果isパスワードであることを意味します。攻撃者がそれを取得できる場合、攻撃者は「真の」パスワードを知らなくても、それを使用してログインできます。
ハッシュされたパスワードは、アプリ/ファイルにCONSTANTとして保存された秘密鍵で暗号化されます
この機能は、攻撃者がハッシュ化されたパスワードを取得できるが、アプリケーションファイル自体は取得できない状況でのみセキュリティが向上します。これが現実的な状況であるかどうかは議論の余地があります。一方、この一定のキーは、アプリケーションを更新するときに管理者を困らせ、余分なダウンタイムを招く可能性があります（デプロイ時に忘れがちです...）。また、これはアプリケーションファイルの機密性を重要な目標にしますが、これはあまり一般的ではありません。
最初のログイン失敗時の再キャプチャ
これは安全というより迷惑です。
デバイスごとのログインストライクシステム。したがって、ユーザーが5回のdiffログインを試行しても、すべてが間違っている場合、彼は不在です。ログインごとに5つではない
アカウントをブロックせず、遅延を追加するだけです（たとえば1分）。さもなければ、誰もが誰のアカウントもロックすることができ、これは問題です。デバイスごとの試行のカウントは適切ですが、微妙であり、裏目に出る可能性があります。サーバーの観点から、大量のNATまたはプロキシになる）のネットワークがいくつかあります（ISPを含む） 、同じソースIPからの何千ものログインリクエスト。
SMS、メールを使用した2ステップ認証？またはAlterEgo-多分デバイス+場所ごとに1回、パスワードを変更する場合に使用します
履歴とは異なる場所からログインする場合は、SMS/Eメールをユーザーに送信します
SMSはユーザーを困らせる可能性があります。海外のユーザーにはうまく機能せず、その場で機能する携帯電話を必要とし、一部の人はSMS携帯電話プロバイダー）電子メールはわずかに優れています（ただし、保護しようとしているアプリケーションがWebメールの場合は、もちろんnot）。
ログインデバイスと場所を履歴に保存するオプションがあります（つまり、ネットカフェやパブリックネットワークなどでこのオプションを使用しないでください）。これにより、常に2ステップが要求されます。
ネットカフェでは、セキュリティが低下することに注意してください。キーロガーはあまりにも見えません。それに対してできることはあまりありません。
だから私はやりすぎだと思いますか？
はい。しかし、さらに重要なことには、サイト全体のSSLという重要な機能も欠けています。
私が常にプロジェクト定義仕様で探している主要な要素はここにありません：
何を保護していますか？誰を保護していますか？侵害された場合の影響は何ですか？
友達の誕生日リストを保護しているのなら、それはほぼ間違いなくやり過ぎです。トップシークレットの資料を国際スパイまたは企業スパイから保護している場合は、弱すぎる可能性があります。
潜在的なリスク、あなたを標的とする可能性のある攻撃者、および回復力などの他の要因（月曜日の朝にログインに失敗すると、本当に必要なときにユーザーがアクセスするのが非常に困難になります）について考える必要があります。
うまくいけば、あなたはこれらの答えを持っているでしょうが、ここに投稿しない限り、他の人がセキュリティアーキテクチャに関するガイダンスを提供するのは難しいかもしれません。
ここでは多くのセキュリティ流行語を使用していますが、最終的な結果は必要以上に安全ではなく、Lucanosが言うように冗長性がたくさんあります。
読んでください このスレッド 。
パスワードは送信される前にsha256に変換されます（JS /ブラウザクライアントにとってbcryptはまだ遅すぎる）bcrypt格納されたハッシュ
それはあなたがパスワードのsha256ハッシュのbcryptハッシュを生成することを意味しますか？ saltがないと、sha256パスワードはセキュリティに役立ちません。また、2回目のハッシュを使用しても効果がありません。
ハッシュされたパスワードは、アプリ/ファイルにCONSTANTとして保存された秘密鍵で暗号化されます
何？どうして？パスワードのハッシュのハッシュを回復したいですか？そうしたとしても、これを行う方法は、公開鍵を使用して暗号化することです。
最初のログイン失敗時の再キャプチャ
多くの付加価値はありません。
ログイン中にデバイス/場所の情報が変更された場合は、セッションを終了します
したがって、ここでは認証だけでなくセッション管理についても話します。その場合、まだやらなければならないことがたくさんあります。
ここに記載されていないことがいくつかあり、おそらく追加する価値のあるものは1つまたは2つあります。
- ハッシュされたパスワードは、アプリ/ファイルにCONSTANTとして保存された秘密鍵で暗号化されます
「定数」として-それはどういう意味ですか？ハードコードされていますか？どのように保護されていますか？ソルトは良い計画であるという他の投稿にも同意します。パスワードをソルトしてハッシュする場合、その上に暗号化の必要性はありません。また、暗号化の秘密鍵がフラットファイルに保存されているか、アプリにハードコードされている場合は、そこに弱点があります。このキーをより適切に保護する方法を見つけることをお勧めします。
- 「デバイスごと」
多くの場所で、「デバイスごと」の行動を追跡しているとおっしゃっていますが、それはどういう意味ですか？デバイスはどのように決定していますか？ここでデバイス認証のタイプを示唆しています。この領域について私がほとんど知らないことから、ほとんどの方法は非常になりすましが可能であり、信頼できるポイントからのデバイスの発行を必要としない方法は、操作のモデルを大きく変える可能性があります。 。
「デバイスごと」と言う場所では、デバイスがシステムを偽造している場合、それが何を意味するのかをよく考える必要があります。また、「IPアドレス」=「デバイス」と決定した場合、ユーザーの障害なしにユーザーのIPアドレスが変更される多くの状況を考慮する必要がある場合があります。
- ログイン履歴を古いデバイスから削除できるようにする
それはあなたが完全にサポートする準備ができているものですか？たとえば、Cookieのスクラブは非常に簡単ですが、メモリのすべての部分を意味するのでしょうか。個人的には、この約束をする場合、何らかの方法でそれをバインドしたので、ログイン情報がOSによってどこか奇妙な場所に置かれた場合でも、それは私のシステムがユーザーに約束したことの違反ではありませんでした。
私もいくつかの問題を見ます：
- ユーザーは、紛失/忘れたパスワードからどのように回復できますか？
パスワード変更のかなり複雑なプロセスを引用しているようですね。これがカジュアルなWebシステムである場合、これが最も使用頻度の低い機能になると私は考えています。代わりに、ユーザーはシステムから離れて、パスワードを返して必要とし、それらを完全に忘れてしまいます（または、画面上の付箋にパスワードを書き込んだ...さらに悪いことです）。
高度な保護モデルに適合するパスワードの回復/リセットを行う方法が必要です。人員配置ですか？答えるべき質問がありますか？彼らは帯域外で彼らに電子メールで送られるリセットパスワードを受け取りますか？それぞれの回復メカニズムにはリスクがあり、一般的にリスクが低い=コストが高くなります。たとえば、このような問題に対する私のクレジットカード会社の最終的なIDチェックは、私の購入履歴に関する実際の人との苦痛なQ＆Aです。非常に良いですが、その人の給与に関しては高額です。
- ユーザーがシステムを精査するための簡単な方法
サーバーがSSLで提示する資格情報は十分なはずですが、PKIに精通しているユーザーはほとんどいません。大手金融機関が、ログイン時にユーザーが確認するはずのユーザーが選んだ単語や写真を活用し始めたことを知っています。ここでの全体的な目標は、フィッシング詐欺師がユーザーに「paypa1.com」（lではなく1番）に誘導するメールを送信し、パスワードを取得する状況を回避することです。リモートログインに対応する機能があるため、攻撃者はどのシステムからでも正規のユーザーアカウントを使用できます。
- その他の社会工学
これらの2つの問題は、おそらく人間が考える必要のあるプロセスだけではありません。アクセスをログに記録していますか？ログイン監査と管理権限を分離する計画はありますか？管理者にはどのくらいのアクセス権があり、システムはどのように保護されていますか？機能する可能性のある他のソーシャルエンジニアリング攻撃はありますか？
これまでのところ、概説しているのは技術が重く、人間の明かりです-ユーザービリティに影響を与える可能性のあるいくつかのメカニズムについて話しているため、ユーザーがシステムを使用していないか、ユーザーがシステムをハッキングするための手順を実行する可能性があります使いやすくし、ソーシャルエンジニアの攻撃ベクトルについて考えたことがないのではないかと心配しています。水のように、ハッカーは最も使いやすい亀裂や隙間を見つけます。
私はここで重いものにぶつかっています。私の考えでは、リスクが高いと思われるものに対して、ある程度ハイエンドなものを設計しようとしているからです。それが設計しようとしているものである場合は、バックアップしてwholeシステム-ユーザーコミュニティ、アカウントの誕生から死亡、システム内の動作、および不正な動作のリスクを確認する必要があります。
私はいくつかの質問を試してみて、1）自分自身を教育し、2）システムについて別の見方をします。
パスワードは送信される前にsha256に変換されます（JS /ブラウザークライアントに対してbcryptはまだ遅すぎます）
はじめにSSL接続を使用している場合、これを行う必要がありますか？誰かがハッシュされたパスワードを傍受できたとしても、平文のパスワードを傍受するよりも安全ですか？ログインを偽装して同じハッシュ化ペイロードを送信できた場合、それはどのように違うのですか？
そのユーザーのすべての重要なログインデータベース値のハッシュ。インジェクションによって変更された場合、ハッシュは一致せず、アカウントはロックアウトされます。
したがって、ユーザーがメールアドレスまたはパスワードを更新すると、ハッシュが変更され、セッションが終了しますか？または、これらの正当な変更を処理できるようにする保護手段はありますか？
ログイン中にデバイス/場所の情報が変更された場合は、セッションを強制終了します（セッションの盗用を防ぐため）
これについては100％確実ではありませんが、WiFiからGSM/Cell、GSM/CellからWiFiに、またはGSM/Cellネットワーク内で（変更された場合）移行すると、（正当な）セッションからモバイルハンドセットがキックされる可能性がありますデバイスによって提示されたパブリックIPアドレス）？
デバイスごとのログインストライクシステム。したがって、ユーザーが5回のdiffログインを試行しても、すべてが間違っている場合、彼は不在です。ログインごとに5つではない
「デバイスごと」をどのように追跡していますか？ IPアドレスで？共有できます。クッキーで？パージできます。 User-Agent文字列で？それも変更できます。
これらとは別に、他のいくつかのアイデアはいい音に聞こえます。
わかりました、これは私がみんなの反応から学んだことです
- SSLを使用してください。クライアント側のパスワードを無意味なものとしてハッシュする必要はありません。SSLは盗聴から保護するための正しい方法です。
- PHPの実装が見つかった場合は、BCrypt（w/Salt）を使用してパスワードハッシュ、SCryptを保存します。
- 失敗したパスワードのためにログインをロックダウンせず、DOSを防ぐために時間制限を増やしてください。もちろん、失敗した試行を記録し、異常に高くなった場合は管理者に警告します。
- パスワードの暗号化と再ハッシュは無意味です
- システムを精査し、ソーシャルエンジニアリングを防ぐ方法を検討する
- passwdqcを使用して確認し、ユーザーに予想されるパスワードをユーザーに通知するなど、ユーザーに長くて難しいパスワードを強制します。
- 携帯電話、ワイヤレス、または一部のISPでは、デバイス/場所の変更が原因でロックダウンが問題になる可能性があります。セッションからログアウトすることを検討してください。
- セッション管理を適切に実装する必要がある
- 管理セッションはSSL領域内に留まる必要があります。