web-dev-qa-db-ja.com

「強力な認証」を必要としないアプリケーションの例

「強力な認証」を必要としない実際のアプリケーションの例はありますか。特に、すべてのアプリケーションに「強力な認証」が必要なわけではないと主張するブログ投稿や科学論文を探しています。たとえば、IPアドレスのみを使用してユーザーを認証する必要がある場合もありますが、それ以上のことは不要です。 ..

[〜#〜] edit [〜#〜]:わかりました、もう少し説明する必要があると思います。開発者または事業主または科学者(科学論文などの公式声明、またはブログなどの半公式)からの議論を探しています投稿)for「非強力」認証を主張します。 事業主の洞察は(私が探している)最も重要なことです。たとえば、@ Florin Coadaの例は素晴らしいですが、この問題に関するAppleの洞察を見る方がよいでしょう。何日もグーグルを試しましたが、使用しているキーワードはまったく無関係な結果をもたらしています。

編集2:答えは素晴らしいです、そして多分私は質問を少し拡張する必要があります(最後に)。サービスのユーザーのプライバシー侵害(熟練したプログラマーのような「パワーユーザー」による)のように、「セキュリティ侵害」のリスクが高いが、「弱い認証」を選択するようなアプリケーションはありますか?

2
FearUs

リスクと戦うための保護が実施されています。リスクが低い場合、保護は低くなる可能性があります。

フォーラムサイトについて考えてみてください。サイトが「強力な保護」を使用する理由はないかもしれません。あなたが本当にやりたいのは、誰が貢献しているかを特定できるようにすることだけだからです。その場合、サイトには非常に弱い保護が必要であると判断できます。

あなたの質問に対する答えはリスク分析にあります。特定したリスクと戦うための適切な保護を提供します。

投稿の明確化を編集:

事業主の視点はリスク計算に基づいています。誰かが誤認された場合のリスク、そのようなリスクが実現した場合のコスト、およびそのリスクを軽減するためのより強力な保護を導入するためのコストは何ですか?削減するコストが実現リスクのコストよりも大きい場合、ビジネスの観点から、より強力な保護を導入することは費用効果が高くありません。

ISO 27005は、このリスク管理フレームワークを提供します。

3
schroeder

あなたが説明していることは、Apple学生割引のように聞こえます。学生割引で何かを購入するには、大学のネットワークからログインする必要があります。

編集:
彼らがこれを行う理由は、彼らがこれを誰もが利用できるようにしたくないからです(救助に明らかな船長)。
人々は一般的にそれらのネットワークにログインする必要があるので、彼らは人々を識別するために大学のネットワークを使用したと思います。
これは、大学のネットワークに接続することで、その大学の学生の資格情報を使用してログインすることを意味します。これにより、彼らはその大学の学生(およびその他)になり、割引の対象になります。

ここで注意すべき重要なことは、AppleによるIP認証の前に別のレベルの認証があるということです。
編集の終わり

この投稿はこちら: http://www.mikewilson.cc/2010/08/18/how-to-get-a-15-discount-at-the-Apple-online-store-from-your- own-home-youve-got-to-be-a-student-though / これについて簡単に説明し、彼がどのようにしてその認証をバイパスしたかについても説明します。

おそらく彼らは、人々が15%の割引を受けるのがいかに簡単であるかを理解したため、unidaysと呼ばれるものを選択しました。それがどのように機能するかはわかりませんが、これはあなたが求めていたものの一例です。

2
sir_k

私はあなたの説明を読みました。次の論文で説得力のある議論を見つけるかもしれません:

一般に、システムを保護する立場にある当事者がセキュリティ障害の結果を被る当事者ではない場合、問題が予想される可能性があります。 [1]

つまり「私たちのためにセキュリティに投資する必要はありません」-議論。この議論をさらに「強力な認証を使用しないという利点があります」に引き込むこともできます。エンドユーザーにとって使いやすいので、最終的にはより多くのユーザーがいることがその一例かもしれません。

[1]アンダーソン、ロス。 「なぜ情報セキュリティが難しいのか-経済的な観点から」コンピュータセキュリティアプリケーション会議、2001年。ACSAC2001年。議事録第17回年次。 IEEE、2001。

2
RedPixel