この文書は2016年以降更新されていません
認証に関するチートシート
|
最終改訂日 (yy/mm/dd):2015/08/11
はじめに認証とは、個人、エンティティまたは Web サイトが本人 (本物) であることを検証するプロセスのことです。Web アプリケーションのコンテキストにおける認証は通常、ユーザー名または ID と、本人のみが知っているはずの個人情報の項目を 1 つ以上送信することで実行されます。 セッション管理とは、サーバーがエンティティとのやり取りの進行状態を把握するプロセスです。これはサーバーがトランザクション中の後続のリクエストにどのように反応するかを決めるために必要です。サーバー上では、セッションはセッション ID によって維持されます。セッション ID は、リクエストの送受信時にクライアントとサーバーの間で受け渡しされます。セッションはユーザーごとに固有なものとして管理し、外部からは予測困難なものにする必要があります。 認証の一般的なガイドラインユーザー IDユーザー名とユーザー ID では、大文字小文字を区別しないようにします。ユーザー「smith」とユーザー「Smith」は、同じユーザーを表すようにします。 ユーザー ID としての電子メールアドレス電子メールアドレスは、多くのサイトでユーザー ID として使用されています。これは、新しいユーザー名を覚えるという負担を増やすことなく、ID が必ずユーザーごとに一意になる優れたメカニズムです。ただし、多くの Web アプリケーションは、電子メールアドレスの形式について誤解しており、電子メールアドレスを正しく取り扱っていません。 次のような性質を持つ電子メールアドレスは、完全に有効であることに注意してください。
ローカル部とは、メールアドレスのいちばん右側に現れる @ 文字より左側の部分のことです。 ドメインとは、メールアドレスのいちばん右側に現れる @ 文字より右側部分のことで、ゼロ個以上のラベルがピリオドで結合された形になっています。 執筆時点では、SMTP および有効な電子メールアドレスの形式を定義している標準の最新版は、RFC 5321 です。 電子メールアドレスは、公開データと見なす必要がある点に注意してください。高いセキュリティが要求されるアプリケーションでは、ユーザー定義の公開データを使わずにアプリケーション側でユーザー名を割り当て、外部からはわからないようにすることでしょう。 検証多くの Web アプリケーションでは、計算コストが高く不正確な正規表現式を使って電子メールアドレスを検証しています。 最近の状勢変化により、正規表現がマッチしないケースが増加することでしょう。特に以下のような原因が考えられます。
RFC 5321 に従うと、電子メールアドレスの検証に関するベストプラクティスは次のようになります。
アドレスが配達可能であることを確かめるには、ユーザーに電子メールを送信して、ユーザーが受信を確認する操作を行ったことをチェックする以外に方法はありません。 これは、電子メールアドレスが有効であり配達可能であることを確認するだけでなく、ユーザーがメールボックスにアクセスしたことと、そのメールボックスの使用が認可されている可能性が高いことを示す、肯定応答を得ることにもなります。ただし、このメールボックスに他のユーザーがアクセスできないという意味にはなりません。たとえば、ユーザーが使い捨てメールアドレスを生成するサービスを使用している場合です。 アドレスの正規化電子メールアドレスのローカル部は、実際には大文字小文字が区別されるため、電子メールアドレスを正確に保存して比較することが重要になります。 電子メールアドレスを正規化する場合、小文字に変換するのはドメイン部のみとすべきです。 残念なことに、これが行われると、入力の正規化とユーザーの意図に正確に合わせることが困難になります。 同じアドレスの 1 文字のみを大文字化したものを受け入れることは妥当なことですが、その場合は次のようにすることが重要です。
適切なパスワード強度制御の実装認証にパスワードを使用する場合、パスワード強度が主な懸案事項になります。"強力" なパスワードポリシーがあると、手動でも自動化された方法でもパスワードの推測が困難になります。次に示す特性によって、強力なパスワードを定義します。 警告これ以降のアドバイスには、議論の余地があります。詳細については、OWASP プレゼンテーション "Your Password Complexity Requirements are Worthless - OWASP AppSecUSA 2014" を参照してください。 パスワードの長さパスワードを長くするほど、文字の組み合わせが多くなり、攻撃者による推測が困難になります。
一定の長さ以上のパスワードを使うよう強制すると、パスワードを覚えられないユーザーが出てくるかもしれません。そのような場合には、パスフレーズ (文または単語の組み合わせ) を設定するようにユーザーに促す必要があります。通常、パスフレーズはパスワードよりも長くなりますが、パスワードよりも覚えやすくなります。
パスワードの複雑さアプリケーションでは、パスワードが簡単に推測されないようにするために、パスワードの複雑さに関するルールを強制する必要があります。パスワードのメカニズムでは、パスワードの一部としてユーザーが入力可能なほぼすべての文字 (空白文字を含む) を使用できるようにする必要があります。当然ながらパスワードは、複雑さを増すために大文字小文字を区別する必要があります。パスワードの大文字小文字が区別されていないシステムを見かけることがありますが、多くの場合、パスワードの大文字小文字を区別しない旧式のメインフレームなど、従来のシステムに関わる問題が原因です。 パスワード変更のメカニズムでは、アプリケーションとユーザー数に適った、最小レベルの複雑さを要求する必要があります。次に例を示します。
パスワードのトポロジ
追加情報
より複雑なパスワードポリシーをアプリケーションで要求するときには、そのポリシーの内容は理解しやすいものである必要があります。
推奨事項:
UI の動作とは別に、ユーザーがパスワード変更のリクエストを送信したときには、次のようにするとよいでしょう。
セキュアなパスワードの回復メカニズムの実装一般に、アプリケーションは、ユーザーがパスワードを忘れたときにも、そのユーザーが自分のアカウントにアクセスできるようにするメカニズムを備えています。この機能の詳細については、「パスワードを忘れた場合に関するチートシート」を参照してください。 セキュアな方法によるパスワードの保存アプリケーションにとって、適切な暗号化技法を使用してパスワードを保管することは重要なことです。この機能の詳細については、「パスワードストレージに関するチートシート」を参照してください。 TLS などの強力なトランスポートのみを使用したパスワードの伝送ログインページとそれ以降のすべての認証済みページへのアクセスは、TLS などの強力なトランスポートを通じてのみとする必要があります。最初のログインページ (ログインランディングページと呼ばれます) は、TLS などの強力なトランスポートを通じて提示する必要があります。ログインランディングページに TLS などの強力なトランスポートを使用していない場合、攻撃者は、ログインフォームの動作を変更して、ユーザーの認証情報を任意の宛先に送信させる可能性があります。ログイン後の認証済みのページに TLS などの強力なトランスポートを使用していない場合、攻撃者は、暗号化されていないセッション ID を取得して、ユーザーの認証済みのセッションを侵害できるようになります。 再認証を必要とする機密性の高い機能CSRF とセッションハイジャックの被害を軽減するために、機密のアカウント情報 (ユーザーのパスワードやユーザーの電子メールアドレスなど) を更新する際や、機密のトランザクション (購入品を新しい住所に出荷するなど) を実行する際には、アカウントの資格情報を要求することが重要です。こうした対策がないと、攻撃者は、ユーザーの資格情報を知る必要なく、CSRF または XSS 攻撃によって機密のトランザクションを実行できるようになる可能性があります。さらに、攻撃者が、ユーザーのブラウザーへの一時的な物理アクセスを獲得する可能性や、セッション ID を盗んでユーザーのセッションを乗っ取る可能性もあります。 多要素認証の利用多要素認証 (MFA、Multi-Factor Authentication) では、ログオンまたはトランザクションの処理に複数の認証要素を使用します。
ハードウェアトークンを使用して実装される One Time Password (OTP) などの認証方式も、CSRF やクライアント側マルウェアなどの攻撃に対抗する際の要になり得ます。Web アプリケーションとの適切な統合が可能な、MFA に適したいくつかのハードウェアトークンが市場で入手できます。参照: [2]。 TLS クライアント認証TLS クライアント認証は、両方向 TLS 認証と呼ばれることもあり、ブラウザーとサーバーの両方で構成されます。TLS ハンドシェークプロセス時に、その両方がそれぞれの TLS 証明書を送信します。ユーザーがサーバーの信頼性を検証するために証明書を使用して、周知の認証局 (CA) に問い合わせを行うのと同様、サーバーはクライアントから証明書を受け取り、その証明書をサードパーティの CA または独自の CA に照らし合わせて検証することでユーザーを認証できます。これを行うには、サーバーが特定のユーザー専用にサブジェクトに値を割り当てた証明書をユーザーに提供する必要があります。この値により、ユーザーが特定できます。ユーザーはブラウザーに証明書をインストールして、その証明書を Web サイトに使用します。 以下の場合に、これが良策になります。
一般に、平均的なユーザーが広く公開利用できる Web サイトに、この方法を使用することは良策ではありません。たとえば、Facebook などの Web サイトにこれを実装することは、良策とはいえません。この技法ではユーザーはパスワードの入力をしなくてもすみます (そのため、通常のキーロガーによるパスワードの盗難を防止できます) が、やはりパスワードと TLS クライアント認証を組み合わせての使用を検討するのが賢明です。 詳細については、次を参照してください。Client-authenticated TLS handshake 認証とエラーメッセージ認証機能については、不適切に実装されたエラーメッセージが、ユーザー ID とパスワードを列挙する目的で使用されることがあります。アプリケーションは、一般的な方法で応答する必要があります (HTTP と HTML の両方)。 認証の応答アプリケーションは、ユーザー ID とパスワードのどちらに間違いがあっても、一般的なエラーメッセージで応答する必要があります。また、既存のアカウントの状態について示してもいけません。 不適切な応答例
適切な応答例
適切な応答では、間違っているパラメータがユーザー ID なのかパスワードなのかを示していないため、有効なユーザー ID を暗示することもありません。 エラーコードと URLアプリケーションは、認証の試行に対する応答に応じて異なる HTTP エラーコードを返すことがあります。肯定的な結果には 200 番の応答を返し、否定的な結果には 403 番の結果を返します。ユーザーには一般的なエラーページが示されていても、HTTP 応答は異なることがあり、それによってアカウントが有効であるかどうかに関する情報が漏れる可能性があります。 ブルートフォース攻撃の防止攻撃者がパスワードを推測できるときに、失敗した認証の試行回数でアカウントを無効化しないと、攻撃者はアカウントに侵入するまでブルートフォース攻撃を続けられるようになります。Web アプリケーションに自動的なブルートフォース攻撃やパスワード推測攻撃を仕掛けることは、難しいことではありません。パスワードロックアウトのメカニズムを採用して、失敗したログイン試行が所定回数まで行われたときには、アカウントをロックアウトする必要があります。パスワードロックアウトのメカニズムには、論理的な弱点があります。既知のアカウント名に対して多数の認証の試行を開始する攻撃者は、複数のユーザーアカウントをまとめて閉鎖するという成果を得てしまいます。パスワードロックアウトシステムの目的が、ブルートフォース攻撃を防止することならば、しばらくの間 (たとえば、20 分間) だけアカウントをロックアウトすることが合理的な戦略といえます。これによって攻撃者の動きを大幅に鈍らせて、正当なユーザーにはアカウントを自動的に再開できるようになります。 また、多要素認証は、ブルートフォース攻撃の非常に強力な抑止力になります。これは、資格情報が動く標的であるためです。多要素が実装されていてアクティブな状態のときには、アカウントのロックアウトは必要なくなるでしょう。 パスワードを必要としない認証プロトコルの使用ユーザーとパスワードの組み合わせによる認証と多要素認証の使用は、一般にセキュアであると考えられますが、これが最善策ではなく、安全でさえないと考えられるユースケースがあります。この一例として、サードパーティのアプリケーションが、モバイルデバイス、他の Web サイト、デスクトップまたはその他の場所のいずれかから Web アプリケーションへの接続を求める場合が挙げられます。これが行われると、サードパーティのアプリケーションがユーザーとパスワードの組み合わせを保存できるようになるため、安全だと考えられなくなります。このようになると、攻撃対象領域がサードパーティの手の内に広がり、自分の制御が及ばなくなります。こうしたユースケースに対して、ユーザーのデータを攻撃者に公開しない認証プロトコルが複数存在します。 OAuthOAuth (Open Authorization) とは、アプリケーションがサーバーをユーザーとして認証できるプロトコルのことです。このとき、パスワードや ID プロバイダーの役割を果たすサードパーティのサーバーは必要とされません。このプロトコルでは、サーバーが生成したトークンを使用し、最も多く発生する認可のフローの方法を提供して、モバイルアプリケーションなどのクライアントから、どのユーザーがサービスを使用しているかをサーバーに通知できるようにします。 OAuth 1.0a または OAuth 2.0 の使用と実装が推奨されます。最初のバージョン (OAuth1.0) にはセッション固定に対する脆弱性が見つかっています。 OAuth 2.0 は、セキュリティを HTTPS に依存しており、現在 Facebook、Google、Twitter、Microsoft などの企業からの API で使用され、実装されています。OAuth1.0a は、デジタル署名の暗号ライブラリを使用する必要があるため使い方がより難しくなっていますが、セキュリティに関しては HTTPS に依存しないため、リスクの高いトランザクションに適しています。 OpenIdOpenId は、HTTP ベースのプロトコルであり、ユーザーが本人であることを検証するために、ID プロバイダーを使用します。これは非常に簡単なプロトコルで、サービスプロバイダーによるシングルサインオン (SSO) 開始を実現します。これにより、ユーザーは信頼された OpenId ID プロバイダーに付与した 1 つの ID を再使用して、複数の Web サイトで同じユーザーになれます。このとき、OpenId ID プロバイダー以外の Web サイトにパスワードを提示する必要はありません。 そのシンプルさとパスワード保護の提供により、OpenId は広く採用されています。よく知られた OpenId の ID プロバイダーとして、Stack Exchange、Google、Facebook、Yahoo! などが挙げられます。 企業環境以外の場合は、ID プロバイダーが信用できるものであれば、OpenId はセキュアであり、多くの場合に優れた選択肢であると見なされています。 SAMLSAML (Security Assertion Markup Language) は通常、OpenId に匹敵するものと見なされています。最も推奨されるバージョンは 2.0 です。このバージョンは、機能の完全性が非常に高く、強力なセキュリティを提供します。OpenId と同じように、SAML は ID プロバイダーを使用しますが、XML ベースである点と、高い柔軟性を備えている点が異なります。SAML は、XML データを送信するブラウザーのリダイレクトに基づいています。SAML とは異なり、サービスプロバイダーによってのみ開始されるのではなく、ID プロバイダーから開始されることもあります。これにより、ユーザーは何もすることなく、認証された状態で異なるポータル間を移動できるようになり、プロセスが透過的になります。 OpenId が消費者市場の大部分に浸透しているのに対し、SAML は企業アプリケーションに多く採用されています。その最大の理由として、企業クラスと見なされる OpenId ID プロバイダーがほとんどないことがあります (したがって、ユーザー ID を検証する方法が企業 ID に要求される高度な基準に達していないのです)。SAML はイントラネット Web サイトの内側で使用されていることのほうが多く、イントラネットのサーバーを ID プロバイダーとし使用していることもあります。 ここ数年、SAP ERP や SharePoint (Active Directory フェデレーションサービス 2.0 を使用する SharePoint) のようなアプリケーションでは、Web サービスと Web アプリケーションに企業連合が必要になるときにはたいてい、SAML 2.0 認証がシングルサインオン実装に優先される方法です。 FIDOFIDO (Fast Identity Online) Alliance は、オンライン認証を円滑に進めるための 2 つのプロトコル、UAF (Universal Authentication Framework) プロトコルと U2F (Universal Second Factor) プロトコルを作成しました。UAF がパスワードが不要な認証に焦点を合わせているのに対し、U2F では既存のパスワードベースの認証に 2 つ目の要素を追加できます。どちらのプロトコルも公開鍵暗号系を使ったチャレンジ / レスポンスモデルに基づいています。 UAF は、デバイスに存在する既存のセキュリティテクノロジーを認証に利用します。たとえば、指紋センサー、カメラ (顔認証)、マイク (音声認証)、Trusted Execution Environment (TEE)、セキュアエレメント (SE) などです。UAF は、これらのデバイス機能を共通の認証フレームワークにプラグイン接続するように設計されています。UAF は、ネイティブアプリケーションと Web アプリケーションのどちらでも機能します。 U2F は、ハードウェアトークン (通常は USB) を使用してパスワードベースの認証を強化します。トークンは、暗号の認証キーを格納し、署名の際には使用します。ユーザーは、同じトークンを複数のアプリケーションの 2 番目の要素として使用できます。U2F は Web アプリケーションで機能します。U2F は、格納している認証キーのルックアップに、Web サイトの URL を使用することで、フィッシング防止を実現します。 セッション管理の一般的なガイドラインセッション管理は、認証に直接関連します。これまではこの『認証に関するチートシート - OWASP』にあった「セッション管理の一般的なガイドライン」は、『セッション管理に関するチートシート』に統合されています。 パスワードマネージャーパスワードマネージャーは、大量の異なる資格情報の管理を自動化するプログラム、ブラウザーのプラグイン、または Web サービスのことです。パスワードの記憶機能や入力機能、異なるサイトに対するランダムパスワードの生成機能などが組み込まれています。パスワードマネージャーを使用するユーザーを考慮して、Web アプリケーションでは以下のような点に注意するとよいでしょう。
追加のリソース次の場所に、このチートシートの PDF があります。https://magic.piktochart.com/output/7003174-authentication-cheat-sheet Authors and Primary EditorsEoin Keary eoinkeary[at]owasp.org Other CheatsheetsDeveloper Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets OpSec Cheat Sheets (Defender) Draft Cheat Sheets
|
