Thu, 29 Aug 2019 02:59:56 +0000

全体概要

デジタル認証は、与えられた要求者と以前認証を行った加入者とが同一である、という確からしさを証明するためのプロセスである。この確からしさの堅牢性については、認証器信頼レベル(Authenticator Assurance Level、以下AAL)として知られている分類を用いて表される。AALはsp 800-63Aにおいてアイデンティティ信頼レベル(Identity Assurance Level、以下IAL)と区別される。これはより高いAALをサポートするようなアプリケーションでは、仮名を用いた高度な認証を要求するようなことがあるかもしれないためである。

本ガイドラインは、要求者としての個人がどのようにクレデンシャル・サービス・プロバイダ(Crendential Service Provider)に対してセキュアな認証を行い、遠隔で行われるデジタルな対話のためのコンテキストを確立するか、という点に取り組むものである。

3つのAALは、システムに対する不正・詐欺的なユーザアクセスによって生じるリスクや損害に基づいて、各機関が選びうる選択肢を示している。各AALは次の通り：

AAL 1: ALL 1は、単一要素の認証を必要とする。これは、保護された取引/データへアクセスしようとする要求者が以前の取引に関わった人と同一であるという、ある程度の信頼性を持つ。

AAL 2: AAL 2は、2つの異なる要素の認証を必要とする。これは、保護された取引/データへアクセスしようとする要求者が以前の取引に関わった人と同一であるという、より高い信頼性を提供する。

AAL 3: AAL 3は、遠隔で行われるデジタル認証のうち最も実用的な信頼性を提供する。これは、暗号理論に基づくプロトコルを介して、物理的な多要素認証器内部にある鍵の所有者であることを証明することを必要とする。

目次

1. 目的

2. はじめに

3. 定義及び略語

4. 認証器信頼レベル(Authenticator Assurance Levels)

5. 認証器(Authenticator)及び検証器(Verifier)の要件

6. 認証器ライフサイクルの要件

7. セッション管理

8. 脅威とセキュリティに関する考慮事項

9. プライバシに関する考慮事項

10. ユーザビリティに関する考慮事項

11. 参照

付録A. 記憶シークレットの強度

<!–

1. Purpose

–>

1. 目的

本推奨、及び付随文書 SP 800-63-3, SP 800-63A 及び SP 800-63C は、クレデンシャル・サービス・プロバイダがデジタル認証の実装を行う際の技術的なガイドラインを提供する。

2. イントロダクション

デジタル認証は、情報システムにおいて電子的に表現されたユーザのアイデンティティの確かさを証明するためのプロセスである。E-authentiationは、本プロセスがネットワークを介した個々人のデジタル認証に関与する際、技術的なチャレンジを提起する。

継続的に行われる加入者の認証が本プロセスの中心である。加入者認証は、要求者が、加入者と関連付けられた一つ以上の 認証器 (SP 800-63の以前の版では トークン と呼ばれていた)を制御していることを検証することによって実施される。認証が成功すると、識別子（仮名または仮名でない）及びオプションで他のアイデンティティ情報のアサーションが、リライング・パーティ(RP: Relying Party)に提示される。

本書は、様々な 認証器保証レベル (AAL)の認証器の選択を含む、認証プロセスの種別の指針を提供する。また、本書は認証器の紛失・盗難に伴う廃棄を含む、認証器のライフサイクルに関する指針を提供する。

これらの技術的なガイドラインは人間のユーザがネットワークを介してITシステムに対して行うデジタル認証に適用される。これらは主として人間が物理的に存在すること ー例えばそのユーザが建物に入館できることー の認証については言及しない。しかしながら、リモートで利用されるクレデンシャルのなかにはローカルの認証でも利用するものがあるかもしれない。また、これらの技術的なガイドラインは、米国連邦のITシステムやサービスプロバイダが加入者を認証するための認証プロトコルに準拠する上での要件を規定している。しかしながら、これらのガイドラインは、(ルータ同士のような)Machine-to-machineの認証については言及していない。また、マシンやサーバに対して発行された認証クレデンシャルが、E-authenticationプロトコル中でユーザを介して利用される際の特別な要件については規定しない。

認証トランザクションの強度はAALとして知られている分類によって特徴付けられる。より強力な認証(より高度なAAL)では、攻撃者側が認証を成功させるために高度なケーパビリティ及びリソースが必要となる。個々の認証器保証レベルに求められる技術要件の高度なサマリを以下に記載する; 特別な要求規則については、本書の Section 4 及び 5 を参照。

認証器保証レベル1 - AAL 1は加入者に対して登録された認証器を申請者が制御しているという、いくらかの確実性を持つ。AAL 1では幅広く利用可能な認証技術を利用した、単一要素の認証の利用を用いる。認証が成功するには、その要求者が、セキュアな認証プロトコルを介して、自身がその認証器を所有・制御していることを証明する必要がある。

認証器保証レベル2 - AAL 2は、加入者に対して登録されている認証器を申請者が制御しているという高い確実性を持つ。異なる2つの認証要素が必要である。AAL 2及びそれ以上では、承認済み(approved)暗号技術が必要とされる。

認証器保証レベル 3 - AAL 3は、加入者に対して登録されている認証器を申請者が制御しているというかなり高い確実性を持つ。AAL 3における認証は、暗号プロトコルを介した鍵の所有証明(proof of posession)に基づいたものである。AAL 3は、なりすましをも防止する「ハードウェア」暗号化認証器が必要という点を覗いて、AAL 2と同様である。

3. 定義及び略語

認証分野では様々な用語が用いられる。多くの用語はSP 800-63の初版のものと一貫性があるものの、この版で変更になっているものがいくつかある。そのため、複数の定義の一貫性をとるため、本章で定義される用語がどのような内容であると宣言されているか注意すること。

本章の定義は本章で参照するものである。SP 800-63の他の構成文章における追加の定義及び用語の詳細は、それぞれの文書の内容を参照すること。

能動的攻撃 (Active Attack)

攻撃者が認証の要求者、クレデンシャルサービスプロバイダ、検証器、リライングパーティに対してデータを送信するような認証プロトコルにおける攻撃のこと。能動的攻撃の例として、中間者攻撃、なりすまし、セッションハイジャックが挙げられる。

承認済み (Approved)

連邦情報処理標準(FIPS)により承認されている、またはNISTにより推奨されていること。アルゴリズムや技術が 1) FIPSまたはNIST推奨で指定されたものであること。または 2) FIPSまたはNIST推奨に適合していること

アサーション (Assertion)

検証者からリライングパーティー(RP)に対する文書であり、加入者に関するアイデンティティ情報を含む。アサーションは妥当性が検証されている属性を含んでもよい。

アサーションリファレンス (Assertion Reference)

アサーションと関連づけられて作成されたデータオブジェクト。検証者を識別するとともに、検証者が取り扱う完全なアサーションへのポインタを含んでいる。

確実性 (Assurance)

[OMB M-04-04]及び本書の中で、確実性の定義は、1) クレデンシャルが発行されている個人のアイデンティティを証明するため審査プロセスの信頼度、及び 2) クレデンシャルを利用している個人が、そのクレデンシャルが発行されている個人に一致することの信頼度、と定義される。

非対称鍵 (Asymmetric Keys)

2つの関連する鍵で、公開鍵と秘密鍵で構成されており、暗号化と複合、署名生成と署名検証といった相補的な操作を行うことができる公開鍵と秘密鍵のこと。

攻撃

権限のない個人による、セキュリティ制限を突破する試み。例えば、検証者やリライングパーティを偽って、権限のない当該個人が加入者であると信じ込ませること。

攻撃者 (Attacker)

悪意をもって情報システムを侵害しようとする者。

属性 (Attribute)

人や物に固有に帰する性質や特徴のこと。

認証済み保護チャネル (Authenticated Protected Channel)

接続の開始者(クライアント)が受信者(server)を予め認証しているような、承認済みの暗号化を利用する通信チャネル。認証済み保護チャネルは、機密性と中間者攻撃保護を提供し、ユーザ認証プロセスにおいて頻繁に利用される。TLS [BCP 195]は、認証済み保護チャネルの例の1つで、受信者が提示した証明書を開始者が検証することで実現される。

認証 (Authentication)

ユーザや情報システムのアイデンティティが確かなものであることをを証明するプロセス。ユーザ(加入者)の認証は、暗黙的に加入者の存在と認証する意思の確認を含んでいる。

認証要素(Authentication Factor)

認証要素の3つのタイプは、本人が知っていること(something you know)、本人が所持しているもの(something you have)、本人に備わっているもの(something you are)である。各認証器は一つ以上の認証要素を持っている。

認証プロトコル (Authentication Protocol)

要求者と検証者との間でやり取りされるメッセージのシーケンスを定義したもので、要求者は、彼・彼女のアイデンティティを証明するための一つ以上の妥当な認証器を所有し、管理することを明らかにする。セキュアな認証プロトコルは、要求者に対し、彼・彼女が意図した検証者と通信をしているということを証明する。

認証プロトコル実行 (Authentication Protocol Run)

要求者と検証者との間でメッセージを交換し、2者間で認証(または認証失敗)結果を得ること。

認証シークレット (Authentication Secret)

攻撃者が加入者を詐称するために利用できる可能性がある、任意のシークレット値に対する一般的な表現。

これらは更に 攻撃者が限られた期間しか利用することができない短期間の認証シークレットと、明示的にリセットされるまで攻撃者が加入者を詐称するために利用することができる長期間の認証シークレットに分類できる。認証器のシークレットは典型的な長期間の認証シークレットの例である。一方、認証器の出力は、その値が認証器のシークレットと異なるならば、通常、短期間の認証シークレットである。

認証器 (Authenticator)

要求者が所有し、管理することができ、要求者のアイデンティティを認証するために利用することができるもの(典型的には暗号化モジュールやパスワード)。SP 800-63の以前の版ではトークンとされていたものである。

認証器保証レベル (AAL: Authenticator Assurance Level)

要求者が指定された加入者の認証器を管理していることを証明する、認証プロセスの堅牢性を表す尺度。

認証器出力 (Authenticator Output)

認証器によって生成される出力の値。必要な時に妥当な認証器出力を生成する能力は、要求者が認証器を所有し管理していることを証明する。検証者へ送信されるプロトコルメッセージは、認証器出力に依存するが、明示的に出力の値を含んでいるとは限らない。

認証器シークレット (Authenticator Secret)

認証器が保持するシークレット値。

無記名アサーション (Bearer Assertion)

加入者が、自身がそのアサーションの正当な所有者であることを証明するメカニズムを提供しないアサーションのこと。 RPは、加入者がアサーションかRPやアサーションリファレンスを提示してきた場合、そのアサーションが加入者に対して発行されたものであると過程することになる。

バイオメトリクス (Biometrics)

個人の振る舞いや生物学的特徴にもとづいて自動的に認識すること。

本書では、バイオメトリクスは他要素認証器のロック解除や、登録の否認防止で利用される。

チャレンジ-レスポンス プロトコル (Challenge-Response Protocol)

検証者が要求者に対してチャレンジ(通常はランダム値やノンス)を送信し、要求者はシークレットと連結(チャレンジと共有シークレットを一緒にハッシュしたり、チャレンジに対して秘密鍵による操作を実施)して応答を生成し、検証者に返却するような認証プロトコルのこと。検証者は、要求者によって生成された応答を自身のみで検証（チャレンジと共有シークレットのハッシュを再計算してレスポンスと比較したり、レスポンスに対してい公開鍵による操作を実施）し、要求者がシークレットを所有し管理できることを証明することができる。

要求者 (Claimant)

一つ以上の認証プロトコルを用いて自身のアイデンティティを検証する当事者。

キャプチャ (CAPTCHA: Completely Automated Public Turing test to tell Computers and Humans Apart)

Webフォームに利用者が人間と自動エージェントを区別するために追加する対話的な機能のこと。典型的には、その機能は、歪んだ画像や、音声に対応するテキストの入力を求める方式である。

クレデンシャル (Credential)

加入者によって所有、管理される認証器に対して、アイデンティティ（及びオプションで追加属性）を正式に関連付けるオブジェクトまたはデータ構造。

一般的な用途では、大抵はクレデンシャルは加入者によって維持管理されていると仮定するが、本書では、加入者の認証器と加入者のアイデンティティとの関連付けを確立するCSPによって維持管理される電子的記録について言及する用語として用いる。

クレデンシャルサービスプロバイダ (CSP: Credential Service Provider)

加入者の認証器を発行・登録し、加入者に対して電子的なクレデンシャルを発行する、信頼されているエンティティ。CSPは自身が運用する検証者も包含しても良い。CSPは独立したサードパーティでも良く、自分自身で利用する目的でクレデンシャルを発行しても良い。

クロスサイトリクエストフォージェリ (CSRF: Cross Site Request Forgery)

RPに対して認証済みの加入者がセキュアなセッションを経由して接続している場合に発生する攻撃で、ブラウザで攻撃者のウェブサイトにアクセスすることで、加入者が意図せず望まないアクションをRPで実行してしまうもの。

例えば、もし銀行のサイトがCSRFに対して脆弱である場合、単にユーザWebメールの本文中の悪意のあるリンクを参照するだけで、別のブラウザで銀行への接続が開かれ、加入者が意図せず大きな金額の資金移動を許可てしまう可能性がある。

クロスサイトスクリプティング (XSS: Cross Site Scripting)

攻撃者が、不正なコードを他の無害なページに対して注入することを許してしまう脆弱性。 これらのスクリプトはターゲットのウェブサイトで生成されるスクリプトの権限で動作し、ウェブサイトとクライアント間でのデータ転送の機密性や一貫性を侵害する。 ウェブサイトは、ユーザが入力するデータをリクエストやフォームから受け取り、サニタイズを施して実行不可能にすることなく表示してしまう場合に脆弱である。

暗号鍵 (Cryptographic Key)

複合、暗号、署名生成、署名検証といった暗号操作を制御するために利用される値。本書の目的において、鍵要求仕様はNIST SP 800-57 Part 1の表2で述べられている最小の要求仕様に一致させるものとする。

非対称鍵、対象鍵も合わせて参照のこと。

暗号認証器 (Cryptographic Authenticator)

シークレットが暗号鍵であるような認証器のこと。ハードウェア暗号認証器は一つ以上の暗号鍵を含む暗号モジュールである。

暗号モジュール (Cryptographic Module)

承認済み(approved)セキュリティ機能（暗号アルゴリズムと鍵生成を含む）ハードウェア、ソフトウェア、及びファームウェアの集合。

データ一貫性 (Data Integrity)

認可されていないエンティティによってデータが変更されることがない、という性質。

派生クレデンシャル (Derived Credential)

過去に発行されたクレデンシャルと関連付けられている一つ以上の認証器の所有及び制御の証明に基づいて発行されるクレデンシャル。したがって、アイデンティティの証明プロセスを重複して行うわけではない。

デジタル署名 (Digital Signature)

プライベートキーを利用してデータに署名し、パブリックキーを利用して署名を検証する、非対称鍵の操作のこと。デジタル署名は真正性の保護、一貫性の保護、非否認性を実現する。一方、秘匿性を実現するものではない。

盗聴攻撃 (Eavesdropping Attack)

認証プロトコルを受動的に聞き、情報を傍受する攻撃。傍受した情報は、後続の要求者に成りすました能動的攻撃で利用される。

電子的認証 (E-Authentication: Electronic Authentication)

デジタル認証を参照。

エントロピー (Entropy)

攻撃者がシークレットの値を決定することに対峙する際の不確実性の量の尺度。エントロピーは、通常ビットで表現される。nビットのエントロピーを持つ値は、nビット一様乱数と同じ度合いの不確定性を持つ。

等価エラー率 (EER: Equal Error Rate)

センサーにおいて、マッチすべきものがマッチしない割合(False Match Rate: FMR)、及びマッチすべきではないものがマッチしてしまう割合(False Non-Match Rate: FNMR) が等しくなる地点の値である等価エラー率を、センサーの性能指数とする。等価エラー率が低ければ低いほど、センサーの検出結果がより確からしいものとなる。

Federal Information Security Management Act (FISMA)

Title III of the E-Government Actは各連邦政府機関に対し、運営や資源を支援する情報及び情報システムへの情報セキュリティを備えるための機関横断的なプログラムを、開発、記録、実行していくことを要求している。対象となる情報及び情報システムには、別の機関、業者や他の調達元によって導入・管理されるものも含まれる。

連邦情報処理規格 (FIPS: Federal Information Processing Standard)

Information Technology Management Reform Act (Public Law 104-106)に基づいて、商務長官は、連邦政府機関のコンピュータ・システムに適用するために国立標準技術研究所(NIST)が開発した標準及びガイドラインを承認する。これらの標準及びガイドラインは、NISTによってFIPSとして発行されたものであり、政府機関で横断的に使われるものである。 NISTは、セキュリティや相互運用性といった強制力のある連邦政府の要求事項がある場合や、許容可能な業界標準やソリューションが存在しない場合に、FIPSを開発する。詳細については背景を参照すること。

FIPS文書は、FIPSホームページ http://www.nist.gov/itl/fips.cfm からオンラインで利用できる。

ハッシュ関数 (Hash Function)

任意長の短いの文字列を、固定長の文字列に変換する関数。承認されているハッシュ関数は以下の性質を満たす。

1. (一方向性) 指定された出力結果から、対応する入力を特定することが計算上困難で、
2. (衝突困難性) 同じ出力となる任意の2つの異なる入力を特定することが計算上困難である

Holder-of-Keyアサーション (Holder-of-Key Assertion)

加入者が保持している対称鍵または（秘密鍵に対応する）公開鍵への参照を含んだアサーション。 RPは、加入者が実際にその鍵を所有・管理することが可能である、ということを検証することで、加入者を認証しても良い。

アイデンティティ (Identity)

与えられた文脈において、人物を一意に指し示す属性の集合。

アイデンティティ保証レベル(IAL: Identity Assurance Level)

申請者が申告したアイデンイティが、彼ら自身の実際のアイデンティティに一致することの信頼の度合いを表現する尺度。

Kerberos

MITで開発された認証プロトコルで幅広く利用されている。古典的なKerberosでは、ユーザは秘密のパスワードをKey Distribution Center(KDC)に共有する。ユーザAliceは、他のユーザBobと通信するため、KDCに対して認証を行い、KDCからチケットの提供を受ける。 そのチケットは、Bobとの間で認証を行うために利用する。

Kerberos認証はパスワードに基づいており、プロトコルは最初にユーザとKDCの間で行われるやり取りを盗聴することにより可能となる、オフラインの辞書攻撃に対して脆弱であることが知られている。パスワードをより長く・複雑にすることで、この脆弱性に対する一定の緩和策となる一方、十分に長いパスワードはユーザにとって扱いにくいものとなってしまう。

中間者(Man-in-the-Middle)攻撃(MitM)

認証プロトコルの実行にあたり、攻撃者が、認証の要求主体と検証主体との間に立ち、送受信されるデータを横取り・改ざんする攻撃。

メッセージ認証コード (MAC: Message Authentication Code)

暗号理論に基づくデータのチェックサムであり、対称鍵を用いて、データの予期していない変更及び意図的な変更との両方を検知するために用いられる。MACは真正性(authenticity)と一貫性(integrity)の保護を行うが、非否認性(non-repudiation)は保護は行わない。

モバイルコード (Mobile Code)

通常は送信元から実行先のもう一方のコンピュータに対して送信される実行可能コード。しばしばネットワーク（例、Webページに埋め込まれたJavaScript）経由で送信されたり、同様に物理メディアを介して送信されることがある。

多要素 (Multi-Factor)

認証を成功させるために、2つ以上の認証要素を要求するような認証システムや認証器の性質。多要素認証は、１つ以上の要素を提供する単一認証器を利用するか、異なる要素に基づく認証器の組み合わせによって実現される。

認証要素の3つのタイプは、本人が知っていること(something you know)、本人が所持しているもの(something you have)、本人に備わっているもの(something you are)である。

ネットワーク (Network)

オープンコミュニケーションの媒介、典型的にはインターネットであり、要求者と対応する関係者間でメッセージを伝送するために利用されるもの。 特別に宣言をしていない限り、ネットワークのセキュリティについては何ら仮定は行わないものとする。 すなわち、オープンであり、関係者（例：要求者、検証主体、CSP、RP）間の任意の地点で、能動的攻撃(例：なりすまし、中間者、セッションハイジャック）と受動的攻撃(例：盗聴）に晒されている、と仮定する。

ノンス (Nonce)

セキュリティプロトコル中で利用され、同じキーによる繰り返しを許さない値。例えば、ノンスはチャレンジ・レスポンス認証プロトコルのチャレンジとして利用され、認証キーが変更されるまでの間、繰り返されないものとする(SHALL NOT)。 さもなければ、再生攻撃(replay attack)の可能性がある。 ノンスをチャレンジとして利用することと、チャレンジをランダムにすることとは異なる要件である。というのも、ノンスは必ずしも予測不可能である必要性がないからである。

オフライン攻撃 (Offline Attack)

攻撃者が何らかの情報を得る（典型的には認証プロトコルの実行を盗聴したり、システムに侵入してセキュリティファイルを盗む）ことで、選択したシステムを分析する攻撃。

オンライン攻撃 (Online Attack)

認証プロトコルにおいて、正当な認証主体に対する要求者の役割を詐称する、または能動的に認証チャネルを改ざんする攻撃。

オンライン推測攻撃 (Online Guessing Attack)

攻撃者が認証器の出力が取りうる値を推測して、ログオンを繰り返し行うような攻撃。

受動的攻撃 (Passive Attack)

認証プロトコルに対する攻撃。要求者と検証主体との間をネットワークを介してやり取りされるデータを傍受するが、データは改ざんしない(例. 盗聴)。

パスワード (Password)

要求者が記憶し、自身のアイデンティティを認証するために利用するシークレット。パスワードは一般的に、文字列である。

Personal Identification Number (PIN)

数字のみで構成されているパスワード。

ファーミング (Pharming)

DNS(Domain Name Service) のようなインフラストラクチャサービスを汚染する手法により、加入者を偽造した検証主体/RPへ誘導し、機微情報を入力させる、有害なソフトウェアをダウンロードさせる、詐欺活動に加担させる可能性のある攻撃。

フィッシング (Phishing)

加入者を(主にemailを通じて)偽の検証主体/RPに誘導し、真の検証主体/RPに対して加入者に成りすましを行うために利用する情報を騙し取る攻撃。

認証器の所有および管理 (Possession and control of an authenticator)

認証プロトコルにおいて、認証器をアクティベートし、利用できること。

実施規定 (Practice Statement)

認証プロセスの当事者(例. RA、CSP、検証主体)が従う実践的な内容を正式に記載した文書。通常、当事者のポリシーと実行内容が記述されており、法的拘束力を持つ可能性がある。

プライベートクレデンシャル (Private Credentials)

認証器を損なうために使うことができるため、CSPによって開示されることがないクレデンシャル。

秘密鍵 (Private Key)

非対称鍵ペアの秘密である側。デジタル署名やデータ暗号化に用いる。

保護されたセッション (Protected Session)

セッション鍵と呼ばれる共通シークレット一式を用いて、二者間のメッセージが暗号化され、一貫性が保護されるようなセッション。

セッションが継続する間において、セッション鍵に加えて当事者が認証器の所持を証明する、または他方が認証器に関連付けられたアイデンティティを検証することができるならば、当事者が 認証済み(authenticated) であるという。もし相互の当事者が認証済みである場合、保護されたセッションは 相互に認証済み(mutually authenticated) と呼ばれる。

パブリッククレデンシャル (Public Credentials)

認証器を損なうことのない方法で紐付けされているクレデンシャル。

公開鍵 (Public Key)

非対称鍵ペアの公開側。署名検証やデータ復号に用いる。

公開鍵証明書 (Public Key Certificate)

加入者の名前と公開鍵を紐付けている認証局(CA)の秘密鍵でデジタル署名され発行されるデジタル文書。証明書は、証明書中で識別される加入者が、唯一、その秘密鍵のコントロールとアクセスがであることを示す。 [RFC 5280] も参照のこと。

Public Key Infrastructure (PKI)

発行、維持、証明書、公開-秘密の鍵ペアの管理のために用いるポリシー、プロセス、サーバプラットフォーム、ソフトウェア、およびワークステーションのこと。

再認証(Reauthentication)

長時間に渡り用いられるセッションの期間で加入者が引き続き存在し、認証する意思があることを確認するプロセス。

登録 (Registration)

申請者がCSPの加入者となり、CSPが申請者のアイデンティティの正当性を確認するプロセス。

Relying Party (RP)

加入者の認証器とクレデンシャル、または検証主体が発行する要求者のアイデンティティのアサーションを信頼し、一般的には、取引を進めたり、情報やシステムへのアクセス権限を与えたりするエンティティ。

リモート (Remote)

(リモート認証やリモート取引で)ネットワークで繋がったデバイス間で交換される情報。その情報は、単一の組織のセキュリティ統制によるエンドツーエンドの信頼できる保護ができない。

注記: インターネット上でやり取りされる全ての情報は、リモートである、と考える。

リプレイ攻撃 (Replay Attack)

攻撃者が、正当な申請者と検証主体との間のメッセージをキャプチャし、申請者から検証主体、またはその逆であるかのように振る舞うために再送できるような攻撃。

リスクアセスメント (Risk Assessment)

システム・セキュリティに対するリスクを識別し、発生確率、与える影響、影響を緩和しうる追加の防御策を決定するプロセス。リスクマネジメント及びリスク分析と同義のものの一部。

ソルト (Salt)

暗号プロセスにおいて用いられる秘密でない(non-secret)値で、通常、ある特定の計算結果が攻撃者によって再利用されないことを保証するために用いられる。

二次認証器 (Secondary Authenticator)

アサーションプロトコルの一部分において、正しく認証された加入者を検証することで発行された一時的なシークレット。このシークレットは発行後、加入者がRPに対して認証するために利用する。

二次認証器の例としては、無記名アサーション、アサーション参照、及びKerberosセッションキーがある。

Secure Sockets Layer (SSL)

Transport Layer Security (TLS) を参照のこと。

Security Assertion Mark-up Language (SAML)

OASIS(Organization for the Advancement of Structured Information Standards)によって開発されたXMLベースのセキュリティ仕様で、信頼されたエンティティ間がインターネット上で、認証（及び認可）情報を交換するために利用される。[SAML]を参照のこと。

SAML認証アサーション (SAML Authentication Assertion)

検証主体と加入者の間で行われた成功した認証行為について、検証主体からRPに対して情報を伝達するSAMLアサーションの一つ。

セッション (Session)

加入者とエンドポイント、またはRPやCSPとの間の継続的なインタラクション。セッションは認証イベントで開始し、セッション終了イベントで終了する。セッションは、加入者のソフトウェア(ブラウザ、アプリケーションやOS）がRPやCSPに対して、加入者の認証クレデンシャルの代わりに提示するセッションシークレットを用いて結び付けられる。

セッションハイジャック攻撃 (Session Hijack Attack)

攻撃者が自身を申請者と検証主体の間に入り込み、その後、当事者間で認証を成功させるような攻撃。攻撃者は検証主体に対して加入者であるかのように振る舞うことができ、逆にセッションデータののやり取りを制御することもできる。申請者とRP間のセッションも同様に侵害される可能性がある。

シェーアド・シークレット (Shared Secret)

申請者と検証主体にとっては既知である認証で使用する秘密。

サイドチャネル攻撃 (Side Channel Attack)

物理的な暗号システムからの情報漏洩によって可能となる攻撃。タイミング、消費電力、電磁波放出、及び音声放出はサイドチャネル攻撃で活用されうる特徴の例である。

ソーシャルエンジニアリング (Social Engineering)

ある個人と親交を深めて信用・信頼を得ることによって、個人を騙して個人の機微情報を明らかにする行為。

Special Publication (SP)

NISTによって発行される出版物。特に、Special Publication 800シリーズは、Information Technology Laboratoryの研究、ガイドライン、及びコンピュータセキュリティにおける教育・援助を行う努力、さらに産業、政府、及び学術機関との協調的な活動についての報告である。

加入者 (Subscriber)

CSPから認証器に結びつけられたクレデンシャルを受け取る当事者。

対象鍵 (Symmetric Key)

暗号化と複合、またはメッセージ認証コードの作成と検証に例示される暗号操作及びその逆操作の両方を実施するために利用する鍵。

トークン (Token)

認証器 (Authenticator) を参照のこと。

トークン認証器 (Token Authenticator)

認証器出力 (Authenticator Output) を参照のこと。

トークンシークレット (Token Secret)

認証器シークレット (Authenticator Secret) を参照のこと。

Transport Layer Security (TLS)

ブラウザやウェブサーバに広く実装されている認証・セキュリティプロトコル。TLSは [RFC 5246] で定義されている。TLSはより古い Secure Socket Layer (SSL)プロトコルと、実質的にSSLバージョン3.1であるTLS1.0と同様である。NIST [SP 800-52] ガイドラインでは、Transport Layer Security (TLS)実装の選択と利用について記載しており、TLSを政府のアプリケーションでどのように利用すべきであるかを指定している。

トラストアンカー (Trust Anchor)

公開鍵・共通鍵のうち、別の（例えば公開鍵証明書で）信頼されている存在によって保証されているよりむしろ、直接的に、ハードウェアやソフトウェアに組み込まれた、セキュアに経路外の方法でプロビジョニングされている、といった理由で信頼されているもの。

ユーザビリティ

ISO/IEC 9241-11を通じ、プロダクトが特定のユーザによって、特定の利用文脈における実効性・効率性・充足度を伴いながら、特定の目的を達成するために利用しうる範囲。

検証主体

認証プロトコルを利用して、1つまたは2つの認証器を申請者が所有、管理できることを検証し、申請者のアイデンティティを検証する存在。

検証主体なりすまし

認証プロトコルにおいて、攻撃者が検証主体になりすまし、一般的には真の検証主体に対して加入者を詐称することを目的として情報を集めるようなシナリオ。 以前のSP 800-63の版では、検証主体なりすまし攻撃へ耐性のある認証プロトコルについて”strongly man-in-the-middle resistant”として記述されていた。

弱結合クレデンシャル

クレデンシャルを無効化することなく改ざんできてしまう方法で、加入者と結びつけられたクレデンシャル。

ゼロ化

データを破壊し、復元できないようにするために、ゼロ値のビットだけで構成されるデータによってメモリを上書きすること。これはしばしば、データそのものを破壊するのではなく、ファイルシステム上のデータへの参照を破壊するだけの削除手法と対比される。

ゼロ知識パスワードプロトコル

申請者が検証主体に対して認証を行う際、検証主体に対してパスワードを提示する必要がないようなパスワードベースの認証プロトコル。 プロトコルの例としては、EKE、SPEKE及びSRPがある。

4. 認証器保証レベル

指定された認証器保証レベル(AAL)要件を満たすために、申請者は少なくとも自身が加入者であると認識される強度のレベルで認証するものとする(SHALL)。認証プロセスの結果は識別子である。それは仮名でもよく(MAY)、加入者がRPに対して認証するたびに使われるものとする(SHALL)。任意で、加入者を一位な人物であると識別するために、他の属性もまた提供されるかもしれない。

各AALにおける認証器及び検証主体に対する要求規則の詳細については、5章で記載する。

FIPS 140 要求事項は、[FIPS 140-2]またはより新しい版によって充足される。

Table 4-1は、M-04-04 保証レベルを遵守するAALを表したもので、対応する認証器保証レベルにマッピングされている。

M-04-04保証レベル(LOA)	認証器保証レベル(AAL)
1	1
2	2 または 3
3	2 または 3
4	3

4.1. 認証器保証レベル 1(Authenticator Assurance Level 1)

AAL 1は、申請者が加入者に対して登録されている認証器を制御していることにある程度の保証を与える。AAL 1は幅広く利用可能な認証技術を使った単一要素認証器を利用する。認証が成功するには、申請者が、自身が認証器を所有及び制御することを、セキュアな認証プロトコルを通して証明する必要がある。

4.1.1. 許可された認証器タイプ

認証器保証レベル 1では、5章で定義される以下の任意の認証器タイプの利用が許可されている。

• 記憶シークレット
• ルックアップシークレット
• 経路外 (一部非推奨。 より詳細については Section 5.1.3 参照のこと。)
• 単一要素 OTP デバイス
• 多要素 OTP デバイス
• 単一要素暗号ソフトウェア
• 単一要素暗号デバイス
• 多要素暗号ソフトウェア
• 多要素暗号デバイス

4.1.2. 認証器及び検証主体 要求事項

AAL 1で用いられる暗号認証器は、承認済みの暗号を利用するものとする(SHALL)。汎用オペレーティング・システム環境で動作するソフトウェアベースの認証器は、実施上(例、マルウェアやJailbreakによって)それ自身が動作しているプラットフォームが改竄されていることを検出するよう試みてもよく(MAY)、そのような改竄が検出されると操作を拒否すべき(SHOULD)である。

申請者とチャネル(経路外認証器の場合はプライマリチャネル)との間の通信は、認証器出力の秘匿性と中間者攻撃に対する耐性を提供する保護された認証済みチャネルを介して行われるものとする(SHALL)。

政府機関が運用する検証主体は、AAL 1において、[FIPS 140] Level 1 の要求事項に適合していることを確認されるものとする(SHALL)。

4.1.3. アサーション 要求事項

AAL 1で正当であるために、認証器のアサーションは SP 800-63C で定義されている要求事項を満たすものとする(SHALL)。無記名アサーションを利用してもよい(MAY)。

4.1.4. 再認証

AAL 1では、ユーザの活動に関わらず、加入者の再認証は少なくとも30日ごとに1回は繰り返し実施すべきである(SHOULD)。

4.1.5. セキュリティ統制

CSPは、[SP 800-53] または等価な業界標準で定義されているセキュリティ統制の低い基準に、適切に適合したセキュリティ統制を採用すべき(SHOULD)であり、 低い基準に対応する確実性の要求事項を最低限を満たしていることを保証すべきである(SHOULD)。

4.1.6. レコード保存

CSPは、準拠法及び規則の適用に合致する個別のレコード保存ポリシーに従うものとする。もしCSPが何らかの法的要件なくレコード保存をすることを選択する場合、CSPはレコードの記録期間を決定するためのプライバシリスクアセスメントを行うものとする(SHALL)。

4.2. 認証器保証レベル2(Authenticator Assurance Level 2)

AAL 2は、申請者が加入者に対して登録されている認証器を制御していることにより高い確実性を与える。2つの異なる認証要素が必要である。承認済み(approved)の暗号技術がAAL 2とそれ以上では必須である。

4.2.1. 許可された認証器タイプ

AAL 2では、多要素認証器の所持、または2つの単一要素認証器の組み合わせが求められる。認証器の要求事項は5章で述べられている。

多要素認証器を利用する際、以下の任意のものを利用してよい:

• 多要素 OTP デバイス
• 多要素暗号ソフトウェア
• 多要素暗号デバイス

2つの単一要素認証器を組み合わせる際には、記憶シークレット認証器と、以下のリストから1つの所有ベース(“something you have”)の認証器を含むこととする(SHALL):

• ルックアップシークレット
• 経路外
• 単一要素OTPデバイス
• 単一要素暗号ソフトウェア
• 単一要素暗号デバイス

注記: 上記の記憶シークレット認証器の要件は、異なる2タイプの認証器要素を利用するということに由来する。本仕様に準拠した全ての生体認証器は多要素であるので、something you know (記憶シークレット)は使っても良いし使わなくても良い。

4.2.2. 認証器及び検証主体 要求事項

AAL 2で用いられる暗号認証器は、承認済み(approved)暗号を使うものとする(SHALL)。政府機関によって開発された認証器は、[FIPS 140] Level 1の要求事項に適合していることを確認されるものとする(SHALL)。汎用オペレーティング・システム環境で動作するソフトウェアベースの認証器は、実施上(例、マルウェアやJailbreakによって)それ自身が動作しているプラットフォームが改竄されていることを検出するよう試みてもよく(MAY)、そのような改竄が検出されると操作を拒否すべき(SHOULD)である。

申請者とチャネル(経路外認証器の場合はプライマリチャネル)との間の通信は、認証器出力の秘匿性と中間者攻撃に対する耐性を提供する保護された認証済みチャネルを介して行われるものとする(SHALL)。

政府機関によって運営されているAAL 2の検証主体は、[FIPS 140] Level 1の要求事項に適合していることを確認されるものとする(SHALL)。

4.2.3. アサーション要求事項

AAL 2で正当であるために、認証器のアサーションは SP 800-63C で定義されている要求事項を満たすものとする(SHALL)。無記名アサーションを利用してもよい(MAY)。

4.2.4. 再認証

AAL 2では、ユーザの活動に関わらず、加入者の再認証は少なくとも12時間に1回は繰り返し実施するものとする(SHALL)。加入者の再認証はユーザが活動していない時間が30分を超えないように繰り返し実施することとする(SHALL)。CSPは、望ましい場合、ユーザが活動していないことで生じるタイムアウトの間際に、ユーザに対し活動契機となるように入力を促してもよい(MAY)。 再認証は単一認証要素を利用してよい(MAY)。

4.2.5. セキュリティ統制

CSPは、[SP 800-53] または等価な業界標準で定義されているセキュリティ統制の適度な基準に、適切に適合したセキュリティ統制を採用すべき(SHOULD)であり、 適度な基準に対応する確実性の要求事項を最低限を満たしていることを保証すべきである(SHOULD)。

4.2.6. レコード保存

CSPは、あらゆる法律及び規則の適用に対しても合致する個別のレコード保存ポリシーに従うものとする。もしCSPが何らかの法的要件なくレコード保存をすることを選択する場合、CSPはレコードの記録期間を決定するためのプライバシリスクアセスメントを行うものとする(SHALL)。

4.3. 認証器保証レベル(Authenticator Assurance Level 3)

AAL 3は、申請者が加入者に対して登録されている認証器を制御していることにより非常に高い確実性を与える。AAL3における認証は、暗号プロトコルを介した鍵の所持証明に基づいている。AAL 3は、さらに検証主体なりすまし耐性を持った”堅牢な”の暗号認証器を必要とする、という点を除けばAAL 2と同一である。

4.3.1. 許可された認証器タイプ

認証器保証レベル 3では、3種類のハードウェアデバイスのうち、1つを利用する必要がある:

• 多要素暗号デバイス
• 単一要素暗号デバイス(記憶シークレットと連動して用いられる)

AAL 3で用いる全ての暗号デバイス認証器は、section 5.2.5に記載されている検証主体なりすまし耐性を備えるものとする(SHALL)。

4.3.2. 認証器及び検証主体 要求事項

申請者とチャネルとの間の通信は、認証器出力の秘匿性と中間者攻撃に対する耐性を提供する保護された認証済みチャネルを介して行われるものとする(SHALL)。AAL 3で利用される少なくとも1つの認証器は、Section 5.2.5に記載されているように検証主体なりすまし耐性を備えるものとする(SHALL)。

AAL 3で利用される多要素認証器は、[FIPS 140] Level 2、または少なくとも[FIPS 140] Level 3物理セキュリティ全体よりも高度な基準で確認されたハードウェア暗号モジュールであるものとする(SHALL)。 AAL 3で利用される単一要素暗号デバイスは、[FIPS 140] Level 1、または少なくとも[FIPS 140] Level 3物理セキュリティ全体よりも高度な基準で確認されているものとする(SHALL)。これらの要求事項は、[FIPS 201]準拠のPersonal Identity Verification (PIV) CardのPIV認証鍵を利用することで満たすことができる(CAN)。

AAL 3における検証主体は、[FIPS 140] Level 1またはそれ以上の基準で確認されるものとする(SHALL)。

4.3.3. アサーション要求事項

AAL 3で正当であるために、認証器のアサーションは SP 800-63C で定義されている 所持証明(proof-of-posession)アサーションの要件を満たすものとする(SHALL)。

4.3.4. 再認証

AAL 3では、ユーザの活動に関わらず、加入者の再認証は少なくとも12時間に1回は繰り返し実施するものとする(SHALL)。加入者の再認証はユーザが活動していない時間が15分を超えないように繰り返し実施することとする(SHALL)。再認証は両方の認証要素を利用するものとする(SHALL)。検証主体はユーザが活動していないことで生じるタイムアウトの前に、ユーザに対し活動契機となるように入力を促してもよい(MAY)。

4.3.5. セキュリティ統制

CSPは、[SP 800-53] または等価な業界標準で定義されているセキュリティ統制の高度な基準に、適切に適合したセキュリティ統制を採用すべき(SHOULD)であり、 高度な基準に対応する確実性の要求事項を最低限を満たしていることを保証すべきである(SHOULD)。

4.3.6. レコード保存

CSPは、あらゆる法律及び規則の適用に対しても合致する個別のレコード保存ポリシーに従うものとする。もしCSPが何らかの法的要件なくレコード保存をすることを選択する場合、CSPはレコードの記録期間を決定するためのプライバシリスクアセスメントを行うものとする(SHALL)。

4.4. プライバシー要件

CSPは[SP 800-53]で定義された適切に調整されたプライバシーコントロール、または他の等価な業界標準を採用すべきである(SHOULD)。

CSPは、認証実施や法令遵守、法的手続き以外の目的で認証器の情報を利用・開示しないものとし、追加の用途のためには、明確な通知を提供し、加入者から承諾を得るものとする(SHALL NOT)。CSPは、サービス条件に対する同意をとらなくてもよい(MAY NOT)。情報を収集した際の元々の目的に利用が限定されていることを保証するための対策が講じられるものとする(SHALL)。このような情報の利用が、認証実施や法令遵守、法的手続きに関連する用途に該当しないのであれば、CSPは通知を行い、加入者から同意を得るものとする(SHALL)。この通知は、SP 800-63A Section 8.2のNotice and Consentに記載されているのと同じ原則に従うべき(SHOULD)であり、法律に固執し過ぎたプライバシーポリシーや一般条件に丸め込むべきではない(SHOULD not)。明示的な目的外の用途がある場合は、むしろ加入者は追加の利用目的を理解するための意味のある方法、及び承諾または辞退する機会が提供されるべきである(SHOULD)。

CSPが政府機関または民間のプロバイダーであるかどうかにかかわらず、次の要件が認証サービスを提供・利用する政府機関に対して適用される:

1. 政府機関は、認証器の発行・維持を目的としたPersonally Identifiable Information (PII)の収集がPrivacy Act of 1974 [PrivacyAct]の要件に発展するかどうか分析を実施するため、プライバシー領域の政府機関幹部と協議するものとする(SHALL)。

• 政府機関は、必要に応じてそのような収集活動を対象とするレコード通知システムを公開するものとする(SHALL)。
• 政府機関は、認証器の発行・維持を目的としたPIIの収集がE-Government Act of 2002 [E-Gov]の要件に発展するかどうか分析を実施するため、プライバシー領域の政府機関幹部と協議するものとする(SHALL)。
• 政府機関は、必要に応じてそのような収集活動を対象とするPrivacy Impact Assement(PIA)を公開するものとする(SHALL)。

4.5. 要求事項要約

(参考; 要求規則は前セクションを参照のこと。)

Table 4-3は認証器保証レベル毎の要求事項を要約したものである:

要求事項	AAL 1	AAL 2	AAL 3
許可されている認証器タイプ	記憶シークレット; ルックアップシークレット; 経路外; 単一要素OTPデバイス; 多要素OTPデバイス; 単一要素暗号ソフトウェア; 単一要素暗号デバイス; 多要素暗号ソフトウェア; 多要素暗号デバイス	多要素OTPデバイス; 多要素暗号ソフトウェア; 多要素暗号デバイス; または記憶シークレットと以下の組み合わせ:  • ルックアップシークレット  • 経路外  • 単一要素OTPデバイス  • 単一要素暗号ソフトウェア  • 単一要素暗号デバイス	多要素暗号デバイス 単一要素暗号デバイス ＋   記憶シークレット
FIPS 140 確認	Level 1 (政府機関の検証主体)	Level 1 (政府機関の認証器及び検証主体)	Level 2 全体 (多要素認証器) Level 1 全体 (検証主体及び単一要素暗号デバイス) Level 3 物理セキュリティ (全ての認証器)
アサーション	無記名または所有証明	無記名または所有証明	所有証明のみ
再認証	30 日	12 時間または30分間活動なし; 単一認証要素を利用してもよい	12 時間または15分間活動なし; 両方の認証要素を利用するものとする
セキュリティ統制	[SP 800-53] 低い基準 (または 等価なもの)	[SP 800-53] 適度な基準 (または等価なもの)	[SP 800-53] 高い基準 (または等価なもの)
中間者攻撃耐性	必要	必要	必要
検証主体なりすまし耐性	不要	不要	必要

5. 認証器及び検証主体の要求事項

本章では、各認証器タイプごとの要求仕様詳細について明らかにする。Section 4で指定された再認証の要求事項の例外とともに、各認証器タイプごとの技術的要求事項が、それが利用されるAALとは関係なく、同じである。

5.1. 認証器タイプ毎の要求事項

5.1.1. 記憶シークレット

5.1.1.1. 記憶シークレット認証器

記憶シークレットは、加入者が指定する場合少なくとも8文字とするものとする(SHALL)。記憶シークレットがCSPまたは検証主体によってランダムに選択されたものである場合は、少なくとも6文字であるものとし(SHALL)、全て数字でもよい(MAY)。 CSPや検証主体は、指定された記憶シークレットがセキュリティ侵害を受けたブラックリストに出現するかどうかに基づいて拒否するかもしれず、そのような場合に加入者は、別の記憶シークレット値を選ぶものとする(SHALL)。 その他、記憶シークレットに課される複雑さに関する要求事項はあるべきではない(SHOULD)。このことについての根拠はAppendix Aに記載されている。

5.1.1.2. 記憶シークレット検証主体

検証主体は加入者が指定した、最低8文字の記憶シークレットを要求するものとする(SHALL)。検証主体はユーザが決定した記憶シークレットの場合は最低でも64文字とすべきである(SHOULD)。すべての印字可能なASCII [RFC 20] 文字(スペースも同様)は記憶シークレットとして許容されるべきである(SHOULD)。Unicode[ISO/ISC 10646:2014]文字も同様に許容されるべきである(SHOULD)。検証主体は、最低8文字以上であることの検証に先立って、連続した複数のスペースまたは全てのスペースを除去してもよい(MAY)。シークレット文字列の前後の切り詰めについては実施しないものとする(SHALL NOT)。前述の長さ要求を満たす目的で、それぞれのUnicode符号位置は単一文字としてカウントされるものとする(SHALL)。

もしUnicode文字が記憶シークレットとして許容されるならば、検証主体は、Unicode Standard Annex 15 [UAX 15] の Section 12.1で定義されている”Stablized Strings”を行うために、NFKCまたはNFKD正規化のどちらかを用いた正規化処理を適用すべきである(SHOULD)。Unicode文字を含む記憶シークレットを選択した加入者は、いくつかのエンドポイントでは異なって表現されるかもしれない文字があることを通知されるべきであり(SHOULD)、それが彼らが正しく認証を行うための能力に影響する可能性がある。この処理は記憶シークレットのバイト文字表現のハッシュ化に先立って適用される。

記憶シークレットは、CSP(例えばエンロールメント時など)また検証主体(ユーザが新しいPINを要求した時など)によりランダムに決定されるもので、最低6文字であるものとし(SHALL)、承認済み(approved)乱数生成器を利用して生成されるものとする(SHALL)。

記憶シークレット検証主体は、加入者に対して、未認証の申請者が簡単に手に入れることができる「ヒント」を記録しないものとする(SHALL NOT)。 記憶シークレットを選択する際、検証主体は加入者に対して特別なタイプの情報（例えば、あなたの最初のペットの名前はなんですか？といったもの）の入力を求めないものとする(SHALL)。

記憶シークレットの設定、変更の要求を処理する際、検証主体はシークレットの値を、一般的に利用されている値、予想できる値、セキュリティ侵害を受けた値と比較するものとする(SHALL)。例えば、以下のリスト(に限定するものではない)が含んでいるものでよい(MAY):

• 過去にセキュリティ侵害にあったパスワード集
• 辞書に含まれる言葉
• サービス名や、ユーザ名、そこから派生するようなものなど、文脈によって特定可能な単語

もし選択したシークレットがリスト中に存在したら、加入者は、それが一般的に使われているため異なるシークレット値を選び直す必要があるということを知らされ、異なる値の選択を求められるものとする(SHALL)。

検証主体は、攻撃者が加入者のアカウント乗っ取りのために試みた認証失敗の回数を有効に制限するスロットリングの仕組みSection 5.2.2を実装するものとする(SHALL)。

検証主体は他の構成ルール(例えば、異なる文字種の組み合わせ)を記憶シークレットに課すべきではない(SHOULD NOT)。検証主体は、認証器が侵害されている、または加入者が変更要求を行った証拠がない限りは、記憶シークレットを任意で(例えば、定期的に)変更するよう要求すべきではない(SHOULD NOT)。

申請者が記憶シークレットを正しく入力することを支援するために、検証主体は(典型的なドットやアスタリスク表示ではなく)シークレットを表示するオプションを提供すべき(SHOULD)である。検証主体は、申告者が入力文字を確認するのに十分な時間表示したあとは、文字を非表示にするものとする(SHALL)。これにより、申請者は彼らのスクリーンが盗み見られている可能性が高くない場所にいるとき、自身で入力を検証することができる。

検証主体は承認済み(approved)暗号化を利用するものとし(SHALL)、記憶シークレットを要求する際には、盗聴や中間者攻撃を防止する目的で保護された認証済みのチャネルを用いるものとする(SHALL)。

検証主体は、オフライン攻撃へ対策する形式で記憶シークレットを保存するものとする(SHALL)。シークレットは、 ソルト値と一緒に、例えば[SP800-132]で記載されているPBKDF2のような承認済み(approved)のハッシュを用いてハッシュ化されるものとする(SHALL)。 ソルト値は32ビット以上のランダム値で、承認済み(approved)の乱数生成器を用いて生成され、ハッシュ結果とともに記録される。少なくとも繰り返し10000回のハッシュ関数を適用すべきである(SHOULD)。ハッシュ認証器から分離されて記録される鍵(例:ハードウェアセキュリティモジュール中)を用いる鍵付ハッシュ関数(例:HMAC)は、記録済みハッシュ化認証器に対する辞書攻撃に対する更なる対抗方法として利用されるべきである(SHOULD)。

5.1.2. ルックアップシークレット

5.1.2.1 ルックアップシークレット認証器

CSPがルックアップシークレット認証器を生成する際、承認済み(approved)乱数生成器を用いてシークレットのリストを生成するものとし(SHALL)、加入者に対して認証器を安全に届けるものとする(SHALL)。ルックアップシークレットは最低64ビットのエントロピーを持つものとする(SHALL)か、Section 5.2.2に記載があるように認証失敗回数の制限を行ったうえで最低20ビットのエントロピーを持つものとする(SHALL)。

もし認証機がルックアップシークレットを連続してリストから利用する場合、加入者は一度認証に成功した場合に限ってシークレットを破棄してもよい(MAY)。

5.1.2.2. ルックアップシークレット検証主体

ルックアップシークレットの検証主体は申請者に対して、彼らの認証器から得られる次のシークレット、または特定の(例:付番された)シークレットの入力を促すものとする(SHALL)。認証器から得られたシークレットは1度しか正常に利用できないものとする(SHALL)。従って、ある認証器は有限の回数に限り認証を成功させるために利用することができる。もしルックアップシークレットが格子状のカードから得られる場合、格子の各セルは1度だけ利用するものとする(SHALL)。

検証主体は、オフライン攻撃へ対策する形式でルックアップシークレットを保存するものとする(SHALL)。シークレットは、ソルト値と一緒に、[SP800-132]で記載されている承認済み(approved)のハッシュ関数を用いてハッシュ化されるものとする(SHALL)。 ソルト値は128ビット以上のランダム値で、承認済み(approved)の乱数生成器を用いて生成され、ハッシュ結果とともに記録される。ハッシュ認証器から分離されて記録される鍵(例:ハードウェアセキュリティモジュール中)を用いる鍵付ハッシュ関数(例:HMAC [FIPS198-1])は、記録済みハッシュ化認証器に対する辞書攻撃に対する更なる対抗方法として利用されるべきである(SHOULD)。

ルックアップシークレットは、承認済み(approved)乱数生成器を用いてシークレットのリストを生成するものとし(SHALL)、最低20ビットのエントロピーを持つものとする(SHALL)。ルックアップシークレットが64ビット未満のエントロピーを持つような場合、検証主体はSection 5.2.2に記載があるように、攻撃者が加入者のアカウント乗っ取りのために試みた認証失敗の回数を有効に制限するスロットリングの仕組みを実装するものとする(SHALL)。

検証者は承認済み(approved)暗号化を利用するものとし(SHALL)、ルックアップシークレットを要求する際には、盗聴や中間者攻撃を防止する目的で、保護された認証済みチャネルを利用するものとする(SHALL)。

5.1.3. 経路外(Out-of-Band)デバイス

5.1.3.1. 経路外認証器

経路外認証器は経路外シークレットや認証リクエストを取得するために検証主体との分離された通信チャネルを確立するものとする(SHALL)。このチャネルはプライマリ通信チャネルとの関係において経路外(out-of-band)であるとし、同じデバイス上で終端されている場合でさえも、申請者の認可なしに一方から他方に対して情報が漏洩することがないようなデイバイスであることを前提とする。

経路外デバイスは一意にアドレス可能であるとし(SHALL)、セカンダリチャネルを介した通信はプライベートであるものとする(SHALL)。VoIP(voice-over-IP)電話サービスの中にはテキストメッセージや音声コールを、物理デバイスの所持なしに配信することができるものがあり、これらは経路外認証で利用しないものとする(SHALL NOT)。Emailメッセージや他の種類のインスタントメッセージを受け取ることができる能力は、一般的には特別なデバイスを所持していることの証明にはならないため、経路外認証方式では利用されないものとする(SHALL NOT)。スマートフォンアプリケーションのようなセキュアな通信プロトコルを用いて一意に経路外デバイスを特定する仕組みが、経路外認証に用いられるべきである(SHOULD)。

経路外認証器は、検証主体との通信において以下に記載する方法の1つを用いて、一意に自身の真正性を証明するものとする(SHALL):

• 承認済み(approved)暗号理論を利用して検証主体に対する保護された認証済みチャネルを確立する。利用する鍵はデバイス上で最もセキュアなストレージ(例:キーチェーン、Trusted Platform Module、可能ならばTrusted Execution Environment)に記録されるものとする(SHALL)。

• SIMカードまたはデバイスを一意に識別する等価な方法を用いて公衆携帯電話網に対して認証する。この方法は電話網(SMSまたは音声)を介して経路外デバイスに対して検証主体からシークレットが送信される場合に限り用いるものとする(SHALL)。

もし検証主体から経路外デバイスに対してシークレットが送信されるならば、デバイスは所有者によってデバイスがロックされている(例:PINやパスコード入力を求める)間は認証シークレットを表示すべきではない(SHOULD NOT)。しかしながら認証器はロックされたデバイス上で認証シークレットを受信したことは表示してもよい(MAY)。

もし経路外認証機がセカンダリ通信チャネルを介して承認メッセージを送信するならば(申請者がプライマリ通信チャネルに対して受け取ったシークレットを送信するよりもむしろ)、次のうち1つを実施するものとする(SHALL):

• 認証器はプライマリチャネルから得たシークレットを転送することを許容するものとし(SHALL)、認証トランザクションに対する承認と関連付けるために、セカンダリチャネルを介して検証主体に対して送信するものとする(SHALL)。申請者は送信を手動で実施、またはバーコード・QRコードといった技術を利用して送信を達成してもよい(MAY)。

• 認証器はセカンダリチャネルを介して検証主体から受け取ったシークレットを提示し、申請者に対してプライマリチャネルのシークレットとの一貫性を検証するよう促した上で、申請者から「はい/いいえ」の応答を受け入れるものとする(SHALL)。

5.1.3.2. 経路外検証主体

SMSメッセージや音声コールが傍受されたりリダイレクトされたりするかもしれないというリスクに起因し、新システムの実装者は代替となる認証器を注意深く検討すべきである(SHOULD)。もし経路外検証が公衆交換電話網(PSTN:public switched telephone network)を用いて行われるならば、検証主体は事前登録された電話番号がVoIP(または他のソフトウェアベースの)サービスと関連付けられていないことを検証することとする(SHALL)。そのうえでSMSや音声メッセージは事前登録された電話番号に対して送信される。事前登録された電話番号の変更が、変更時に2要素認証なしで可能となっていないものとする(SHALL NOT)。

注記: 公衆交換電話網(SMSまたは音声)を用いた経路外(OOB)認証は非推奨であり、このガイドラインの将来の版では削除される。

経路外検証がセキュアなアプリケーション(例:スマートフォン上)を利用して行われる場合、検証主体はデバイスに対してPush通知を行ってもよい(MAY)。検証主体は保護された認証済みチャネルの確立を待ち、認証器の識別キーを検証する。認証器は識別キー自身を記録しないものとする(SHALL NOT)が、承認済み(approved)のハッシュ関数を用いたハッシュのような検証方法を用いるか、認証器を一意に識別するための識別キーの所持証明をおこなうものとする(SHALL)。認証すると、検証主体は認証シークレットを認証器に対して送信する。

経路外認証器の種別に応じて、以下のうち1つを行うものとする(SHALL):

• シークレットをプライマリチャネルに送出: 検証主体は加入者の認証器を持つデバイスに対して認証の準備を示すシグナルを送信してもよい(MAY)。そのうえで、経路外認証器に対してランダムなシークレットを送信するものとする(SHALL)。検証主体はプライマリ通信チャネル上でシークレットが返却されるのを待つものとする(SHALL)。

• シークレットをセカンダリチャネルに送出: 検証主体はランダムな認証シークレットをプライマリチャネル経由で申請者に対して表示するものとする(SHALL)。そのうえで、セカンダリチャネル上で申請者の経路外認証器からシークレットが返却されるのを待つものとする(SHALL)。

• 申告者によるシークレットの検証主体: 検証主体はランダムな認証シークレットをプライマリチャネル経由で申請者に対して表示するものとし(SHALL)、セカンダリチャネルを介して経路外認証器に対して同じシークレットを送信し申請者に提示するものとする(SHALL)。そのうえで、セカンダリチャネルを介した承認(非承認)メッセージを待つものとする(SHALL)。

全てのケースにおいて、5分以内に完了しない認証は不正とみなすものとする(SHALL)。

検証主体は、承認済み(approved)乱数生成器を用いて最低20ビットのエントロピーでランダムな認証シークレットを生成するものとする(SHALL)。もし認証シークレットが64ビット未満のエントロピーを持つような場合、検証主体はSection 5.2.2に記載があるように、攻撃者が加入者のアカウント乗っ取りのために試みた認証失敗の回数を有効に制限するスロットリングの仕組みを実装するものとする(SHALL)。

5.1.4. 単一要素OTPデバイス

5.1.4.1. 単一要素OTP認証器

単一要素OTP認証器は2つの永続的な値を保持する。1つ目はデバイスの生存期間の間保持し続ける対象鍵である。2つ目は認証機が使われる都度変化する、またはリアルタイムクロックに基づいているノンスである。

秘密鍵とそのアルゴリズムは最低でも[SP 800-131A]の最新版で定義されたセキュリティ強度(現在は112ビット)であるものとする(SHALL)。ノンスは、デバイスの生存期間に渡りデバイスが操作される都度一意であることを保証するために十分長いこととする(SHALL)。

認証器出力は、鍵とノンスとを安全な方法で結合し、承認済み(approved)ブロック暗号またはハッシュ関数を施して得られる。認証器出力は少なくとも(約20ビットのエントロピーの)6桁の数字になるよう切り詰めてもよい(MAY)。

もし認証器出力を生成するために利用されるノンスがリアルタイムクロックをベースとしている場合、ノンスは少なくとも2分毎に変化するものとする(SHALL)。与えられたノンスと結び付けられているOTP値は一度だけ受け入れられるものとする(SHALL)。

5.1.4.2. 単一要素OTP検証主体

単一要素OTP検証主体は、認証器によるOTPの生成プロセスを実質的に再現する。検証主体は、認証器が使う対象鍵を所持しており、セキュリティ侵害に対して強力な防御が行われているものとする(SHALL)。

多要素OTP認証器が加入者アカウントに紐付けられている時、検証主体(または関連付けられているCSP)は承認済み(approved)暗号法を利用した認証器の出処(典型的には製造者)から認証器の出力を再現するために必要なシークレットを得るものとする(SHALL)。

検証主体は、OTPを収集する際の盗聴や中間者攻撃に対抗するために、承認された(approved)暗号化を利用し、保護された認証済みチャネルを利用するものとする(SHALL)。時間ベースのワンタイムパスワードの生存期間は2分未満であるものとする(SHALL)。

もし認証器出力が64ビット未満のエントロピーしか持ち得なければ、検証主体はSection 5.2.2に記載があるように、攻撃者が加入者のアカウント乗っ取りのために試みた認証失敗の回数を有効に制限するスロットリングの仕組みを実装するものとする(SHALL)。

5.1.5. 多要素OTPデバイス

5.1.5.1. 多要素OTP認証器

多要素OTP認証器は、認証器からパスワードを得るために記憶シークレットの入力または生体認証の利用を要求する点を除いて、単一要素OTP認証器(Section 5.1.4.1参照)と同じ方法で動作する。いずれの場合でも追加要素の入力が必要であるものとする(SHALL)。

認証器出力は少なくとも(約20ビットのエントロピーの)6桁の数字とする(SHALL)。出力は、個人所有のハードウェアデバイス上に保存された対象鍵と、ワンタイムパスワードを生成するためのノンスとを安全な方法で結合し、承認済み(approved)ブロック暗号またはハッシュ関数を施して得られるものとする(SHALL)。ノンスは日時またはデバイス上で生成されるカウンタを基にしてもよい(MAY)。

アクティベーションのために認証器が用いる記憶シークレットは、少なくとも(約20ビットのエントロピーの)6桁の数字またはそれと等しい複雑さであるものとし(SHALL)、Section 5.2.2で指定されるようにレート制限をおこなうものとする(SHALL)。生体アクティベーション要素は、連続する認証失敗回数の制限を含むSection 5.2.3の要件に合致することとする(SHALL)。

暗号化されていない鍵とアクティベーションシークレット、生体サンプル(及び信号処理結果のプローブのような、生体サンプル由来の任意の生体データ)はパスワード生成後、直ちにメモリから消去するものとする(SHALL)。

5.1.5.2. 多要素OTP検証主体

多要素OTP検証主体は、認証器によるOTPの生成プロセスを実質的に再現するが、2要素目の要求は行わない。例えば、認証器が用いる対象鍵は、セキュリティ侵害に対して強力な防御が行われているものとする(SHALL)。

多要素OTP認証器が加入者アカウントに紐付けられている時、検証主体(または関連付けられているCSP)は承認済み(approved)暗号法を利用した認証器の出処(典型的には製造者)から認証器の出力を再現するために必要なシークレットを得るものとする(SHALL)。検証主体またはCSPは、認証器の出処から、認証機が多要素認証デバイスであるということのアサーションも同様に取得するものとする(SHALL)。多要素認証器であるという信頼できるアサーションがない場合、検証主体はsection 5.1.4に従い認証器を単一要素として扱う。

検証主体は、OTPを収集する際の盗聴や中間者攻撃に対抗するために、承認された(approved)暗号化を利用し、保護された認証済みチャネルを利用するものとする(SHALL)。時間ベースのワンタイムパスワードの生存期間は2分未満であるものとする(SHALL)。

もし認証器出力またはアクティベーションのためのシークレットが64ビット未満のエントロピーしか持ち得なければ、検証主体はSection 5.2.2に記載があるように、攻撃者が加入者のアカウント乗っ取りのために試みた認証失敗の回数を有効に制限するスロットリングの仕組みを実装するものとする(SHALL)。生体アクティベーション要素は、連続する認証失敗回数の制限を含むSection 5.2.3の要件に合致することとする(SHALL)。

5.1.6. 単一要素暗号ソフトウェア

5.1.6.1. 単一要素暗号ソフトウェア認証器

単一要素暗号ソフトウェア認証器は、認証器で一意な秘密鍵を保持している。利用する鍵はデバイス上で最もセキュアなストレージ(例:キーチェーン、Trusted Platform Module、可能ならばTrusted Execution Environment)に記録されるものとする(SHALL)。デバイス上のソフトウェアコンポーネントがアクセス要求を行ったときのみ鍵にアクセスできるよう制限するアクセス制御を用いて、鍵は許可のない暴露から強力に保護されているものとする(SHALL)。

5.1.6.2. 単一要素暗号ソフトウェア検証主体

単一要素暗号ソフトウェア検証主体に対する要求事項は、Section 5.1.7.2 に記載されている単一要素暗号デバイス検証主体に対する要求事項と同一である。

5.1.7. 単一要素暗号デバイス

5.1.7.1. 単一要素暗号デバイス認証器

単一要素暗号デバイス認証器はデバイスで一意かつエクスポートされない(デバイスから除去できない)ものとする(SHALL NOT)秘密鍵を保持している。チャレンジノンスに署名することで動作し、通常はUSBポートなどのコンピュータに対するダイレクトなインタフェースを介して提供される。暗号デバイスはソフトウェアを含んでいるが、全ての組み込みソフトウェアはCSP(または他の発行者)の制御下にあるという点、及び認証器全体で認証時のAALにおけるFIPS 140要求事項に適合する必要がある点において、暗号ソフトウェア認証器とは異なっている。

秘密鍵とそのアルゴリズムは最低でも[SP 800-131A]の最新版で定義されたセキュリティ強度(現在は112ビット)であるものとする(SHALL)。チャレンジノンスは少なくとも64ビット長であるものとする(SHALL)。承認済み(Approved)暗号法が利用されるものとする(SHALL)。

単一要素暗号デバイス認証器は動作のためにボタンを押すなどの物理的な入力を必要とすべきである(SHOULD)。これにより、デバイスが接続している先がセキュリティ侵害をうけているようなときに起こりうるデバイスの意図しない動作を防止することができる。

5.1.7.2. 単一要素暗号デバイス検証主体

単一要素暗号デバイス検証主体はチャレンジノンスを生成し、対応する認証器に送信する。また、認証器出力をデバイスの所有を検証するために利用する。認証器出力は特定の暗号デバイスとプロトコルに強く依存し、一般的にはある種の署名付メッセージになっている。

検証主体は、各認証器に対応する対象・非対称暗号鍵を保持している。鍵の両タイプともに改変に対する保護がなされているものとし(SHALL)、対象鍵については更に、許可のない暴露から強力に保護されているものとする(SHALL)。

チャレンジノンスは少なくとも64ビット長であるとし(SHALL)、認証器の生存期間を通して一意、または(承認済み乱数生成器を用いて生成され)統計上一意であるものとする(SHALL)。

5.1.8. 多要素暗号ソフトウェア

5.1.8.1. 多要素暗号ソフトウェア認証器

多要素暗号ソフトウェア認証器は、認証器で一意かつ、記憶シークレットや生体情報などの追加の要素の入力なしではアクセスすることができない秘密鍵を保持している。利用する鍵はデバイス上で最もセキュアなストレージ(例:キーチェーン、Trusted Platform Module、可能ならばTrusted Execution Environment)に記録されるべきである(SHOULD)。

認証器を用いた各認証操作は追加の要素の入力を要求するものとする(SHALL)。

アクティベーションのために認証器が用いる記憶シークレットは、少なくとも(約20ビットのエントロピーの)6桁の数字またはそれと等しい複雑さであるものとし(SHALL)、Section 5.2.2で指定されるようにレート制限をおこなうものとする(SHALL)。生体アクティベーション要素は、連続する認証失敗回数の制限を含むSection 5.2.3の要件に合致することとする(SHALL)。

暗号化されていない鍵とアクティベーションシークレット、生体サンプル(及び信号処理結果のプローブのような、生体サンプル由来の任意の生体データ)は認証トランザクションの実施後、直ちにメモリから消去するものとする(SHALL)。

5.1.8.2. 多要素暗号ソフトウェア検証主体

多要素暗号ソフトウェア検証主体に対する要求事項は、Section 5.1.8.2に記載されている多要素暗号デバイス検証主体に対する要求事項と同一である。

5.1.9. 多要素暗号デバイス

5.1.9.1. 多要素暗号デバイス認証器

多要素暗号デバイス認証器は、認証器で一意かつ、記憶シークレットや生体情報などの追加要素の入力がある場合のみアクセス可能な秘密鍵を保持する目的で、耐タンパ性を持ったハードウェアを利用する。暗号デバイスはソフトウェアを含んでいるが、全ての組み込みソフトウェアはCSP(または他の発行者)の制御下にあるという点、及び認証器全体で認証時のAALにおけるFIPS 140要求事項に適合する必要がある点において、暗号ソフトウェア認証器とは異なっている。

秘密鍵とそのアルゴリズムは最低でも[SP 800-131A]の最新版で定義されたセキュリティ強度(現在は112ビット)であるものとする(SHALL)。チャレンジノンスは少なくとも64ビット長であるものとする(SHALL)。承認済み(Approved)暗号法が利用されるものとする(SHALL)。

認証器を用いた各認証操作は追加の要素の入力を要求すべきである(SHOULD)。追加要素の入力はデバイス上での直接入力またはハードウェア接続(例: USBやスマートカード)を介して行われてもよい(MAY)。

アクティベーションのために認証器が用いる記憶シークレットは、少なくとも(約20ビットのエントロピーの)6桁の数字またはそれと等しい複雑さであるものとし(SHALL)、Section 5.2.2で指定されるようにレート制限をおこなうものとする(SHALL)。生体アクティベーション要素は、連続する認証失敗回数の制限を含むSection 5.2.3の要件に合致することとする(SHALL)。

暗号化されていない鍵とアクティベーションシークレット、生体サンプル(及び信号処理結果のプローブのような、生体サンプル由来の任意の生体データ)は認証トランザクションの実施後、直ちにメモリから消去するものとする(SHALL)。

5.1.9.2 多要素暗号デバイス検証主体

多要素暗号デバイス検証主体はチャレンジノンスを生成し、対応する認証器に送信する。また、認証器出力をデバイスとアクティベーション要素の所有を検証するために利用する。

検証主体は、各認証器に対応する対象・非対称暗号鍵を保持している。鍵の両タイプともに改変に対する保護がなされているものとし(SHALL)、対象鍵については更に、許可のない暴露から強力に保護されているものとする(SHALL)。

チャレンジノンスは少なくとも64ビット長であるとし(SHALL)、認証器の生存期間を通して一意、または(承認済み乱数生成器を用いて生成され)統計上一意であるものとする(SHALL)。検証操作は承認済み(approved)暗号法を用いることとする(SHALL)。

5.2. 一般認証器要求事項

5.2.1. 物理認証器

CSPは加入者に対して、認証器の盗難や紛失を正しく防止する方法について指示するものとする(SHALL)。CSPは加入者から認証機の盗難や紛失の疑いがある旨の通知に対し、直ちに認証器を無効化、中断するメカニズムを備えるものとする(SHALL)。

5.2.2. レート制限 (スロットリング)

800-63-2 sec 8.2.3, p.75参照

認証器出力やアクティベーションシークレットが十分なエントロピーを持たない場合、検証主体はオンライン推測攻撃に対抗するための制御を実装するものとする(SHALL)。指定された認証器の説明に記載がなければ、検証主体は、オンライン攻撃者に対し、同一アカウントで30日間で100回の認証失敗しか試行できないよう効果的に制限をするものとする(SHALL)。

加入者と思われる認証試行を、攻撃者によるものと思われる試行よりも優先させるような追加のテクニックを用いてもよい(MAY):

• 申請者に対して、認証する前にCAPTCHA(Completely Automated Public Turing test to tell Computers and Humans Apart)の入力を要求

• 申請者に対して、認証失敗後に再度認証する前に短期間の待ち(許容する最大認証失敗にどれだけ近づいているか次第で、30秒から1時間まで任意)を要求

• 加入者が以前認証成功したことがあるIPアドレスのホワイトリストからのみ認証要求を受理

• ユーザの振る舞いが通常の範疇にあるかないかを特定するリスクベースまたは適応型認証の手法を活用

これらはしばしばユーザに不便を感じさせてしまうため、検証主体は、上記の手法を用いる前に、ある程度の回数の認証失敗を許容すべき(SHOULD)である。

加入者が認証に成功した際、検証主体は同一IPアドレスからの以前の認証失敗回数を無視すべきである(SHOULD)。

5.2.3. バイオメトリクスの利用

様々な理由で、本書は認証におけるバイオメトリクスの利用を限定的にサポートする。それらは以下のとおりである:

• バイオメトリクスにおけるマッチすべきものがマッチしない割合(False Match Rate: FMR)及びマッチすべきではないものがマッチしてしまう割合(False Non-Match Rate: FNMR)は、それら自身は加入者認証に確実性を与えるものではない。更に、FMRとFNMRはスプーフィング攻撃の原因にはならない。

• バイオメトリクスマッチングは確率的なものであるが、一方他の認証要素を決定的なものである。

• バイオメトリクスのテンプレート保護スキームは、他の認証要素(例: PKI証明書やパスワード)に相当するバイオメトリッククレデンシャルを無効化するための手段を提供する。しかしながら、そのようなソリューションの可用性は制限されており、これらの手段を試験するための標準も策定中の段階である。

• バイオメトリクス特性はシークレットにはならない。それらはオンラインで取得したり、知識のあるなしに関わらず誰かが携帯電話のカメラで(顔)写真を取ることができ、誰かが触った物から(例えば潜在的に指紋を)採取することができ、高精細な画像から(例えば青い目の虹彩パターンを)キャプチャすることができる。生体検知のようなPresentation attack detaction(PAD)技術は、これらのタイプの攻撃リスクを緩和することができるが、CSPと加入者のニーズに合うようにセンサーがPADを適切に処理することを保証する必要がある。

したがって、認証におけるバイオメトリクスの使用は、以下の要件とガイドラインの下でサポートされる:

バイオメトリクスはもう一つの認証要素(somthing you nowやshomething you have)とともに用いられるものとする(SHALL)。

配備するバイオメトリックシステムの実証試験は、マッチング性能の面で等価エラーレートが ** 1000分の1 またはそれよりも良いこと実証するものとする(SHALL)。バイオメトリックシステムはFMRが **1000分の1またはそれよりも良い状態で動作するものとする(SHALL)。

バイオメトリックセンサーと後続の処理が、センサーの置き換えを防ぐ統合ユニットと一体でない場合、センサー(またはセンサー置き換えを防ぐ統合ユニットを持つエンドポイント)は、それが認定済み、または処理エレメントに対して自身の認証を行うことで要件を満たすような適格のセンサーであることを示すものとする(SHALL)。

バイオメトリックシステムはpresentation attack protection(PAD)を実装しなければならない(SHOULD)。配備されるバイオメトリックシステムの試験では、少なくともPADの(speciesとして知られている)各関連攻撃タイプに対して90%の耐性(presentation attackの阻止回数/試行回数で定義される)があることを示すべきである(SHOULD)。

注記: Presentation attack detactionはこのガイドラインの将来の版では普遍的な要件として考えることになる。

バイオメトリックシステムは3回までの連続した認証試行の失敗を許容するものとする(SHALL)。もし上記の要件に一致するpresentation attack detectionが実装されている場合は、10回までの連続した認証試行の失敗を許容するものとする(SHALL)。一度上限に達すると、申請者は別の認証器または記憶シークレットなどの他の要素で自身の認証器をアクティベートする必要がある。

バイオメトリックマッチングは、申請者のデバイス上で局所的に行われるべき(SHOULD)、または中央の検証主体で実施してもよい(MAY)。

マッチングを中央で実施する場合:

• バイオメトリックの利用は承認済み(approved)暗号法を用いて特定される単一の特定デバイスに強く結び付けられているものとする(SHALL)。
• バイオメトリックの破棄は、ISO/IEC 24745で触れられているバイオメトリックテンプレート保護を実装するものとする(SHALL)。
• センサー(またはセンサー置き換え対策でエンドポイントとセンサーを結合した統合ユニット)と中央の検証主体との間の保護された認証済みチャネルが確立され、申請者からバイオメトリックのサンプルが取得される前にセンサーが認証されるものとする(SHALL)。
• バイオメトリクスの送信は保護された認証済みチャネルを経由して行われる。

認証プロセス中で収集されたバイオメトリックサンプルは、マッチングアルゴリズムの学習や、ユーザの同意で研究目的で利用してもよい(MAY)。バイオメトリックサンプル(及び信号処理結果のプローブのような、バイオメトリックサンプル由来の任意のバイオメトリックデータ)はパスワード生成後、直ちにメモリから消去するものとする(SHALL)。

バイオメトリクスは登録の否認を防ぐため、及びSP 800-63Aで記載されている全ての登録プロセスのフェーズに参加する同一個人であることを検証するために、利用されることがある。

5.2.4 Attestation(証明)

エンドポイントに対して直接接続、または埋め込まれた認証器は次のように認証プロトコルの一部として検証主体に対してAttestation(証明)情報を伝達する:

• 出処、健康、認証器やエンドポイントの一貫性
• 認証器のセキュリティ機能
• バイオメトリックセンサーのセキュリティや性能特性
• センサーモダリティ

Attestation(証明)が署名されている場合、最低でも[SP 800-131A]の最新版で定義されたセキュリティ強度(現在は112ビット)を提供するデジタル署名を用いるものとする(SHALL)。Attestation(証明)情報はリスクベース認証の判断の一部として利用してもよい(MAY)。

SP 800-63Cで記載されている連携認証を行う場合、検証主体は何らかのAttestation(証明)情報をRelying partyに提供するアサーションに含めるべきである(SHOULD)。

5.2.5 検証主体なりすまし対策

検証主体なりすまし攻撃、しばしばフィッシング攻撃と言われ、検証主体やRelying Partyになりすまして不用心な申請者を騙して詐欺サイトに対して認証させる試みとして知られている。SP 800-63の以前の版では、検証主体なりすまし攻撃に対する耐性があるプロトコルが、中間者攻撃への強い耐性(strongly man-in-the-middle registant)として知られていた。

検証主体なりすまし耐性のある認証プロトコルは検証主体を認証し、以下のどちらかを実施すること(SHALL):

1. 強くかつ不可逆に、検証主体によって送信・提示される証明書の公開鍵や、検証主体の認証済みホスト名・ドメイン名に認証器出力を結びつける、または

1. 検証主体の認証済みホスト名・ドメイン名が信頼済み検証主体のリストに記載されているかどうかを決定し、認証器出力をリスト内の検証主体にのみ受け渡す。

検証主体なりすまし耐性のある認証プロトコルの以前の分類の例としては、クライアント認証TLSがある。ネゴシエーション済みの特定TLSコネクション対して一意であるようなプロトコルから予めメッセージを受取り、そのメッセージに連動した認証器出力をクライアントが署名する。もし意図した検証主体に対して中継される場合は、検証主体のホスト名またはドメインを認証器出力の生成に不可逆に含めるようなテクニックを用いて、なりすました検証主体(攻撃者)には使えないような認証器出力を生成してもよい(MAY)。

検証主体なりすまし耐性プロトコルの近頃の分類では、認証器出力を信頼されている検証主体にのみ受け渡すようなアクセスコントロールに頼ったものもある。

対称的に、OOBやワンタイムパスワード認証器のような認証器出力を手動入力するような認証器では、申請者が注意して意図した検証主体と通信していることを見極めることが前提となるため、検証主体なりすまし耐性がないと考える(SHALL NOT)。

6. Authenticator Lifecycle Management

During the lifecycle of an authenticator bound to a subscriber’s identity, a number of events can occur that affect the use of that authenticator. These events include binding, loss, theft, unauthorized duplication, expiration, and revocation. This section describes the actions that SHALL be taken in response to those events.

6.1. Authenticator binding

Authenticators MAY be issued (provided) by a CSP as part of a process such as enrollment; in other cases, the subscriber MAY provide their own, such as software or hardware cryptographic modules. For this reason, this guideline refers to the binding of an authenticator rather than the issuance, but this does not exclude the possibility that an authenticator is issued as well.

Throughout the online identity lifecycle, CSPs SHALL maintain a record of all authenticators that are or have been associated with the identity. The CSP or verifier SHALL also maintain the information required for throttling authentication attempts when required, as described in section 5.2.2.

The record created by the CSP SHALL contain the date and time the authenticator was bound to the account and SHOULD include information about the binding, such as the IP address or other device identifier associated with the enrollment. If available, the record SHOULD also contain information about unsuccessful authentications attempted with the authenticator.

6.1.1. Enrollment

The following requirements apply when an authenticator is bound to an identity as a result of a successful identity proofing transaction, as described in SP 800-63A.

At IAL 2, the CSP SHALL bind at least one, and SHOULD bind at least two, authenticators to the subscriber’s online identity. Binding of multiple authenticators is preferred in order to recover from loss or theft of their primary authenticator. While at IAL 1 all identifying information is self-asserted, creation of online material or an online reputation makes it undesirable to lose control of an account as result of the loss of an authenticator. The second authenticator makes it possible to securely recover from that situation.

At IAL 2 and above, identifying information is associated with the online identity and the subscriber has undergone an identity proofing process as described in SP 800-63A. As a result, authenticators at the same AAL as the desired IAL SHALL be bound to the account. For example, if the subscriber has successfully completed proofing at IAL 2, AAL 2 or 3 authenticators are appropriate to bind to the IAL 2 identity. As above, the availability of additional authenticators provides backup methods of authentication if an authenticator is damaged, lost, or stolen.

Enrollment and binding MAY be broken up into a number of separate physical encounters or electronic transactions. (Two electronic transactions are considered to be separate if they are not part of the same protected session.) In these cases, the following methods SHALL be used to ensure that the same party acts as Applicant throughout the processes:

1. For remote transactions:
   1. The applicant SHALL identify himself/herself in each new transaction by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s phone number, email address, or postal address of record.
   2. Long-term authenticator secrets SHALL only be issued to the Applicant within a protected session.
2. For physical transactions:
   1. The applicant SHALL identify himself/herself in person by either using a secret as described above, or through the use of a biometric that was recorded during a prior encounter.
   2. Temporary secrets SHALL not be reused.
   3. If the CSP issues long-term authenticator secrets during a physical transaction, then they SHALL be loaded locally onto a physical device that is issued in person to the applicant or delivered in a manner that confirms the address of record.

6.1.2. Post-Enrollment Binding

6.1.2.1. Binding of additional authenticator at existing AAL

Subscribers SHOULD be encouraged to maintain at least two valid authenticators of each factor they will be using. For example, a subscriber that usually uses a one-time OTP device as a physical authenticator MAY also be issued a number of look-up secret authenticators, or register a device for out-of-band authentication, in case the physical authenticator is lost, stolen, or damaged.

Accordingly, CSPs SHOULD permit the binding of additional authenticators to a subscriber’s account. Before adding the new authenticator, the CSP SHALL first require the subscriber to authenticate at the AAL (or a higher AAL) at which the new authenticator will be used. When an authenticator is added, the CSP SHOULD send a notification to the subscriber. The CSP MAY limit the number of authenticators that may be bound in this manner.

6.1.2.2. Adding an additional factor to a one-factor account

If the subscriber’s account has only one authentication factor bound to it (at IAL 1/AAL 1), and an additional authenticator of a different authentication factor is to be added, the subscriber MAY request that the account be upgraded to AAL 2 (but still at IAL 1). Once this has been done, the CSP SHALL no longer permit the subscriber to use single-factor authentication.

Prior to binding the new authenticator, the CSP SHALL first require the subscriber to authenticate at AAL 1. The CSP SHOULD send a notification of the event to the subscriber.

6.1.2.3. Replacement of lost authentication factor

As a last resort, if a subscriber loses all authenticators of a factor necessary to complete multi-factor authentication and has been identity proofed at IAL 2 or 3, that subscriber SHALL repeat the identity proofing process. An abbreviated proofing process, confirming the binding of the claimant to previously-supplied evidence MAY be used if the CSP has retained the evidence from the original proofing process pursuant to a privacy risk assessment as described in SP 800-63A section 4.2. The CSP SHALL require the claimant to authenticate using an authenticator of the remaining factor (if any) to confirm binding to the existing identity. Reestablishment of authentication factors at IAL 3 SHALL be done in person and SHALL verify the biometric collected during the proofing process.

The CSP SHOULD send a notification of the event to the subscriber; this MAY be the same notice as is required as part of the proofing process.

6.1.3. Binding to a subscriber-provided authenticator

A subscriber MAY already possess authenticators suitable for authentication at a particular AAL. For example, he or she MAY have a two-factor authenticator from a social network provider, considered AAL2 and IAL1, and would like to use those credentials at a relying party that requires IAL2.

CSPs SHOULD, where practical, accommodate the use of subscriber-provided authenticators in order to relieve the burden to the subscriber of managing a large number of authenticators. Binding of these authenticators SHALL be done as described in section 6.1.2.1.

6.1.4. Renewal

The CSP SHOULD bind an updated authenticator an appropriate amount of time in advance of an existing authenticator’s expiration. The process for this SHOULD conform closely to the initial authenticator issuance process (e.g., confirming address of record, etc.). Following successful use of the new authenticator, the CSP MAY revoke the authenticator that it is replacing.

6.2. Loss, Theft, Damage, and Unauthorized Duplication

Loss, theft, damage to and unauthorized duplication of an authenticator are handled similarly, because in most cases one must assume that a lost authenticator has potentially been stolen or recovered by someone that is not the legitimate claimant of the authenticator. Damaged or malfunctioning authenticators SHALL be treated in a similar manner to protect against any possibility of extraction of the authenticator secret. One notable exception is when a memorized secret is forgotten without other indication of having been compromised (duplicated by an attacker).

To facilitate secure reporting of loss or theft of or damage to an authenticator, the CSP SHOULD provide the subscriber a method to authenticate to the CSP using a backup authenticator; either a memorized secret or a physical authenticator MAY be used for this purpose (only one authentication factor is required for this purpose). Alternatively, the subscriber MAY establish an authenticated protected channel to the CSP and verify information collected during the proofing process. Alternatively, the CSP MAY verify an address of record (email, telephone, or postal) and suspend authenticator(s) reported to have been compromised. The suspension SHALL be reversible if the subscriber successfully authenticates to the CSP and requests reactivation of an authenticator suspended in this manner.

6.3. Expiration

CSPs MAY issue authenticators that expire. If and when an authenticator expires, it SHALL NOT be usable for authentication. When an authentication is attempted using an expired authenticator, the CSP SHOULD give an indication to the subscriber that the authentication failure is due to expiration rather than some other cause.

The CSP SHALL require subscribers to surrender or prove destruction of any physical authenticator containing attribute certificates signed by the CSP as soon as practical after expiration or receipt of a renewed authenticator.

6.4. Revocation and Termination

Revocation of an authenticator (sometimes referred to as termination, especially in the context of PIV credentials) refers to removal of the binding between an authenticator and a credential the CSP maintains. CSPs SHALL revoke the binding of authenticators promptly when an online identity ceases to exist (e.g., subscriber’s death, discovery of a fraudulent subscriber), when requested by the subscriber, or when the CSP determines that the subscriber no longer meets its eligibility requirements.

The CSP SHALL require subscribers to surrender or prove destruction of any physical authenticator containing certified attributes signed by the CSP as soon as practical after revocation or termination takes place.

Further requirements on the termination of PIV credentials are found in [FIPS 201].

7. セッション管理

一度認証イベントが起きたあと、ユーザーが引き続きアプリケーションを継続して使用するときは、インタラクションの度に毎回認証イベントを繰り返す必要がないことが望まれる。 この要件は、ネットワーク経由で調整した幾つかのコンポーネントやアクターを含む認証イベントに関するフェデレーション シナリオ (ボリューム C で説明) で特に必要である。

この動作を実現するため、セッション は、ある認証イベントへの応答によって開始されてもよい (MAY)。そしてそのセッションはそれが終了されるときまで維持されなければならない (SHALL)。 セッションは、活動がないときのタイムアウト、明示的なログアウトイベント、その他の理由など、様々な理由により終了されることがある。 セッションは、ユーザーが自分の存在を主張することによって、いくつかまたはすべての認証イベントを繰り返す再認証イベント (セクション 7.2 で説明) を通して維持されてもよい (MAY)。

セッション管理は、ユーザビリティ要件としての連続的なクレデンシャルの提示において、キャッシュされたアンロック済みのクレデンシャルへのワークアラウンドを動機付けることや、まず認証イベントの新鮮さを否定することが望まれる。

7.1. セッション バインディング

セッションは、サブスクライバーが動作しているブラウザー、アプリケーション、オペレーティング システム (セッション主体) と、サブスクライバーがアクセスする RP や CSP (セッション ホスト) のソフトウェアの間に発生する。 セッション シークレットは、サブスクライバーのソフトウェアとアクセスされているサービスの間で共有される。 このシークレットは、セッションの 2 つのエンドをバインドし、ユーザーがしばらくの間サービスを継続して使用することを許可する。 シークレットは、直接的にユーザのソフトウェアによって与えられてもよい (MAY)。(a bearer secret) また、暗号メカニズムを使用して保証されてもよい (MAY)。(a proof of possession secret：所持を証明されたシークレット)。

セッションのバインドに使用されるシークレットは、認証イベントへの直接の応答としてセッション ホストによって生成されたものとする (SHALL)。 セッションは、その作成をトリガーした認証イベントの AAL プロパティを継承する必要がある (SHOULD)。セッションは認証イベントよりも低い AAL で考慮されてもよい (MAY)。また、認証のイベントよりも高い AAL とみなされることはない (SHALL NOT)。

セッションのバインドに使用されるシークレット:

• インタラクションの間、通常はユーザ認証のすぐ後で、セッション ホストによって生成されなければならない (SHALL)。
• 承認された乱数生成器を使用して生成された、少なくとも 64 bit のエントロピーを含まねばならない (SHALL)。
• ユーザーのログアウト時に、セッション主体によって消去または無効にされなければならない (SHALL)。
• ユーザーがログアウトするとき、またはシークレットの期限が切れたとみなされるとき、ユーザー エンドポイントから消去されなければならない (SHOULD)。
• クロスサイトスクリプティング攻撃 (XSS) によるローカルストレージの暴露の可能性のため、HTML5 のローカル ストレージなど、安全でない場所に配置すべきでない (SHOULD NOT)。
• 認証済みの保護されたチャネルを使用してデバイスから送信、または受信されなければならない (SHALL)。
• セクション 4.1.4、4.2.4、4.3.4 (AAL) によって指定された時間のあとは、タイムアウトしなければならず、受け付けられてはならない (SHALL)。

セッションオーバータイムを管理するための複数の異なるメカニズムがある。 次のセクションは、追加要件と特定の各テクノロジーの考慮事項に沿って、3 つの例を示す。

7.1.1. ブラウザー クッキー

ブラウザー クッキーは、サービスにアクセスするユーザーのセッションの作成と追跡において、有力なメカニズムである。

クッキー:

• セキュリティで保護された (HTTPS) セッションのみでアクセス可能なようにタグ付けされなければならない (SHALL)。
• ホスト名とパスの最小で実用的なセットにアクセス可能でなければならない (SHALL)。
• JavaScriptからアクセス不可 (HttpOnly) となるようにタグ付けされなければならない (SHOULD)。
• セッションの有効期間の後は、すぐに満了としてタグ付けされなければならない (SHOULD)。(この要件はクッキーの蓄積を制限することを目的としている。セッションタイムアウトの適用に依存すべきではない (SHALL NOT)。)

7.1.2. OAuth トークン

OAuth アクセス トークンは、認証イベントののち、ユーザに代わってアプリケーションが一連のサービスへアクセスすることを許可するために使用される。 OAuth アクセス トークンの存在は、他のシグナルがない場合、ユーザーの存在を示す RP によって解釈されてはならない (SHALL NOT)。 OAuth アクセス トークン (および関連付けられたリフレッシュ トークン) は、認証セッションが終了し、ユーザーがそのアプリケーションから去ったあとでも、有効であってもよい (MAY)。

7.1.3. デバイス識別

ユーザーとサービス間のセッションの制定には、相互 TLSやトークンのバインディングなど、安全なデバイスの識別についての様々な方法を使用する。

7.2. 再認証

セッションは、ガイドラインのセクション4.1.4, 4.2.4, and 4.3.4 (AALに依存する) に基づき、セッション シークレットの提示のみで過去へも延長されることはない (SHALL NOT)。

タイムアウトまたは他のアクションによってセッションが終了されるとき、ユーザーはプライマリの認証メカニズム、または AAL に従った適切なサブセットを使用して再認証をしてもよい (MAY)。

AAL	Requirement
1	任意の 1 つのファクターの提示
2	任意の 1 つのファクターの提示
3	全てのファクターの提示

7.2.1 フェデレーションまたはアサーションからの再認証

フェデレーション プロトコル を使用してCSP と RP を接続するときは、セッション管理と再認証のために、特別な考慮が必要である。 CSP と RP のどちらもが、 おそらく個別のセッション管理を採用し、これらのセッション間にはどんな相関の仮定もない (SHALL NOT)。 その結果として、RP においてセッションが満了し、RPによって再認証が必要なとき、CSPにおいてセッションが満了しておらず、ユーザーを再認証することなく CSP でこのセッションから新しいアサーションを生成することができる可能性は十分にあり得る。 したがって、フェデレーション プロトコルを介して再認証を必要とする RP は (当該プロトコルでサポートされていれば) 最小の acceptable authentication age を CSP に示すこととする (SHALL)。CSPは (可能なら) この要求に答えるものとする (SHALL)。 すべてのケースで CSP は、アサーションが再認証のために十分であるかどうかを RP が決められるように、プライマリ認証イベントの時刻を RP へ伝達しなければならない (SHALL)。

8. 脅威とセキュリティに関する考慮事項

このセクションは non-normative である。

8.1. Authenticator に対する脅威

Authenticator を制御できる攻撃者は Authenticator の所有者のように偽装することができる。 認証システムを構成する認証ファクターの種類ごとの攻撃に基づいて Authenticator への脅威を分類できる。

• Something you have は紛失、破損、所有者から盗難される、または攻撃者によって複製されることがある。 たとえば、所有者のコンピューターへのアクセスを取得した攻撃者は、ソフトウェアの Authenticator をコピーするかもしれない。 ハードウェアの Authenticator は、盗難されたり、いじられたり、複製されるかもしれない。

• Something you know は攻撃者に開示されることがある。 攻撃者は、記憶の中のシークレットを推測するかもしれない。 Authenticator が共有シークレットである場合、攻撃者は CSP または検証者へのアクセス権を得てシークレットの値を入手する、または、その値のハッシュに対して辞書アタックを行うかもしれない。 攻撃者は、PIN やパスコードの入力を観察したり、書き写された記録やジャーナル見つけたり、またはシークレットをキャプチャーするために不正なソフトウェア (例：キーボードロガー) をインストールしたりするかもしれない。 さらに、攻撃者は、検証者によってメンテナンスされているハッシュされたパスワード データベースに対するオフライン攻撃からシークレットを特定するかもしれない。

• Something you are は複製されるかもしれない。 攻撃者は、認証されるべき者 (サブスクライバー) の指紋のコピーを取得し、レプリカを作成するかもしれない (堅牢な生体検知技術によってこのような攻撃を検知しない生体認証システムが採用されていることを前提として) 。

• Out of band のシークレットは傍受されるかもしれない。 攻撃者は、プライマリまたはセカンダリの通信チャネルで、盗聴によってチャレンジまたはレスポンスを受信するかもしれない。 攻撃者は、独自のチャネルを認証させたり、後でリプレイするためにメッセージを保存したりするかもしれない。

このドキュメントは、サブスクライバーが検証者に対して虚偽の認証を行おうとしている攻撃者と共謀してないことを前提としている。 この前提に立って、電子認証用の Authenticator への脅威は Table 8-1 について、いくつかの例とともにリストする。

Authenticator に対する脅威/攻撃	説明	例
盗難	物理的な Authenticator が攻撃者によって盗まれる。	ハードウェア暗号化デバイスが盗まれる。
		ワンタイム パスワード デバイスが盗まれる。
		look-up secret authenticator が盗まれる。
		携帯電話が盗まれる。
複製	サブスクライバーの Authenticator が、本人の知識なしに複製される。	パスワードが書かれた紙が開示される。
		電子ファイルに格納されているパスワードがコピーされる。
		Software PKI authenticator (private key) がコピーされる。
		look-up secret authenticator がコピーされる。
盗聴	サブスクライバーが認証を行ったときに、 Authenticator シークレットまたは Authenticator の出力が攻撃者に暴露される。	キーボードエントリーを監視して記憶されたシークレットを取得する。
		キーストロークをロギングするソフトウェアによって、記憶されたシークレットまたは Authenticator の出力を横取りする。
		PIN パッド デバイスからPINをキャプチャする。
		ハッシュ化されたパスワードが攻撃者の手に渡り, それを他の認証に使われる。(pass-the-hash attack)
	Out of band シークレットが、通信チャネルの危殆化によって攻撃者に横取りされる。	Out of band シークレットが暗号化されていないWi-Fiで送信され、攻撃者に受信される。
オフライン クラッキング	Authenticator が、認証メカニズムの外で、解析メソッドによって明らかにされる。	Software PKI authenticator が、秘密鍵の復号に使用する正しいパスワードを識別するために辞書攻撃を受ける。
サイドチャネル攻撃	Authenticator シークレットが、 Authenticator の物理的特性によって明らかにされる。	キーが hardware cryptographic authenticator の差分電力解析によって明らかにされる。
		無数の試行の応答時間の解析によって、 cryptographic authenticator secret が抽出される。
フィッシングやファーミング	攻撃者が検証者や RP であるようにサブスクライバーをだまし、Authenticator の出力をキャプチャする。	サブスクライバーが検証者を偽装した web サイトに入力することで、パスワードが明らかにされる。
		記憶されたシークレットが、銀行からの問い合わせに見せかけたメールに返信することで明らかにされる。
		サブスクライバーがDNS スプーフィングを介して偽の検証者 Webサイトにアクセスしてしまうことで、記憶されたシークレットが明らかにされる。
ソーシャルエンジニア リング	攻撃者が、サブスクライバーとの間に願いに応じるだけの信頼関係を構築し、サブスクライバー自身が Authenticator シークレット、または Authenticator の出力を明らかにする。	サブスクライバーが、サブスクライバーの上司に代わってパスワードを聞いてきた同僚に対して記憶されたシークレットを明らかにする。
		記憶されたシークレットが、システム管理者を装った攻撃者からの電話によって明らかにされる。
		攻撃者が被害者の携帯電話を攻撃者にリダイレクトするようにモバイルオペレーターを信じさせることで、SMS経由のOut of band シークレットが攻撃者に受信される。
オンラインでの推測	攻撃者が、検証者にオンラインで接続し、その検証のコンテキストで有効な Authenticator の出力を推測しようと試行する。	オンライン辞書攻撃によって、記憶されたシークレットを推測する。
		オンラインでの推測によって、正当な要求者に登録されたワンタイム パスワード デバイスとしての Authenticator の出力が推測される。
エンドポイントの危殆化	エンドポイント上の不正なコードがユーザー同意なしの Authenticator へのリモートアクセス接続をプロキシする。	エンドポイントに接続された暗号化 Authenticator が、リモートから攻撃者の認証に利用される。
	エンドポイント上の不正なコードが、検証者が意図していない認証の原因となる。	サブスクライバーではなく攻撃者に代わって認証が行われる。
		エンドポイント上の不正なアプリが SMS 経由で送信された Out of band シークレットを読みだし、攻撃者がシークレットを認証に使用する。
	エンドポイント上の不正なコードが、 multi-factor software cryptographic authenticator を危殆化させる。	不正なコードが認証をプロキシする、またはエンドポイントから Authenticator 鍵をエクスポートする。

8.2. 脅威を軽減するストラテジー

Table 8-2 は、上記で説明された脅威の軽減を支援するメカニズムをまとめたものである。

Authenticator に対する脅威/攻撃	脅威を軽減するメカニズム
盗難	記憶されたシークレットまたは生体認証をアクティブにするときには、多要素認証を使用する。
複製	認証シークレットの複製や抽出が長期的に困難な Authenticator を使用する。
盗聴	特にキーロガーなどのマルウェアに感染していないか、使用する前にエンドポイントがセキュリティを確保できているか確かめる。
	記憶されたシークレットやワンタイムパスワードを入力するときは、他の人がそれを観察できない環境であるか、常に気を配る。
	認証され、保護されたチャネル経由で認証を行う。 (たとえば、ブラウザーウィンドウにあるロック アイコンを確認する。)
	pass-the-hash のようなリプレイ攻撃に耐性のある認証プロトコルを使用する。
オフライン クラッキング	高エントロピーの Authenticator シークレットを使用する。
	辞書攻撃のコストを高めるために、記憶されたシークレットをソルトを用いたハッシュ形式で保存する。鍵付きハッシュを使用する。
サイドチャネル攻撃	シークレットの値に関係なく消費電力とタイミングが一定に保たれるように設計された Authenticator アルゴリズムを使用する。
フィッシングやファーミング	なりすましの検証を行うことができる Authenticator を使用する。
	意図しないホストネームがURLの中にあれば警告する。
	電子メールメッセージ内のリンクをクリックしない。代わりに、URLを手動で入力するか、信頼するブックマークからアクセスする。
ソーシャルエンジニア リング	誰に何を言われても、他人に対して認証シークレットを明らかにしない。
	カスタマーサービスエージェントなどの第三者によるソーシャルエンジニアリングの危険性がある Authenticator の使用を避ける。
オンラインでの推測	高エントロピーの出力を生成する Authenticator を使用する。
	アクティベーションの試行に繰り返し失敗した後は Authenticator をロックアップする。
エンドポイントの危殆化	サブスクライバーの物理的なアクションを必要とするハードウェア Authenticator を使用する。
	検証者と RP のセキュリティで保護された ID 表示を提供する。
	ソフトウェアベースの鍵はアクセス制限つきストレージで管理する。

他にも、表 5 に記載されている脅威を軽減するために適用できるいくつかのストラテジーがある。

• 複数の要素 があると、攻撃が成功しにくくなる。 もし攻撃者が cryptographic authenticator を盗むことと記憶されたシークレットの推定の両方を必要とするなら、その両方を達成することはとても困難になり得る。

• 物理的なセキュリティメカニズム は複製による Authenticator の盗難を防ぐために採用されることがある。物理的なセキュリティメカニズムは、耐タンパー性の確保、検出、および対応を可能にする。

• 共有されている辞書に現れない 長い 記憶されたシークレット の使用を要求する ことは、攻撃者にすべての入力可能な値を試させる。

• システムとネットワークのセキュリティコントロール は、攻撃者がシステムへのアクセスを得ることや、不正なソフトウェアのインストールを防ぐために用いられる。

• 定期的なトレーニング を行うことで、いつ、どのように危殆化 (または危殆化の疑い) を報告するか、サブスクライバーの理解を促す。または、振る舞いのパターンを認識することで、攻撃者の認証プロセスを破るための試行であることを知る。

• Out of band テクニック は、登録されたデバイス (例: 携帯電話) を所有していることの検証に使用される。

8.3. Authenticator の復旧

多くの認証メカニズムの弱点は、サブスクライバーが 1 つまたは複数の Authenticator のコントロールを失い、それらを交換する必要がある場合の手続きである。 多くの場合、サブスクライバーを認証できる残りの選択肢は限られている。経済的な心配 (コールセンター運営のコストなど) から、安価であったり、あまりセキュアでないものや、バックアップの認証方法を使用したいと考えさせる。 Authenticator の復旧は、人の手を借りるという点で、ソーシャルエンジニア リング攻撃の危険性がある。

認証要素の完全性を維持するためには、 1 つの要素によって異なる要素の Authenticator を取得するなど、不正に活用できないことが必要不可欠である。 たとえば、記憶されたシークレットは新しい look-up secret のリストに含まれていない必要がある。

9. Privacy Considerations

These privacy considerations supplement the guidance in section 4. This section is informative.

9.1. Privacy Risk Assessment

Subsections 4.1.6, 4.2.6 and 4.3.6 require the CSP to conduct a privacy risk assessment for records retention. Such a privacy risk assessment would include:

1. The likelihood that the records retention could create a problem for the subscriber such as invasiveness or unauthorized access to the information
2. The impact if a problem did occur

CSPs should be able to reasonably justify any response they take to identified privacy risks, including accepting the risk, mitigating the risk; and sharing the risk. The use of subscriber consent is a form of sharing the risk, and therefore appropriate for use only when a subscriber could reasonably be expected to have the capacity to assess and accept the shared risk.

9.2. Privacy Controls

Section 4.4 encourages CSPs to employ appropriately tailored privacy controls. NIST [SP 800-53] provides a set of privacy controls for CSPs to consider when deploying authentication mechanisms. These controls cover notices, redress and other important considerations for successful and trustworthy deployments.

9.3. Use Limitation

Section 4.4 does not permit the CSP to use information about authenticators that is collected and maintained in the authentication process for any purpose other than authentication or to comply with law or legal process, unless the CSP provides clear notice and obtains consent from the subscriber for additional uses. Care should be taken to ensure that use of such information is limited to its original purpose for collection. Consult your Senior Agency Official for Privacy (SAOP) if there are questions about whether proposed agency uses fall within this scope. As stated in Section 4.4, acceptance by the subscriber of additional uses SHALL NOT be a condition of providing authentication services.

9.4. Agency Specific Privacy Compliance

Section 4.4 covers specific compliance obligations for federal CSPs. It is critical to involve your agency’s SAOP in the earliest stages of digital authentication system development to assess and mitigate privacy risks and advise the agency on compliance requirements, such as whether or not the collection of Personally Identifiable Information (PII) to issue or maintain authenticators triggers the Privacy Act of 1974 [Privacy Act] or the E-Government Act of 2002 [E-Gov] requirement to conduct a Privacy Impact Assessment (PIA). For example, with respect to centralized maintenance of biometrics, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records due to the collection and maintenance of attributes/PII necessary for authentication. The SAOP can similarly assist the agency in determining whether a PIA is required.

These considerations should not be read as a requirement to develop a Privacy Act System of Records Notice (SORN) or PIA for authentication alone; in many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital authentication process or include the digital authentication process as part of a larger programmatic PIA that discusses the program or benefit the agency is establishing online access to.

Due to the many components of digital authentication, it is important for the SAOP to have an awareness and understanding of each individual component so as to advise appropriately on what compliance requirements apply. Moreover, a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means.

10. Usability Considerations

This section is informative.

ISO/IEC 9241-11 defines usability as: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. This definition focuses on users, goals, and context of use as key elements necessary for achieving effectiveness, efficiency and satisfaction. A holistic approach considering these key elements is necessary to achieve usability.

Users’ goals for accessing an information system are to perform their intended tasks. Authentication is not a user’s primary task, but an enabling task standing between the users and their goals. Authentication should be designed and implemented to make it easy for users to do the right thing, hard to do the wrong thing, and easy to recover when something goes wrong.

Organizations must be cognizant of the overall implications of their stakeholders entire digital authentication ecosystem. Many times, users employ one or more authenticators, each for different RPs. Users struggle to remember passwords, to carry multiple authentication devices, and to remember which authenticator goes with which RP. It is critical to evaluate the usability of authentication, since poor usability often results in user coping mechanisms and unintended user work-arounds, which can ultimately degrade the intended security controls.

In order to address users’ authentication needs and organizations’ security goals, organizations should assess the impact of usability across their digital systems, as part of the risk assessment when deciding on the Authenticator Assurance Level (AAL) requirements. If authenticators with a higher AAL offer better usability, users should be allowed to use them for lower AAL applications. For example, rather than forcing users to manage many passwords, allow users to use their favorite authenticator across the organization’s applications. Users should be able to choose their authenticator, and in some instances, may choose to only have to manage one authenticator for their digital authentication needs. For example, this may be achieved by adopting identity federation (see NIST SP 800-63C, Federation and Assertions). For the selection of an authenticator, only by considering the combination of users, their goals, and context of use with the authenticator and the security risk assessment can usability and security be achieved in tandem. The current section takes this holistic view in applying usability principles to authenticators across their lifecycle.

ASSUMPTIONS

In this section, the term “users” means “Claimants” or “Subscribers.” This section describes guidelines and considerations from the end-users’ perspective, as usability guidelines can only be written from the end-users’ perspective.

Accessibility and usability differ significantly; therefore, accessibility is out of scope for this section. However, organizations should obviously address accessibility in their implementation plans.

10.1. Usability Considerations by Authenticator Type

For the selection and implementation of an authentication system, usability should be considered across the entire lifecycle of the selected authenticator(s): enrollment and distribution, typical use, and intermittent events, being mindful of the combination of users, users’ goals, and context of use. This section discusses the usability considerations of authenticators for their typical use and intermittent events, with the goal of raising implementers’ awareness of usability considerations associated with authenticators, and possible implementation options to enhance usability.

In general, a single authenticator option will likely not suffice for the entire population of users. Therefore, whenever possible (depending on the AAL requirements), implementers should provide alternative authenticator types to users and allow users to choose between them depending on their needs. For example, the immediacy of the user’s task, a cost benefit analysis, or unfamiliarity with certain types of authenticators will affect the user’s choice of authenticator. Users generally choose options that incur the least burden or cost at that moment in time. For example, if a user’s task requires immediate access to an information system, a user may prefer to create a new user account and password rather than selecting an authenticator requiring more steps for access to the information system. Alternatively, users may choose to use a federated identity option (approved at the appropriate AAL) if they already have an account with an identity provider. Users may understand some authenticators better than others, and have different levels of trust based on their understanding.

This section focuses on general usability considerations and possible implementations, rather than recommending specific implementation solutions. The possible implementations are provided as examples in order to encourage innovative technological approaches to address specific usability needs. Furthermore, usability considerations and their associated implementation solutions are sensitive to many factors, including context of use; these dependencies prevent a one-size-fits-all solution. For example, in the desktop computing environment, a minimum font size of 12 points may generally work for displaying user facing text, but the same font size of 12 points may force text to scroll off of a small OTP device screen, making it unusable. This is why performing a usability evaluation on the selected authenticator is a critical component of authenticator implementation; evaluations must be conducted with representative users, realistic goals and tasks, and appropriate contexts of use.

Positive user authentication experience is integral to the success of an organizations’ security posture. Therefore, implementers should strive to consider authenticators from the users’ points of view. The overarching goal of usability for authentication is to minimize the authentication burden on users, and to minimize authentication friction (the number of times a user has to authenticate and the steps involved in that authentication, and the amount of information they have to keep track of). For example, one such minimization strategy may be single sign-on (SSO).

10.1.1. Summary of Usability Considerations

Table 10-1 summarizes the usability considerations for typical usage and intermittent events for each of the eight authenticators. The sections following the table provide more detailed discussion on each authenticator. Many of the usability considerations for typical usage apply to the majority of the authenticator types, evidenced by examining the rows. The table highlights common and divergent usability characteristics across the authenticator types. Each column allows readers to easily identify the usability attributes that must be addressed for each authenticator. Depending on users’ goals and the context of use, users may value certain usability attributes more than others. Whenever possible, provide alternative authenticator types to users and allow users to choose between them. It is important to note that multi-factor authenticators (i.e., multi-factor OTP devices, multi-factor cryptographic software, and multi-factor cryptographic devices) also inherit usability considerations of their secondary factor. Since biometrics is only allowed as an activation factor in multi-factor authentication solutions, usability considerations for biometrics are not included in Table 10-1 and are discussed in section 10.2.

10.1.2. Memorized Secret

Typical Usage

Users manually input the memorized secret (commonly referred to as a password or PIN).

Usability considerations for typical usage include:

• Availability of the memorized secret.
  • Users must remember or have their memorized secret readily available. The more items users must remember, the more memory interference will occur, and the greater likelihood of recall failure. For less frequently used passwords, these memory burdens are magnified. Having fewer memorized secrets makes it easier for users to recall the specific memorized secret needed for that particular RP.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues, for example, when users cannot recall their memorized secrets.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of user facing text or text entered by users should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for displaying unmasked secrets.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
    • If possible depending on the size of the device, a minimum font size of 12 points is recommended as long as the text fits for display on the device.
• User experience during entry of memorized secrets.
  • Fields for entry of memorized secrets should support copy and paste functionality. Entry fields should support memorized secrets of at least 64 characters in length; this allows the use of passphrases if desired.
  • An option to display the memorized secret during entry should be offered to the user. Masked text entry is error-prone since users cannot see what they are typing. After the character is displayed for a time sufficient for the user to see the character, then the character can be hidden. It will take longer for users to enter memorized secrets on mobile devices (such as tablets and smartphones) than on traditional desktop computers. Therefore, the masking delay time should take into consideration the device on which the user is entering their memorized secrets.
  • Time allowed for entry of memorized secrets should be adequate to enter the secret, i.e., the entry screen does not time out prematurely.
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration. Significant usability implications will arise when users do not know that they have entered their memorized secret incorrectly, preventing users from accomplishing their tasks. However, care should be taken to not provide so much detail that an attacker can glean information rendering the memorized secret vulnerable.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the memorized secrets, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.

Depending on the implementation, form-factor constraints should be considered, as they are particularly problematic if users must enter their memorized secrets on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard). Providing larger touch areas will improve usability for entering memorized secrets on mobile devices.

Intermittent Events

Intermittent events with memorized secrets include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded; expired memorized secrets; and revocation. Additionally, users may proactively change their memorized secret.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur. This is particularly important when memorized secrets are used as a second factor at AAL 3 where reauthentication is required at 15 minutes of user inactivity.
• When memorized secrets are used at AAL 2 or AAL 3, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions to create and change memorized secrets.
  • Information on how to create and change memorized secrets should be clearly communicated to users.
  • Simplify memorized secret policies by implementing technical defenses, including implementing approved encryption, storing memorized secrets in a form that is resistant to offline attacks, and using blacklists. (see Section 5.1.1 for details).
    • Memorized secret requirements such as minimum length should be clearly communicated to users. Memorized secrets SHALL be at least 8 characters in length as specified in Section 5.1.1.
    • Users should be encouraged to make their memorized secrets as lengthy as they want, and using any characters they like, including spaces. This will allow users to create passphrases to aid memorization. Users should be allowed at least 64 characters in length to support the use of passphrases if desired.
    • No other composition rules (complexity rules) should be imposed (mixtures of different character types, for example) on memorized secrets.
    • Memorized secrets should not be required to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a user requests a change. (Section 5.1.1)
  • When creating memorized secrets, users should not be asked to provide specific types of information (e.g., “What is your favorite food?”, or “What was the name of your first pet?”). These types of questions are difficult for users to remember, especially because information such as personal preferences can change over time.
  • Users should be given clear, meaningful and actionable feedback when chosen passwords are rejected by online services. For example, when a password is rejected because it appears on a “black list” of unacceptable passwords or has been used previously used. The user should be advised that they need to select a different secret because their previous choice was commonly used.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.3. Look-up Secrets

Typical Usage

Users use the authenticator (physical or electronic record) to look up the appropriate secret(s) needed to respond to a prompt from the verifier. For example, a user may be asked by the verifier to provide a specific subset of the numeric or character strings printed on a card in table format.

Usability considerations for typical usage include:

• Availability of the look-up secret authenticator.
  • Users must have their look-up secret authenticators readily in possession when the prompt is delivered.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with look-up secrets.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of text for displaying both prompts and look-up secrets should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for electronic look-up secrets; serif fonts are recommended for physical look-up secrets.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• User experience during entry of look-up secrets.
  • The complexity and size of the prompts should be considered. The larger the subset of secrets a user is prompted to look up, the greater the usability implications are, both the cognitive workload and physical difficulty during entry.
  • Entry of look-up secrets should not be masked. Masked text entry is error-prone since users cannot see what they are typing. For unmasked text entry of look-up secrets, the legibility considerations for prompts and look-up secrets described above also apply.
  • Time allowed for entry of look-up secrets should be commensurate with the length and complexity of the look-up secrets, i.e., the entry screen does not time out prematurely.
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the look-up secrets, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Form-factor constraints should be considered if users must enter their look-up secrets on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard). Providing larger touch areas will improve usability for entering look up secrets on mobile devices.

Intermittent Events

Intermittent events with look-up secrets include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded; damaged, lost, or stolen look-up secret authenticator; expired look-up secrets; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur.
• When look-up secrets are used at AAL 2, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.4. Out of Band

Typical Usage

Out of band authentication requires that users have access to a primary and secondary communication channel. Users present the one-time authentication secret (i.e., the out of band secret) received on the secondary channel to the verifier using the primary channel for authentication.

Usability considerations for typical usage include:

• Availability of the out of band device.
  • Users must have their out of band device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with out of band devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of text for displaying the authentication secret should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for the authentication secret.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• User experience during entry of authentication secret.
  • Entry of the authentication secret should not be masked. Masked text entry is error-prone since users cannot see what they are typing. For unmasked text entry of authenticator output, the legibility considerations described above also apply.
  • Time allowed for entry of the authentication secret should be commensurate with the length and complexity of the authentication secret, i.e., the entry screen does not time out prematurely.
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the authentication secret, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Users should be notified of the receipt of an authentication secret on a locked device. However, if the out of band device is locked by a user, the user will need to authenticate to the device to access the authentication secret (since the authentication secret cannot be displayed on a locked device screen).
  • Form-factor constraints should be considered if users must enter their authentication secrets on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard). Providing larger touch areas will improve usability for entering authentication secrets on mobile devices.
    • A better usability option is to offer users features that do not require text entry on mobile devices, for example, a single tap on the screen, or a copy feature so users can copy and paste the out of band secrets.
• Providing users such features will be particularly helpful in scenarios where the primary and secondary channels are on the same device. For example, on a smartphone, it is difficult for users to transfer the authentication secret because users must switch back and forth — potentially multiple times —between the out of band application and the primary channel.

Intermittent Events

Intermittent events with out of band devices include, but are not limited to, reauthentication; account lock-out; throttling; authentication secret not received; number of allowed attempts exceeded; damaged, lost, or stolen out of band devices; and revocation. Additionally, users often proactively change or upgrade their mobile devices, which would necessitate updating the linkage between the primary and secondary channels.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur.
• When out of band is used at AAL 2, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.5. Single Factor OTP Device

Typical Usage

Users access the authenticator output (i.e., one-time password) generated by the single-factor OTP device. The authenticator output is typically displayed on the device and manually input by the user to the verifier, although direct electronic output from the device as input to a computer is also allowed.

Usability considerations for typical usage include:

• Availability of the single-factor OTP device.
  • Users must have their single-factor OTP device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with single-factor OTP devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of text for displaying authenticator output should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• User experience during manual entry of authenticator output.
  • Entry of authenticator output should not be masked. Masked text entry is error-prone since users cannot see what they are typing. For unmasked text entry of authenticator output, the legibility considerations described above also apply.
  • Time allowed for entry of authenticator output should be commensurate with the length and complexity of the authenticator output, i.e., the entry screen does not time out prematurely.
    • Authenticator output should allow at least one minute between changes, but ideally allow users the full 2 minutes as specified in the requirement that the nonce be changed at least once every 2 minutes. Users need adequate time to enter the authenticator output (including looking back and forth between the single-factor OTP device and the entry screen).
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the authenticator output, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Form-factor constraints should be considered if users must enter the authenticator output on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard). Providing larger touch areas will improve usability for entering the authenticator output on mobile devices.
  • If the single-factor OTP device supplies its output via an electronic interface such as USB, this is preferable since users do not have to manually enter the authenticator output. However, if a physical input (such as pressing a button) is required to operate, the location of the USB ports could pose usability difficulties. For example, the USB ports of some computers are located on the back of the computer that will be difficult for users to reach.
    • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited which may force users to unplug other USB peripherals in order to use the single-factor OTP device.

Intermittent Events

Intermittent events with single-factor OTP devices include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded; damaged, lost, or stolen single-factor OTP devices; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur.
• When single-factor OTP devices are used at AAL 2, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.6. Multi-Factor OTP Device

Typical Usage

Users access the authenticator output (i.e., one-time password) generated by the multi-factor OTP device that requires activation through a second authentication factor. The authenticator output is typically displayed on the device and manually input by the user to the verifier, although direct electronic output from the device as input to a computer is also allowed. The second factor of authentication may be achieved through some kind of integral entry pad to enter a memorized secret, an integral biometric (e.g., fingerprint) reader or a direct computer interface (e.g., USB port). Usability considerations for the additional factor apply as well (see section 10.1.2 for Memorized Secrets and section 10.2 for Biometrics used in Multi-Factor Authenticators).

Usability considerations for typical usage include:

• Availability of the multi-factor OTP device.
  • Users must have their multi-factor OTP device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with multi-factor OTP devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of text for displaying authenticator output should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• User experience during manual entry of authenticator output.
  • Entry of authenticator output should not be masked. Masked text entry is error-prone since users cannot see what they are typing. For unmasked text entry of authenticator output, the legibility considerations described above also apply.
  • Time allowed for entry of authenticator output should be commensurate with the length and complexity of the authenticator output, i.e., the entry screen does not time out prematurely.
    • Authenticator output should allow at least one minute between changes, but ideally allow users the full 2 minutes as specified in the requirement that the nonce be changed at least once every 2 minutes. Users need adequate time to enter the authenticator output (including looking back and forth between the multi-factor OTP device and the entry screen).
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the authenticator output, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Form-factor constraints should be considered if users must unlock the multi-factor OTP device via an integral entry pad; and/or if users must enter the authenticator output on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the integral entry pad and the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the integral entry pad and the onscreen keyboard). Providing larger touch areas will improve usability for unlocking the multi-factor OTP device or entering the authenticator output on mobile devices.
  • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited which may force users to unplug other USB peripherals in order to use the multi-factor OTP device.

Intermittent Events

Intermittent events with multi-factor OTP devices include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded (for either factor); damaged, lost, or stolen multi-factor OTP devices; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur. This is particularly important when multi-factor OTP devices are used at AAL 3 where reauthentication is required at 15 minutes of user inactivity.
• When multi-factor OTP devices are used at AAL 2 or AAL 3, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.7. Single Factor Cryptographic Device

Typical Usage Users prove possession of the single-factor cryptographic device in order to authenticate.

Usability considerations for typical usage include:

• Availability of the single-factor cryptographic device.
  • Users must have their single-factor cryptographic device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with single-factor cryptographic devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Text legibility should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • If a physical input (such as pressing a button) is required to operate the single-factor cryptographic device, this could pose usability difficulties. For example, the USB ports of some computers are located on the back of the computer that will be difficult for users to reach.
    • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited which may force users to unplug other USB peripherals in order to use the single-factor cryptographic device.

Intermittent Events

Intermittent events with single-factor cryptographic devices include, but are not limited to, reauthentication; damaged, lost, or stolen single-factor cryptographic devices; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur. This is particularly important when single-factor cryptographic devices are used as part of a multi-factor solution at AAL 3 where reauthentication is required at 15 minutes of user inactivity.
• When single-factor cryptographic devices are used at AAL 2 or AAL 3, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.8. Multi-Factor Cryptographic Software

Typical Usage

In order to authenticate, users prove possession and control of the cryptographic key stored on disk or some other “soft” media that requires activation. The activation is through the input of a second authentication factor, either a memorized secret or a biometric; usability considerations for the additional factor apply as well (see section 10.1.2 for Memorized Secrets and section 10.2 for Biometrics used in Multi-Factor Authenticators).

Usability considerations for typical usage include:

• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Text legibility should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • All cryptographic keys should be given appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users being faced with multiple similarly and ambiguously named cryptographic keys. Selection among multiple cryptographic keys on smaller mobile devices (such as smartphones) may be particularly problematic if the names of the cryptographic keys are shortened due to reduced screen size.
  • Form-factor constraints should be considered if users must unlock the multi-factor cryptographic software on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard).

Intermittent Events

Intermittent events with multi-factor cryptographic software include, but are not limited to, reauthentication; account lock-out; number of allowed attempts exceeded ; non-functional multi-factor cryptographic software; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur.
• When multi-factor cryptographic software is used at AAL 2, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.9. Multi-Factor Cryptographic Device

Typical Usage

In order to authenticate, users prove possession of the multi-factor cryptographic device and control of the protected cryptographic key. The device is activated by a second authentication factor, either a memorized secret or a biometric; usability considerations for the additional factor apply as well (see section 10.1.2 for Memorized Secrets and section 10.2 for Biometrics used in Multi-Factor Authenticators).

Usability considerations for typical usage include:

• Availability of the multi-factor cryptographic device.
  • Users must have their multi-factor cryptographic device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with multi-factor cryptographic devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Text legibility should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Ideally, the multi-factor cryptographic devices should not require a hardware connection to use. However, if using a hardware connection, the multi-factor cryptographic device should not require users to keep the device connected. Users may forget to disconnect the multi-factor cryptographic device when they are done with it (such as forgetting a smartcard in the smartcard reader and walking away from the computer).
    • Users need to be informed regarding whether the multi-factor cryptographic device is required to stay connected or not.
  • All cryptographic keys should be given appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users being faced with multiple similarly and ambiguously named cryptographic keys. Selection among multiple cryptographic keys on smaller mobile devices (such as smartphones) may be particularly problematic if the names of the cryptographic keys are shortened due to reduced screen size.
  • Form-factor constraints should be considered if users must unlock the multi-factor cryptographic device via an integral entry pad. Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the integral entry pad, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the integral entry pad). Providing larger touch areas will improve usability for unlocking the multi-factor cryptographic device.
  • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited which may force users to unplug other USB peripherals in order to use the multi-factor cryptographic device.

Intermittent Events

Intermittent events with multi-factor cryptographic devices include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded; damaged, lost, or stolen multi-factor cryptographic devices; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur. This is particularly important when multi-factor cryptographic devices are used at AAL 3 where reauthentication is required at 15 minutes of user inactivity.
• When multi-factor cryptographic devices are used at AAL 2 or AAL 3, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.2. Usability Considerations of Biometrics

For multi-factor authenticators, biometrics can be used as an additional factor. Therefore, in contrast to the previous usability considerations for authenticator types, this section provides only a high-level overview of general usability considerations for biometrics. For a more detailed discussion of biometric usability, see Usability & Biometrics, Ensuring Successful Biometric Systems, http://www.nist.gov/customcf/get_pdf.cfm?pub_id=152184.

Although there are additional biometric modalities, the following three biometric modalities are more commonly used for authentication: fingerprint, face and iris.

Typical Usage

• For all modalities, user familiarity and practice with the device improves performance.
• Device affordances (properties of an object that allow a user to perform an action), feedback, and clear instructions are critical factors to a user’s success with the biometric device. For example, clear instructions describing user actions required for liveness detection should be provided to users.
• Ideally, users should be given the choice to select the modality with which they are most comfortable for their second authentication factor. The user population may be more comfortable with and accepting of some biometric modalities than others. For example, the use of iris technology is not as widely accepted or used as are fingerprints and face.
• User experience with biometrics as an activation factor.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Fingerprint Usability Considerations:
  • Users must remember which finger(s) they used for initial enrollment.
  • The amount of moisture on the finger(s) affects the sensor’s ability for successful capture.
  • Additional factors also influence fingerprint capture quality, including age, gender, and occupation (e.g., users handling chemicals or who work extensively with their hands may have degraded friction ridges).
• Face Usability Considerations:
  • Users must remember whether they wore any artifacts, such as glasses, during enrollment because it affects facial recognition accuracy.
  • Differences in environmental lighting conditions can affect facial recognition accuracy.
  • Facial poses affect facial recognition accuracy (e.g., smiling versus neutral expression).
• Iris Usability Considerations:
  • Users wearing colored contacts have the potential to affect the iris recognition accuracy.
  • Users who have had eye surgery may need to re-enroll post-surgery.
  • Differences in environmental lighting conditions can affect iris recognition accuracy, especially for certain iris colors.

Intermittent Events

Since biometrics are only permitted as a second factor in a multi-factor authentication scenario, usability considerations for intermittent events with the primary factor still apply. Intermittent events with the use of biometrics include, but are not limited to, the following that may affect recognition accuracy:

• If a user injures his/her enrolled finger(s), fingerprint recognition may not work. Fingerprint authentication will be difficult for users with degraded fingerprints.
• The time elapsed between the time of facial recognition for authentication and the time of the initial enrollment can affect the recognition accuracy as a user’s face changes naturally over time. A user’s weight changes (e.g., weight gain or loss) may also be a factor.
• Iris recognition may not work for people who have had eye surgery unless they re-enroll.

Across all biometric modalities, usability considerations for intermittent events include:

• For all modalities, an alternative authentication method must be available and functioning. In cases where biometrics do not work, users must be allowed to use a memorized secret as an alternative second factor.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.
  • Users need to be informed regarding factors that may affect the sensitivity of the biometric sensor (e.g., cleanliness of the sensor).

11. References

To be completed

11.1. General References

[OMB M-03-22] OMB Memorandum M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002, September 26, 2003, available at: http://www.whitehouse.gov/omb/memoranda/m03-22.html.

[M-04-04] OMB Memorandum M-04-04, E-Authentication Guidance for Federal Agencies, December 16, 2003, available at: https://www.whitehouse.gov/sites/default/files/omb/memoranda/fy04/m04-04.pdf.

[RFC 20] Cerf, V., ASCII format for network interchange, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, http://www.rfc-editor.org/info/rfc20.

[RFC 5246] IETF, The Transport Layer Security (TLS) Protocol Version 1.2, available at https://tools.ietf.org/html/rfc5246/.

[RFC 5280] IETF, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, available at https://tools.ietf.org/html/rfc5280/.

[RFC 6960] IETF, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, available at https://tools.ietf.org/html/rfc6960/.

[BCP 195] Sheffer, Y., Holz, R., and P. Saint-Andre, Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), BCP 195, RFC 7525, May 2015, http://www.rfc-editor.org/info/bcp195.

[ICAM] National Security Systems and Identity, Credential and Access Management Sub-Committee Focus Group, Federal CIO Council, ICAM Lexicon, Version 0.5, March 2011.

[ISO/IEC 10646] International Standards Organization, Universal Coded Character Set, 2014, available at http://standards.iso.org/ittf/PubliclyAvailableStandards/c063182_ISO_IEC_10646_2014.zip

[ISO/IEC 24745] International Standards Organization, Information technology – Security techniques – Biometric information protection, 2011, available at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52946

[OWASP-XSS-prevention] Open Web Application Security Project, XSS (Cross Site Scripting) Prevention Cheat Sheet, available at https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

[SAML] OASIS, SAML, Security Assertion Markup Language 2.0, v2.0, March 2005, available at http://oasis-open.org/standards#samlv2.0

[ISO 9241-11] International Organization for Standardization, Ergonomic requirements for office work with visual display terminals (VDTs) – Part 11: Guidance on Usability, ISO 9241-11:1998, ISO: Geneva, Switzerland, 1998.

[UAX 15] [UAX 15] Unicode Consortium, Unicode Normalization Forms, Unicode Standard Annex 15, Version 9.0.0, February, 2016. Available at http://www.unicode.org/reports/tr15/

11.2. NIST Special Publications

NIST 800 Series Special Publications are available at: http://csrc.nist.gov/publications/nistpubs/index.html. The following publications may be of particular interest to those implementing systems of applications requiring e-authentication.

[SP 800-52] NIST Special Publication 800-52, Revision 1, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, April, 2014.

[SP 800-53] NIST Special Publication 800-53, Revision 4, Recommended Security and Privacy Controls for Federal Information Systems and Organizations, August 2013 and Errata as of January 2015.

[SP 800-63C] NIST Special Publication 800-63C, Assertions and Federation. To be updated at publication

[SP 800-131A] NIST Special Publication 800-131A , Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, Revision 1, November 2015.

[SP 800-132] NIST Special Publication 800-132, Recommendation for Password-Based Key Derivation, December 2010.

11.3. Federal Information Processing Standards

FIPS can be found at: http://csrc.nist.gov/publications/fips/

[FIPS 140-2] Federal Information Processing Standard Publication 140-2, Security Requirements for Cryptographic Modules, May 25, 2001.

[FIPS 198-1] Federal Information Processing Standard Publication 198-1, The Keyed-Hash Message Authentication Code (HMAC), July 2008.

[FIPS 201] Federal Information Processing Standard Publication 201-2, Personal Identity Verification (PIV) of Federal Employees and Contractors, August 2013, available at http://dx.doi.org/10.6028/NIST.FIPS.201-2.

11.4. Legislation

[Privacy Act] Privacy Act of 1974 (P.L. 93-579), December 1974, available at http://www.justice.gov/opcl/privacy-act-1974

[E-Gov] E-Government Act [includes FISMA] (P.L. 107-347), December 2002, available at http://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf

Appendix A: Strength of Memorized Secrets

This appendix is non-normative.

A.1 Introduction

Despite widespread frustration with the use of passwords from both a usability and security standpoint, they remain a very widely used form of authentication. Humans, however, have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. To address the resultant security concerns, online services have introduced rules in an effort to increase the complexity of these memorized secrets. The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveals that the benefit of such rules is not nearly as significant as initially thought, although the impact on usability and memorability is severe.

Complexity of user-chosen passwords has often been characterized using the information theory concept of entropy[ref]. While entropy can be readily calculated for data having deterministic distribution functions, estimating the entropy for user-chosen passwords is difficult and past efforts to do so have not been particularly accurate. For this reason, a different and somewhat simpler approach, based primarily on password length, is presented herein.

It should be noted that there are many attacks associated with the use of passwords that are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones. These attacks are outside the scope of this Appendix.

A.2 Length

Password length has been found to be the primary factor in characterizing password strength. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.

The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by throttling the rate of login attempts permitted. In order to prevent an attacker (or a claimant with poor typing skills) from easily inflicting a denial-of-service attack on the subscriber by making many incorrect guesses, passwords need to be complex enough that throttling does not occur after a modest number of erroneous attempts, but does occur before there is a significant chance of a successful guess.

Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no throttling requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.

Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.

A.3 Complexity

As noted above, composition rules are commonly used in an attempt to decrease the guessability of user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases the special characters that are not accepted might be an effort to avoid attacks like SQL Injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove spaces in typed passwords prior to verification.

Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.

A.5 Randomly-chosen secrets

Another factor that determines the strength of memorized secrets is the process by which they are generated. Secrets that are randomly chosen (in most cases by the verifier or CSP) and are uniformly distributed will be more difficult to guess or brute-force attack than user-chosen secrets meeting the same length and complexity requirements. Accordingly, at LoA 2, SP 800-63-2 permitted the use of randomly generated PINs with 6 or more digits while requiring user-chosen memorized secrets to be a minimum of 8 characters long.

As discussed above, the threat model being addressed with memorized secret length requirements includes rate-limited online attacks, but not offline attacks. With this limitation, 6 digit randomly-generated PINs are still considered adequate for memorized secrets.

A.6 Summary

Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate throttling are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.