security - ログインページのベストプラクティス？

Question

さまざまなWebアプリケーションで使用されるShibbolethを使用したシングルサインオンログインページに取り組んでいます。もちろん、フィッシング詐欺の影響を制限しながら、このページを可能な限り安全で使いやすいものにしたいと考えています。

ログインページを設計するときに覚えておくべきベストプラクティスは何ですか？

この問題に関して出てきたいくつかの質問：

ログインページがすべてのディスプレイで常に同じように見えることが重要ですか？
逆に、ログインページがランダムなデザインであると有益でしょうか？
ログインページは他のすべてのページと同じように見える方が良いですか、それとも独自のデザインにする必要がありますか？
ログインページに独自のデザインがある場合、サイトのデザインの他の定数要素（グローバルナビゲーションなど）を組み込む必要がありますか？
ログインページは、ユーザーに追加のコンテンツ（最新ニュースなど）を提供するための適切な場所ですか？
人々の安全を守るために含めるべき追加のセキュリティ機能はありますか？

score 21 · Accepted Answer

使用上の注意:

個人的には、サイトがパスワードフィールドとログインボタンの間に「パスワードを忘れた」、「ユーザー名を忘れた」、または「ヘルプ」リンクを配置するのが嫌いです。キーボードユーザーとして、サブミットボタンに到達するためにそれらを TAB する必要はありません。

さらに良いことに、パスワードフィールドでの Enter キーの押下もキャプチャして、Enter キーで自動送信できるようにします。

score 7 · Accepted Answer

ログインページで同じデザインを維持することで、ユーザーがページにログインしようとしていることをユーザーに知らせることができます. そのため、コンテンツページと同じガイドラインを維持することをお勧めします。

score 6 · Accepted Answer

何を設計しても、フィッシャーはそれを模倣できます。フィッシングを完全に防止することは難しい問題です。基本的に、ユーザーがログインする前に、ユーザーを識別する何らかの手段が必要です。現在、一部の銀行はこれを行っています。名前を入力すると、自分で選択した画像が表示され、同じ画像であることを確認したら、パスワードを入力します。これは、サイトが必要とするよりも複雑なレベルになる可能性があります。

技術面では、Bank Of America は PassMark と呼ばれる Flash ローカル共有オブジェクトを使用してこれを実現しています。あなたのブラウザは、あなた自身を識別するこのデータを静かに銀行に送り返します。LSO を削除すると、BofA がユーザーを識別できないため、画像が表示されなくなります。これでも中間者攻撃に対して脆弱です。

score 5 · Accepted Answer

私がアクセスする多くのアプリケーションでまだ見られるもう1つの「当たり前」のことは、指定された資格情報が無効である場合、どれが無効であるかを示さないことです。「無効なパスワード」の代わりに「無効なユーザーとパスワードの組み合わせ」などと言うだけで、ソーシャルエンジニアリングからあなたのサイトにアクセスしているユーザーベースを知ることができなくなります。

score 4 · Accepted Answer

Smashing Magazine には、ログインフォームに関するかなり完全なまとめがあります。 Web フォームのデザインパターン: サインアップフォーム

score 3 · Accepted Answer

アプリケーションレベルのドーズ防止を含む

ログインの失敗については具体的ではありません。「不明なユーザー名」ではなく、一般的な「ログインに失敗しました」。

キャプチャまたはその他のチューリングテストを使用します。

score 3 · Accepted Answer

簡単に思えるかもしれませんが、アプリで必要な場合は HTTPS を使用してください。人々は同じパスワードを再利用する傾向があるため、それが保証されていなくても。最近はSSL証明書を安く手に入れることができます。彼らがあなたのサイトからパスワードを解除した場合、他の場所で試すことができます. 多くの銀行でさえ、安全な回線にログインページがありません。HTTPS ページに投稿しますが、依然として中間者攻撃に対する保護はありません。

オムニウォンバットに同意。フィッシングはうまく解決するのが難しい問題であり、完全に解決することは不可能に思えます。

score 2 · Accepted Answer

ユーザーであると同時に警備員のように考えてください。ログインするたびにキャプチャを実行させると、ユーザーはかなりうんざりすることになります。

サービス拒否を防止しようとしている場合は、特定の期間に十分な（失敗した？）ログイン試行が行われた後にのみキャプチャを表示させることができます。

NTLM、OpenID、またはShibbolethを使用して、ほとんどのユーザーのログインを可能な限り自動化することを検討してください。

登録のために別のページに移動させないでください。おそらく、ユーザー名とパスワードのフィールド、およびログイン/送信ボタンがあります。「新規ユーザーとして登録」ボタンも追加するだけで、新規ユーザーは既存のユーザー名/パスワードフィールドを使用できます。新規ユーザーの追加の詳細を収集する必要がある場合は、フォームをポップアップして（ポップアップウィンドウではなく、DHTMLを使用して）収集します。

score 1 · Accepted Answer

状況に応じた便利なヒント: パスワードフィールドに autocomplete="off" を追加することで、クライアント側のパスワードの保存を無効にできます。

それはすべてのブラウザーで機能するわけではありません (覚えていれば、IE 6 以降と Firefox 3 以降)。

score 1 · Accepted Answer

フィッシングを阻止しようとしてこれまでに見た中で最も優れているのは、銀行のログインインターフェイスです。ログインは 3 つの部分で行われます。最初にユーザーがアカウント番号 (デビットカード番号、クレジットカード番号など) を入力し、2 番目のステップでユーザーが指定した 3 つの質問のうちの 1 つがランダムにリストされます (例: どの高校に通っていましたか? 10 年生の場合)、最後の部分 (最初の 2 つが成功した場合) は、サインアップ時にユーザーが指定した画像とテキストを表示し、その下にパスワードフィールドを表示します。

score 0 · Accepted Answer

@Joe Lencioni、およびシボレスに興味のあるすべての人

サイトページは、各ページで全体的に同じルックアンドフィールを持つ必要があります。

Shibboleth と SSO について。組織がどの役割に関連付けられているかに注意することが重要です。あなたは ID プロバイダー - IdP (ユーザーを認証してから SP に応答を送信する) ですか、それともサービスプロバイダー - SP (IdP によって送信された応答と属性に基づいて認証を付与する) ですか。

あなたが SP である場合、ユーザーがログインできるように IdP にユーザーをリンクするために必要な柔軟性があります。多くの SP は、ユーザーを IdP のログインページにリダイレクトする独自の WAYF (Where Are You From) ページを作成します。

IdP の場合、ユーザーがログインし、SP が適切なアクセスを許可するために必要な属性を使用して SP にリダイレクトできるように、ユーザーになじみのあるログインページが必要です。

フィッシング詐欺に関する限り、Shibboleth メタデータを最新の状態に保つことが重要です。多くの連盟は、メタデータを 1 時間ごとにダウンロードすることを推奨していると思います。

Shibboleth に関する多くの質問は、 https ://spaces.internet2.edu/display/SHIB2/Home で回答できます。

これがお役に立てば幸いです。

score 0 · Accepted Answer

通常、ユーザーはそのページで 10 秒間すべてを費やすことになることを認識してください。ユーザー ID とパスワードをどこに置くかが明らかである限り、見た目は問題ではありません。それ以外は、パスワードを忘れた場合にパスワードをメールで教えてくれるサイトの 1 つにしないでください。少なくとも、これまでに取得できない場所に、適切なソルト付きハッシュに隠されていると信じさせてください。

security - ログインページのベストプラクティス？

12 に答える 12

Related

Reference