Webアプリケーションでのユーザーアクセスとパスワード処理の使いやすさとセキュリティ？
改ざんされたくない個人データを扱う一般ユーザー向けのウェブサイトを構築しようと思っています。どのようにしてサイトを安全にするだけでなく使用可能にすることができますか？
ほとんどのサイトでは、かなりよく理解されているユーザー識別子（電子メールアドレスが最適のようです）とパスワードを使用しているようです。
一部の銀行サイトでは、PINまたは標準の識別子に続くセキュリティの質問、またはパスワードの置き換えによってこれを超えています。この点で成功したことが証明された他の選択肢について知りたいと思います。
また、アカウントの詳細をフィッシングすることを困難にするために、ユーザーが特定されたら、ユーザーが自分のカラースキームを選択したり、サイトのルックアンドフィールを許可したりすることも聞いています。これを使用しているサイトと、それがどれだけうまく機能するかを知っている人はいますか？
ほとんどのシステムの本当の弱点は、パスワードのリセット機能にあるように思えます。ユーザーは常にパスワードを忘れているため、ここでユーザーを支援するための何かが必要ですが、役立つものと恐ろしく安全でないものとのバランスを取るのは本当に難しいようです。ここでも、ユーザーのセキュリティの質問のアプローチが広く使用されているようですが、私が遭遇したこの2つの側面は、ユーザーが設定して回答を提供する質問を持っているか、ユーザーに関する不変の質問を持っています。
ユーザーから提供された質問では、これが非常に重要であるとユーザーに伝えようとしても、「1 + 1とは」という質問をしないとは思わない。
不変の質問では、単純な事実ではなく、物事についてユーザーの意見を求めている場合、彼らは変化する可能性が高くなります-それらは、実際には非常に簡単に見つけられるようなもの（親のファーストネーム、ファーストペット）に変わる傾向がありますユーザーを攻撃のターゲットにしている場合はアウトします。
安全なものと使いやすいものの間には常に妥協点があると思いますが、ほとんどのサイトが今よりもうまくできるはずです。ユーザーアカウントのセキュリティに対して、従来型ではないが信頼性の高いアプローチを提案できますか？画像グリッド、カスタムキャプチャなどの話を聞いたことがありますが、実際にこれらの経験はありますか？これを特にうまく管理しているサイトはありますか、そしてどのように/なぜそれらが機能するのかを示しているなら？
良い質問。
ショートバージョン
ほとんどのサイトと同様に、ユーザー名/メール/パスワード以外にもいくつかのオプションがあります。究極のセキュリティ問題を解決することはできませんが、教育はできます。キャプチャに代わるものがあります。セキュリティと使いやすさは、終わりのない健全な議論です。
ログイン時の追加のセキュリティオプション
Yahoo! 「 sign in seal 」という概念を使用しており、テキストまたは画像を選択でき、そのカスタマイズはCookieに保存され、戻ったときにサインインページに表示されます。ここでの考え方は、フィッシング攻撃の防止に役立つということです。ユーザーにフィッシングの技術的な詳細を説明する代わりに、「URLが https://www.yahooで始まることを確認してください。 com "の場合は、カスタマイズしたテキストまたは画像をページで探すようにユーザーに指示するだけです。そこにない場合は、適切なサイトにいないので、ログイン資格情報を入力しないでください。
World of Warcraftは、 Blizzard Authenticator を使用します。これは、注文して出荷したデバイスか、iPhone/Androidアプリのいずれかです。どちらも、アカウントに関連付けられた一意のコードを毎分生成します。ログインするときは、Battle.netの登録済みメールアドレス、アカウントパスワード、およびそのBlizzard Authenticatorコードを提供する必要があります。それはゲームですが、World of Warcraftはそれ自体がフィッシング大陸ですが、このアプローチはフィッシングによってハッキングされたアカウントの数を減らすのに非常に効果的であることが証明されています（誰かのメールアカウントにハッキングして、World of Warcraftのパスワードを取得または変更した場合でも、その実際の特定の同期オーセンティケータコードがない場合は、ログインできません）。オーセンティケーターは理論的にはハッキング可能ですが、そのためにはさらに多くの作業が必要です。
myOpenID は、Yahoo！と同様のサインインシールを使用します。 「あなたの個人的なアイコン」と呼ばれます。 OpenIDには追加のセキュリティの影響があります（たとえば、私のOpenIDにアクセスすると、そのOpenIDで使用しているすべてのサイトにアクセスできるようになる可能性があります）。ただし、ほとんどの非技術系ユーザーがOpenIDプロバイダーのOpenIDアカウントを持っているとは思わないので、これはそれほど重要ではないかもしれません。それでも、JanRainがさらに1マイル進んだことはすばらしいことです。
ユーザーがセキュリティに関する明確な質問と回答を提供した場合の対処
これはあなたが解決できない問題であり、あなたの責任ではありません。注意すべき点は、ユーザーが注意を払う必要があることについてユーザーを教育することにより、ユーザーの適切な行動を促進することです。あなたが持っているユーザーベースのタイプに応じて、あなたはそれについて多かれ少なかれ積極的になることができます-例えば、Yahoo！ブリザードは非常に攻撃的であり、前述のように、より積極的なセキュリティ支援を実装しています。
あなたができるいくつかのこと：
- 英数字だけで構成されていない一意のパスワードを使用するようにユーザーに通知する
- パスワードは存在しない単語から作成する必要があることを説明し、その型に合う覚えやすいパスワードを作成する方法を説明するのに役立ちます
- ユーザーがセキュリティパスワードのリセットの質問を作成するフロー中に明確なコピーを使用し、他の人が答えを知らない重要な質問をすることの重要性を強調する
- 人々が使用できる質問の例を提供する（しないでください最近Facebookで簡単に見つけられる「母の旧姓」のような例を提供してください）
- FAQアカウントを保護するためのヒントを提供します。ウェブメールはよく使用されるセキュリティホールであるため、メールアカウントを保護するための基本的なヒントとフィッシングの試みを監視する方法を提供します
責任あるウェブサイト所有者になる。私は「スリに気をつけて」とサインアップしている駅を訓練するのに似ています。個人として、財布をはっきりと見えないようにし、盗まれたときに不平を言うのはあなたの責任です。しかし、注意を払うように人々に思い出させるのは、駅管理のいいところです。 Webでの問題は、多くの人々が何を注意深く見て、どのように脅威を特定するかを知らないことです。私たちは、接触するすべての人に常に一貫して教育を行うことで、支援することができます。
キャプチャと代替
Captchaが存在する理由は2つあります。1つは、サイトがDDOSされないようにするため、2つは、ハッカーが辞書攻撃を実行できないようにするためです。しかし、欠点は、ほとんどの場合、彼らは非常に友好的ではなく、「 Do n't Make Me Think 」ではないということです。
辞書攻撃を防ぐ、または少なくとも阻止したい場合は、ログイン画面にタイマーを追加することを検討してください。ほとんどのユーザーは、たとえば5回の試行後に参加しますが、それ以上のことは疑わしい動作です。通常のユーザーではなく、犯罪者に問題を引き起こすことにより、辞書攻撃を煩わしく実行します。
セキュリティと使いやすさ
ジェイコブニールセンは昨年パスワードフィールドにユーザビリティの問題があり、 入力のマスキングをやめるべきであると書いたとき、スプラッシュを引き起こしました 。入力をマスクすると、誰かがあなたの真後ろに立っているときのセキュリティリークが実際に防止されるだけであり、99％の場合はそうではない、と彼は主張しました。ユーザビリティの専門家として、彼と議論するのは難しい。そして、セキュリティの専門家であるブルースシュナイアーも 同意 しました！
したがって、セキュリティと使いやすさは、実際には解決できない論争の的となる問題です。そして、それは健全な議論です：物事がどちらかの方向にあまりにも遠くに動いたならば、それはエンドユーザーにとって良くありません。 UIデザイナーとして、セキュリティエキスパートの主張を認識し、ユーザーエクスペリエンスを設計するときにそれらを考慮することが重要です。
実際、ほとんどのプロバイダーがログインAPI（通常はOpen Authに基づいている）を提供しているため、ユーザーのログイン/認証の問題に対処する必要すらありません。ユーザーにFacebook、Google、Yahoo、Twitterなどでログインさせるだけです。Google、Microsoft、Yahooなどだと思います。 al。ログイン資格情報を保護し、パスワードのリセットを処理することは、私よりも優れています。ユーザーは新しい資格情報を覚えておく必要がないため、これは本当にユーザーにとって最良のケースです。ほとんどの場合、ユーザーが既にメールにログインしている場合は、再度パスワードを入力する必要はありません。ワンクリック（タイピングなし）でのサインインに最適です。
この作業には2つの小さな落とし穴があります。 （1）すべてのユーザーを不便にすることなく確実にキャプチャするには、比較的多数のログインプロバイダーをサポートする必要があります。 （2）プロバイダーはAPIを変更したり（多くの場合警告なしに）メンテナンスを行ってユーザーを効果的にロックアウトしたりできるので、ユーザーがサイトのアカウントに複数のサインインプロバイダーを追加できるように、アカウントリンクをサポートおよび推奨する必要があります。あなたのサイトの。
通常、ユーザーのパラメーターをプロバイダーから直接取得できるため、ユーザーは電子メールアドレス、名前、電話などの情報を入力する必要がありません。
正直に言うと、厳密にプログラミングの観点から答えを誤って入力する可能性があるため、プログラマとしての個人的な質問/回答のセキュリティ手順はあまり好きではありません。彼らの答えが名前だった場合はどうなりますか？しかし、名前全体を入力したのか、短い名前だけを入力したのか、単に自分の名前だけを入力したのか、アポストロフィを忘れて気づかないのです。
一方、（さまざまな種類の）キャプチャには白黒の答えが必要です。有効か無効か。そうは言っても、キャプチャの読みやすさはユーザーに問題を引き起こすことがあります。ほとんどは読み取り可能ですが、一部は文字化けします。
パスワードをリセットするときに電子メールの検証を要求する方法は、私にとっては常にかなり安全であるように思われます。アクセスするにはsecondシステム（私のメールアカウント）のログイン詳細を知っている必要があるからです。新しいパスワードを要求するサイトへのリンクback。