今日、パスワードやWebリソースでの従来の認証方法を回避するという考え方がますます頻繁に提起されており、Google、Paypal、およびFIDOアライアンスの他のメンバーなどのIT業界の巨人がこれを処理しています。 Googleの従業員が実施した調査の一環として、認証方法を改善する方法と、Cookieを使用しないTLS拡張標準のドラフトが提案されました。



この記事では、従来の認証方式の問題、2段階認証を導入する際の落とし穴、および提案されているTLS拡張標準について検討します。 この記事のテキストは、2段階認証を統合する予定のWeb開発者に役立ちます。



強力な認証方法を議論するとき、提案されたすべての方法がユーザーにとって複雑すぎるか不便であるという疑問がしばしば生じます。 この場合、2つの補完的なソリューションを提案できます。

• 重要度によるアカウントの分離
• ユーザー透過認証の使用

アカウントの区別

明らかに、すべてのアカウントが強力な認証を必要とするわけではありません。 Googleは、これらを次のタイプに分割することをお勧めします。

• ユーザーがもう戻る予定がないサービスのワンタイムアカウント。 このようなサービスには、強力な認証制御は必要ありません。
• ユーザーが大事にする典型的なアカウントですが、その損失は重大な損失または評判の損失を伴いません。
• パブリックアカウント：Twitterまたは多数のサブスクライバーがいるブログ、およびクレジットカード情報を含むオンラインストアのデータベース
• 重要なアカウント：主要な住所またはオンラインバンクのアカウント。

明らかに、最後の2種類のアカウントには強力な認証が必要であり、時間の経過とともにアカウントクラスが相互に移動する可能性があることに注意してください。

典型的な脅威

すべてのアカウントは、次のような平凡なものであり、あまり脅威ではありません。

• フィッシング、2要素認証コードでも適切に変装しても保存されない
• 複数のアカウントのユーザーパスワード（または同じパスワード）の再利用
• ユーザーが間違ったフィールドまたは別のアカウントに正しいパスワードを入力した。 この脅威はそれほど明白ではありませんが、あるべき場所があります。時々、私自身がログインフォームにパスワードの半分を入力し始めました。
• パスワード回復方法を目的としたソーシャルエンジニアリング。
• ユーザーのコンピューターのウイルス感染。

これらの脅威の一部はパスワードマネージャーを使用して回避できますが、これには個別のプログラムのインストールが必要であり、さまざまなオペレーティングシステム上の豊富なユーザーデバイスとの互換性が不十分です。



ユーザーは通常、セキュリティ、アカウントの種類、および起こりうる脅威を気にしません。 実践が示すように、セキュリティに関連する変更は敵意を持つ人々によって認識されます。 したがって、目に見えない認証方法の開発に加えて、新しいメカニズムへの移行の透明性についても考慮する必要があります。

古い認証の新しい方法

デバイスへの認証の委任

現在、人々はますます多くの新しい鉄片を手に入れており、それらはネットワークにアクセスし、ユーザーはさまざまなサービスで認証されます。 同時に、デバイスは何らかの方法で、後で使用するためにユーザーデータを保存できます。



ユーザーがデバイスにアカウントへのアクセスを一度許可して、デバイスに自分自身を認証する権限を委任できるようになったとします。 ある程度まで、そのようなスキームは、現代のモバイルOSですでに実装されています。 以下の説明を追加して、認証データのキャッシュプロセスを確認する必要があります。

• 必要に応じて、多要素認証を使用してアクセスを直接委任します。
• ラベルはユーザーのデバイスを一意に識別し、別のデバイスから使用される場合は無効である必要があります。 これにより、サーバーはユーザーが現在どの特定のデバイスからログインしているかを理解できるようになり、アクセストークンの盗難の可能性からも保護されます。
• 「ライフタイム」アクセスタグ。 理想的には、ラベルが一意である場合、ユーザーがそれを取り消すことを決定するまでアクセスを許可する必要があります。
• デバイスを紛失した場合にアクセスを取り消すプロセス デバイスを紛失した場合、アクセスタグを無効にするだけでよく、パスワード自体を変更する必要はありません。
• PINコードでデバイス自体を保護し、その必要性をユーザーに伝えます。
• ユーザーによる確認が必要な操作の識別（パスワードの変更、アカウントの削除、金銭取引など）

その後、ユーザーが複数の認証済みデバイスを自由に使用できる場合、個々のデバイス間で権限の委任を構成できるため、パスワードをまったく入力する必要はありません。 これは、いくつかの要因と暗号的に堅牢なアルゴリズムを使用してプライマリ認証を実行する必要があることを示唆しています。

多要素認証に関する考え方

2要素以上の認証の技術は、情報セキュリティ組織のさまざまな分野で長い間使用されており、現在、多くの一般的なWebサービスには多要素認証の可能性が含まれています。 たとえば、GoogleとAmazonの後、Twitter、Dropbox、LinkedInもゲームに参加しました。 ただし、ほとんどのサービスは2番目の要素としてOTPメカニズムを使用します。 この方法はあまり便利ではないことに加えて（SMSを待つか、特別なアプリケーションを起動するか、OTPトークンでパスワードを生成してからペンで入力する必要があるたびに）、OTPには多くの脆弱性があります-フィッシングの可能性に加えて、それを保存する必要があるクリアテキストのOTPジェネレータシークレットサーバー。 あまり知られていない有名企業の苦い経験から、最終的に強力なパスワードハッシュを使用するようになりました。その後、OTPの秘密を明確に保ち、​​穏やかに奇妙なものにする必要がありました。 サーバーに認証データを安全に保存するには、非対称暗号化アルゴリズムを使用する必要があります。 これらの問題については記事の本文で後ほど検討しますが、ここでは、多要素認証システムを開発する際に生じる主な困難を読者に提供します。



最も単純な2段階認証を実装する場合でも、以下を考慮する必要があります。

• ユーザーが携帯電話ネットワークの外にいるとき（休暇中など）のアプリケーションの動作
• アカウントのユーザー回復プロセス
• デバイス/携帯電話番号を変更し、アクセスタグを無効にするプロセス

アカウントアクセススキームの一般的な構成に加えて、多くのアプリケーションはすぐに新しい認証手順に切り替えることができないことを考慮することが重要です。 この場合、Googleがすべてのモバイルプログラムで現在行っているように、Webフォームに基づくアプリケーションに認証を実装すると便利です。 このメソッドにより、開発者はさまざまな認証APIから抽象化し、プロセス全体を単一のブラックボックスと見なすことができ、その出力でプログラムはアクセストークンを受け取ります。



2要素認証はユーザーにとって最も透過的で目立たないはずなので、標準アカウントでは完全に切り替えることができないことは明らかです。 したがって、ユーザーに負担をかけない妥協案を見つけ、アカウントのセキュリティを確保する必要があります。 Googleの調査では、1か月に1回の再認証の要件は煩わしく、同時にデバイスの紛失の脅威から保護されないことが示されています。 この場合の黄金の意味は、ユーザーが最初にシステムにログインするときの2要素認証の要件です。その後、ブラウザまたはデバイスに「スーパーCookie」が書き込まれ、特定のデバイスが将来承認されます。 さらに、ユーザーが必要に応じて、ブラウザーのCookieセッションの有効期間を制限できます。



予期しない2段階認証のマイナスとして、アカウント管理を傍受する攻撃者による使用を区別することが可能です：攻撃者が2段階認証を無効にしたアカウントへのアクセスを取得した後、彼は自分の電話番号を使用して設定できるため、アカウントを回復する手順が複雑になります。

中間出力として

要するに、最新の2段階認証方法（たとえば、OTP over SMS）は、サーバーからのパスワード再利用の脅威やパスワードハッシュデータベースの漏洩（ええ、時にはクリアテキストのパスワード）から保護するのに役立ちますが、それでも手の込んだフィッシングに対しては効果がないことがわかりますまたは電話自体の盗難を含む標的型攻撃。 したがって、OTPの脆弱性を持たないメカニズムを考慮する必要があり、さらに、必要なユーザー認証が少なくなります。

ハードウェアと実装により近い

上記で、公開キー暗号化を使用して、サーバーからのフィッシングおよびデータ盗難から保護する必要性について説明しました。 同時に、USBトークンの形で追加のデバイスを使用してキー情報を保存することは合理的です。 実践が示すように、そのような技術への移行は可能な限り単純でなければなりません。したがって、次の要件を確立する必要があります。

1. このテクノロジーでは、ブラウザーとその拡張機能を超える追加ソフトウェアのインストールは必要ありません。
2. ユーザーが登録されている多くのウェブサイトにデータを保存するには、1台のデバイスで十分です
3. 登録および認証プロトコルはオープンである必要があり、サードパーティのサービスに依存するべきではありません。 ユーザーはサイトを信頼しているため、他の関係者はユーザーとサイトの間の関係に入るべきではないことに注意することが非常に重要です（これは同じSSLによって促進されます）

この場合、ブラウザ（+プラグイン）は、新しいユーザーの登録と認証のための2つのAPIをサイトに提供する必要があります。 新しいアカウントを作成するとき、サービスは登録APIを呼び出します。その結果、デバイス上に新しいキーペアが生成され、その公開キーはサーバーに保存されます。 その後、このキーは次のようにユーザーのIDを確認するために使用されます。サーバーは認証APIを使用して、リクエストをユーザーに渡し、署名して返送します。 Rutoken WebおよびRutoken Plug-inの製品にも同様の認証スキームが実装されています。



Chromeブラウザー開発者の経験から 、単純な認証に証明書を使用することはお勧めできません。 これに関して、GoogleはTLSプロトコルの拡張を作成することを提案します。これは、上記の認証スキームを実装します。

TLS ChannelID拡張

この拡張機能はIETFドラフトで説明されており、TLSプロトコルを拡張するメカニズムを提供します。これにより、HTTP CookieやOAuthトークンなどの認証トークン（英語、ベアラートークン）の転送を取り除くことができます。



そのようなトークンの所有者（何らかの方法で以前に取得された）は、トークンの所有者と送信先のチャネルに関係なく、リソースにアクセスできます。 したがって、認証トークンを所有している攻撃者は、別のユーザーを装って問題なくログインできます。



標準のドラフトでは、TLS拡張について説明しています。TLS拡張を使用すると、クライアントとサーバーの間に、これらの接続が同じクライアントデバイスから発信された場合にさまざまなHTTP要求とTLSセッションの間に保存される長期チャネルを作成できます



この方法の本質は、Cookieの代わりに初期認証の後、クライアントデバイスでキーペアが生成され、その公開キーがサーバーに保存されることです。 後で、TLS接続（TLSハンドシェイク）の確立中に、クライアントはサーバーに対して秘密キーを所有していることを証明し、公開キーはチャネル識別子（チャネルID）です。 この方法は、いくつかの理由でCookieを使用するよりも優れています。

• 秘密鍵がクライアントデバイスから離れることはないため、攻撃者はチャネルからの秘密を傍受することはできません。
• すべての暗号化操作は個別のデバイスで実行できます。これにより、クライアントからの直接の盗難から秘密鍵が保護されます。

TLSハンドシェイクプロセスの説明

接続を確立するとき、クライアントはClientHelloメッセージに拡張子「channel_id（0x754F）」を追加できます。 サーバーがこの拡張機能をサポートしている場合、ServerHelloメッセージでこれをクライアントに通知できます。



サーバーから拡張ServerHelloを受信した後、クライアントは選択された暗号化アルゴリズムの強度を確認し、「ChangeCipherSpec」の後「Finished」の前に「EncryptedExtensions」というメッセージで応答する必要があります。 このメッセージは、公開鍵と署名値のパラメーターを次の形式で示します。

struct { opaque x[32]; opaque y[32]; opaque r[32]; opaque s[32]; } ChannelIDExtension;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、x、y、r、およびsは32バイトのビッグエンディアンの数値です。 xおよびyフィールドには、P-256楕円曲線のアフィン座標が含まれ、rおよびsフィールドには、対応する秘密鍵を含むECDSA署名が含まれます一般的なTLSハンドシェイクを次の図に示します。 緑色は、標準と比較した変更を強調しています。

結論として

標準はまだ開発中であるため、厳密な結論を出すことは困難ですが、少なくとも、Googleが認証の開発で見ている傾向を強調することができます。 まず、従来のパスワード認証を他の方法で補完する必要があることは明らかです。 第二に、ユーザー間で多数のデバイスが出現したため、これらのデバイスを認証する信頼できる方法を開発する必要があります。 そして第三に、アカウントのセキュリティレベルの「シフト」の傾向を区別できます。以前の2要素認証が主にRBのサービスで使用されていた場合、現在はパブリックアカウントの領域に移行しています。 このことから、RBS自体のサービスにはOTPよりも厳しい認証方法が必要であると結論付けることもできます。