Webアプリケーションでセキュリティを使用できるようにする方法は？

Question

私は、できるだけ安全にしたいWebアプリケーションを開発する計画段階にあります。技術的な観点からそれを行う方法についてはかなり明確ですが、1つの大きな潜在的なセキュリティホールがあります。サイトにユーザーがいることを望んでいます。

ユーザーであったことがある人なら誰でも知っているように、ユーザーはユーザー名を忘れ、パスワードを忘れ、時々あなたのサイトにアカウントを持っていることを忘れます。ユーザーはフィッシングメールに応答し、資格情報を提供します。あなたが彼らがあなたのサイトを使用しないほど複雑すぎると思う何かをする場合、それは簡単でなければならず、すべてができるだけ少ないクリックで起こる必要がありますが、ユーザーが誤ってできるだけ難しいようにすることでそれのバランスをとる必要があります資格情報を提供し、サービスへのアクセスを可能な限り安全に保ちます。

私が特に興味を持っているのは、標準のユーザー名とパスワードの組み合わせを超えている戦略と、ユーザーが簡単にするが、アカウントを盗もうとする人にとっては難しいパスワードを回復またはリセットする方法です。多くのサイトが追加のユーザーセットのセキュリティの質問を提供していることは知っていますが、ユーザーが「1+1とは何か」などの愚かな質問を作成しないと信用していないため、これがセキュリティを保証する方法はわかりません。

アカウントに侵入することを目的とした、最も無知なユーザーにとって使用可能な戦略はありますか？そうでない場合、私たちが得ることができる最も近いものは何ですか？ユーザーとして、これに遭遇したこれで最良/最悪のサイトは何ですか？その理由は何ですか？

Answer 1

本当に安全なWebサイトを構築する唯一の方法は、パスワードを要求し、チャレンジ/応答デバイスを持つことです。

たとえば、TreasuryDirect.govは、ランダムな文字のグリッドを備えたカードを送信します。ログオンプロセスの一部として、グリッドの特定のセルに含まれる文字を提供するように求められます。しかし、これは高価で時間がかかります。カードを取得し、それらを追跡し、送信する必要があります。さらに、人がカードを失った場合、新しいカードを手に入れるまでログインできません。数百万ドルを管理できる財務省の場合、この手間は価値があります。サイトにとって価値があるかどうかを判断できます。

別のオプションは、多くの銀行がそうであるように、検証画像を追加することです。このオプションは、フィッシング攻撃を妨害するのに役立つと思うので、フィッシングが問題になると思うなら、これがオプションかもしれません。

私は、ほとんどの銀行が使用するものを含む他の代替品は安全であるように見えるが、実際にはそうではないと思います。たとえば、セキュリティの質問は、サイトが役立つ以上に妥協すると信じています。 他の人もこれを考えています.

もう1つのことは、ユーザーがパスワードの代わりに「PassPhrase」を使用することを奨励することです。 ジェフ・アトウッドがお勧めします. 。 Amazonは、新しいPayPhraseでこのアプローチも行っています。

Answer 2

ホイールを再発明すべきではないと思います。ほとんどのWebサイトには、忘れられたパスワードに機能するソリューションがあり、ユーザーの電子メールアカウントへのリンクが送信されています。計画を立てる唯一の方法は、電子メールアカウントが侵害された場合です。

あなたのウェブサイトのユーザーデータがより重要であればあるほど、より多くのセキュリティ対策が必要であることは明らかですが、これらの追加のセキュリティ対策がサイトの使いやすさに影響を与えます。あなたのサイトのデータはどれほど重要ですか？ eバンクのような2つまたは3つの認証システムが必要ですか？

最も重要な側面は、「ユーザーの入力を信頼しないでください」です。これを行うと、ほとんどのセキュリティの問題は存在せず、使いやすさに影響を与えません。妄想的になりたい場合は、先に進んで派手なセキュリティシステムを構築しますが、ユーザーがサイトを使用する方法に影響を与える可能性があることを忘れないでください（最悪の場合）。これら2つのことのバランスを見つける必要があります。

Answer 3

OPに：Webサイトのセキュリティへの標準的なアプローチを使用します。必然的にあなたの安全なサイトからdrれて立ち去るバカのユーザーがいるでしょうが、それは獣の性質です。セキュリティが必要です。柔軟性を犠牲にする必要があります（そして、ユーザーフレンドリーな視点からうまく機能したセキュリティに関する既知のプラクティスがあります）。

その上、ユーザーが去るとき、それは通常、セキュリティ（くだらないウェブデザイン、混乱のナビゲーション、パフォーマンスの低下、信頼性など）以外のもののためです。邪魔なセキュリティは通常、セキュリティ自体ではなく、アーキテクチャの低下の結果です。心に留めておきます。

Answer 4

「使用可能だが安全な」戦線に関する私の唯一の提案は、質問を設定することですが、ユーザーが入力した回答（例：顕著な場所、最初のペットの名前、著名な日付）です。これらは個別に水密ではありませんが、2つまたは3つの人に特定の質問の組み合わせに答えるだけで十分です。

キャプチャの言葉を忘れないでください。

Answer 5

使用することもできます Openid と oauth ユーザーに新しいアカウントを作成させるのではなく

Answer 6

認証とセッションに安全に対処するすべてのエッジケースを理解しない限り、これを自分で実装しないでください。

壊れた認証とセッション管理 OWASPセキュリティのトップ10の問題の1つであり、その理由があります。 「それを正しくする」ことは非常に複雑で、ウェブセキュリティの専門家でなければなりません。

可能であれば、サードパーティの認証システムを使用してください。たとえば、Googleアカウントを使用します。彼らにこれらすべてのことを心配させてください。

Answer 7

あなたのコメントに従って

「1+1とは何か」などの愚かな質問を作成しないとユーザーが信用していません。これがセキュリティを保証する方法がわかりません。

セキュリティを保証する必要はありません - 実際、そのような質問をすることは問題ではないはずです。ユーザーが必要なヒントを設定させます。

今、エバンキングのために、フィッシャーが良いお金を稼ぐ十分なターゲットがあるので、同じスペースにいる場合は、一部の銀行がアンチフィッシングスペースで非常に成功していることを見ることができます - antiphishing.org いくつかの有用な情報があり、次にアプリケーションがあります Trusteerの関係 接続の周りにさらなるセキュリティを提供し、より高い価値領域の場合、彼らは多くの場合、スマートカードの形で2因子認証を使用します。

さまざまなリスクとユーザビリティレベルのソリューションは非常によく理解されているため、再開発よりも既存の概念を再利用する方が簡単であることがわかります。ユーザビリティテストのコストは高くなる可能性があります。