Forgot Passwordサービスを次のように実装しました。
これはかなり標準的なことです(ただし、その小さな部分を変更することはできます)が、不思議に思いました。良いパスワードはあまり頻繁に提供/記憶されないため、パスワードを省略して、代わりに「パスワードを忘れた」システムを使用してみませんか?
どちらのシナリオでも、ユーザーの電子メールセキュリティ(盗聴されたものか侵入されたものかにかかわらず)が一般的な脅威ですが、2番目のシナリオでは:
何が不都合なのでしょうか。私は見えます:
それは単なる考えです。
答えを出してくれた皆さんのおかげで、本当に興味深い(そして間違いなく有効な)指摘がいくつかあり、私は本当に考えさせられ、調査する領域が増えました。 D.W.この特定のタイプの状況についてのさらなる洞察を提供するリンクが提供されているため、ティックが取得されますが、与えられたすべての回答に本当に感謝しています。
それは妥当です。セキュリティの観点からは、妥当です。私はWebサーバーのパスワードを決して書き留めない人を知っています。ログインするたびに「パスワードを忘れた」リンクを使用するだけです。
ユーザビリティの観点からは、電子メールは瞬時ではないため、少し残念かもしれません。ユーザーは[メールで通知]をクリックし、メールが表示されるのを待ってから、メールのリンクをクリックする必要があります。残念ながら、ユーザーがメールが表示されるまで数分(または15秒だけ)待たなければならない場合、ユーザーは迷惑になり、あきらめて、他のことをするか、競合他社に行く可能性があります。
さらなる改善。アイデアを少し改善して、ユーザビリティへの影響を減らすことができます。ユーザーがメールのリンクをクリックすると、ブラウザに永続的な安全なCookieを設定できます。その結果、ユーザーがリンクをクリックすると、ユーザーはリンクをたどり、パスワードをクリアしない限り、今後このコンピューターで再度リガマロールを実行する必要がなくなります。同じコンピューターからの今後のアクセスでは、サイトはそれらを自動的に認識し、ログインやリンクをクリックする必要はありません。
これは、ユーザーのルームメイトがアカウントにログインするのを防ぐ必要があるオンラインバンキングなどの高セキュリティサービスには適切/十分ではありませんが、ほとんどのWebサイトでは問題ないかもしれません。
評価これは、このアプローチを調査し、それが本書で評価された攻撃に対するセキュリティを強化することを発見した研究論文です。
クリスカーロフ、J.D。タイガー、デビッドワグナー。 条件付き安全な儀式とWeb認証へのアプリケーションのユーザー調査 。 NDSS 2009。
これはOpenIDのように見えますが、さらに悪いことに:
OpenIDから次の問題を継承します。
OpenIDに不利な点が追加されます。
これは、認証のために事前に登録された携帯電話にピン番号をテキストで送信するサイトのような2要素認証スキームを思い出します。
私が上で実際に見なかった1つのことは、これの利点は何ですか?それは確かにユーザーにとってより多くの仕事です。最初の登録確認メールでさえ人々を困らせる。ログインするたびに受信トレイが汚染されます。オンラインバンキングに毎日少なくとも1日に1回ログインします(10分後にログアウトします)。何千もの「ログイン」メールが届きます。また、メールの配信が遅い場合もあります。 Gmailがたまに時間がかかるため、サイトにログインするまで5分ほどお待ちください。サービスの稼働時間は、世界中のメールサービスの稼働時間に関連付けられています。
このスキームの問題は、実際には何も得られないことです。 vast大多数の人々は、ほとんどのサービスで同じパスワードを使用しています。したがって、メールにログインして、最初のパスワードを使用しただけの場所へのリンクを取得するように強制します。また、盗聴の新しい場所であるため、弱点も生じます。現在、共有シークレット(パスワード)を使用して、HTTPS経由で接続できます。攻撃者は、私が誰であるか、自分のパスワードなどを知ることはありません。あなたのスキームでは、everyログインするには、この認証リンクを平文で送信する必要があります。
パスワードのリセットの結果として、注目を浴びる多くの違反がありました。最近の最大の問題はサラ・ペイリンだったと思います(ただし、彼女はすべての公平性についてセキュリティの質問をしました)。パスワードのリセットは一般的に厄介であり、私たちはそれらの使用をこれ以上奨励すべきではありません。
最初のポイントは次の点にあります。ほとんどの「パスワードを忘れた」機能は、認証プロセスの弱いリンク(またはweakestリンク)です。
ただし、ログインごとに「パスワードを忘れた」プロトコルのようなことをするというあなたの考えは、実際には多くの2要素認証スキームの2番目の要素に似ています。 RSAトークン。専用のハードウェアではなくソフトウェアでログイン識別子を生成する「ソフトトークン」をすでに入手できます。 (たとえば、ハードトークンをポケットに入れて一日中持ち歩くのではなく、iPhoneで実行できるようにするためです。)
私は、そのスキームとあなたのスキームとの概念的な違いを2つだけ見ます。
これらの違いはどちらも、一般的な2要素スキームと比較するとセキュリティを弱めます。
あなたはcould暗号化されていない電子メールを使用しないことでスキームをより安全にします。 S/MIME電子メールを送信するか、他のプロトコル(Appleプッシュ通知システム)など)を暗号化して使用することができます。
全体として、これは興味深い思考の練習ですが、「パスワードを忘れた」プロトコルの難しさを強化する方がよいでしょう。または、ユースケースによっては、自動パスワードリセットを完全に削除し、800番に電話して忘れたパスワードをリセットするなど、攻撃者を阻止する戦略を使用することができます。
「セキュリティの観点から、それは合理的です」と書いたポスターには同意しません。あなたのスキームは、1つの危険なセキュリティプロトコルを別の危険なセキュリティプロトコルと交換しているだけだと思います。
メールパスワードリセットシステムは、DNSと同じくらい強力です。システムはクールですが、電子メールの受信トレイをシングルサインオンツールとして使用できると提案するのではなく、安全でないパスワードリセットフォームがいかに重要であるかを強調するために多くのことを行います。
これらのパスワードリセットフォームでは、パスワードの変更のみが許可され、「パスワードはyyyy-mm-ddにabcdから最後に変更されました」と同等であり、ログイン後に「最後にyyyy-mm-ddにログインしたabcd "メッセージ。このようにして、ユーザーは少なくとも1つがリセットを要求するよう強制され、2。日付に気付く可能性があるため、ユーザーのアカウントが侵入された手がかりが少なくとも得られます。
キャッシュポイズニングは、リゾルバーへの最新のパッチではさらに難しくなりますが、不可能ではありません。DNSの分散された性質とUDPへの依存のため、メールアカウントまで、何千ものサーバーにわたって小さなランダム化スペースを1日中利用できます。成功したログインを収集します。
DNSsecを取得すると、ネットワーク上のログインを盗聴したり、受信トレイから読み取ったりしても問題がなければ、システムは正常に動作します...
はい、セキュリティの面からは合理的です。 (ただし、ユーザーが常にマスターパスワードを使用する必要があるなど、他の人が指摘したいくつかの欠点があります。)
しかしいいえ、物事を台無しにする実用的な観点から。たくさん-「ユーザーの苛立ち」として軽視できない方法で。
たとえば、人々は常にGmailなどにログインしていると想定しています。一部のユーザーには当てはまりますが、ほとんどのユーザーにも当てはまりますが、多くのユーザーには当てはまりません。また、多くのモバイルシナリオには当てはまりませんが、ユーザーはメールからブラウザーと同じ環境へのリンクを簡単に開くことができると想定しています。
根本的なポイントはこれです:メールとブラウジングは別のシステムです彼らはそうではありません確かにを持っていますが、はです。これは基本的に期待それらは分離している。したがって、ITエコシステム全体の事物は、それらのシステムが分離していることを期待する方法で設計されています。実行していることが素敵なハックであっても、ただ進むことはできません他の人たちが作った仮定を念頭に置いて物事を設計します。そうすると、予期しないあらゆる種類のトラブルに遭遇します。
Forgot Passwordサービスを含める場合、パスワードを使用する意味は何ですか?
ユーザーが既知のパスワードを使用してアカウントにログインできる場合、攻撃者はパスワードリセットリンクを使用しておらず、パスワードを変更していないことがわかります。
パスワードをリセットするとノイズが発生します。ターゲットシステムのログ(ユーザーによって表示される場合があります)、およびパスワードリセットの電子メール用のユーザーのメールボックス、および理想的にはアカウントでパスワードが変更されたという電子メール通知。
メールボックスにアクセスできる攻撃者は、これらの電子メールを削除するだけでなく、パスワードを変更してログインするためのリンクを使用する可能性があります。ただし、パスワードマネージャーに保存されているパスワードを使用してシステムにログインできない場合は、この方法でアカウントが侵害されていることを示しています。毎回パスワードリセットリンクを使用しただけの場合、これを知ることはありません。
もちろん、それは単なる赤信号であり、それ自体の決定的な証拠ではありません。サービスの管理者に、パスワードがリセットされたときのログを提供するよう依頼する必要があります(または、この機能があるかどうか確認してください)。これらのログをパスワードマネージャーのログと比較して、パスワードが最後に変更された日時を確認できます。この時点でパスワードを変更しなかった場合は、何かがおかしいことがわかります。
このため、パスワードでアクセスを保護すると、アカウントの整合性を確保できます。
この答えが最適であるかどうかはわかりませんでした その質問 またはこれです。ただし、どちらにも当てはまると思います。もう一方は間もなく閉鎖される可能性があります