[LINE Login]QRコードログインでメールアドレスもパスワードも不要に！

こんにちは、富士榮です。

ついにLINE LoginがブラウザシナリオでのQRコードログインをサポートしました！
このことにより、LINEへのメールアドレスとパスワードの登録がない人でもPCのブラウザやスマホの標準ブラウザ以外でWebアプリへのLINEログインできるようになりました。
（永らく待ち望んでいた機能なのでとっても嬉しいです）

公式アナウンス
　https://developers.line.biz/ja/news/tags/line-login/

■従来の制限（ブラウザシナリオ）

従来もQRコードログインはPCやMac、iPad用のLINEアプリへのログインには使えていましたが、PCブラウザやスマホでも標準ブラウザ以外でLINE Loginを使ったWebアプリへアクセスすると、メールアドレスとパスワードを使ってログインする必要がありました。

もちろんスマホの場合はLINE Loginの自動ログイン機能が使える環境であれば、ブラウザからLINEアプリが呼び出されて自動的にログイン、ブラウザへ制御が戻る、という流れでメールアドレス・パスワードを使わないログインが実現できていました。

しかし、この自動ログイン機能はカスタムスキームを使ってLINEアプリを呼び出すところまではOKなのですが、標準以外のブラウザだとLINEアプリからブラウザへの戻す時に戻し先ブラウザの制御を行うことが出来なかったため、標準ブラウザの場合に制限されていました。
ということで、自動ログイン機能を使う場合は、以下の制限があります。

iOSの場合

LINE 7.5.0未満：アプリ内ブラウザで、LINEログインv2を実装したウェブサイトにアクセスすると、自動ログインできます。

LINE 7.5.0以降：アプリ内ブラウザまたはSafariブラウザで、LINEログインv2を実装したウェブサイトにアクセスすると、自動ログインできます。 

LINE 7.12.0以降：アプリ内ブラウザまたはSafariブラウザで、LINEログインv2またはv2.1を実装したウェブサイトにアクセスすると、自動ログインできます。 

Androidの場合

LINE 7.14.0未満：アプリ内ブラウザまたはChromeなどの外部ブラウザで、LINEログインv2を実装したウェブサイトにアクセスすると、自動ログインできます。 

LINE 7.14.0以降：アプリ内ブラウザまたはChromeなどの外部ブラウザで、LINEログインv2またはv2.1を実装したウェブサイトにアクセスすると、自動ログインできます。

出典）https://developers.line.biz/ja/faq/

■QRコードログインが付かなかったことによる制限

新規にLINEアプリを登録する時、SMSさえ通じればメールアドレスの登録は必須ではなく、パスワードも不要なため、スマホ・ネイティブな世代の殆どがメールアドレスもパスワードも登録しない状態でLINEの利用を開始していると思われます。
もちろん、LINEもアカウントのリカバリの容易さなどを理由にメールアドレスとパスワードの登録を推奨していましたが、現実問題登録していないアカウントもそれなりの数、存在していました。（数字は言えませんが）

上記の制限事項もあり、LINE Loginをブラウザシナリオで実装する際は、ある程度の数「使えない」ユーザが存在することを前提に設計を行う必要がありました。

以前よりLINEさんにはブラウザでもQRコードログインをサポートしてもらえるようにお願いはしていたのですが、ようやく実現した！！というのが今回の発表です。

■早速使ってみる

では、早速使ってみます。（といっても見た目は地味ですが）

LINE Loginを使うWebサイトにアクセスするとLINEへリダイレクトされます。
（ちなみに、QRコードログインを使うには、LINE Login v2.1を使っている必要があります）

ログイン画面が変わっています。下の方に「QRコードログイン」がみえます！
早速クリックすると、QRコードが表示されます。（一部マスクしています）

おもむろにスマホを取り出してQRコードをスキャンします。
（友達追加の時に使うアプリ内のQRリーダーを使います）

ログイン確認をされるので、ログインボタンをタップします。
すると、ブラウザに認証番号が表示されるので、スマホ側で数字を入力します。

ここで入力します。

問題なく確認が終わると、ブラウザ側でログイン処理が完了、アプリへ遷移します。



ということで、メールアドレスもパスワードも使わずにアプリケーションへのログインができるようになりました！
Microsoftアカウント、Yahoo! JAPANのパスワード・レス・ログインに続いてLINEも同体験を実現してきており、ようやく人類がパスワードを捨てることが出来る日がくる予感がしてきました。

Active Directoryのパスワードに特定の文字の利用を禁止する

こんにちは、富士榮です。

先日紹介したAzure ADの新機能「Azure AD Password Protection for Windows Server Active Directory」を使うとブラックリストに載っているパスワードを使うことを禁止することは出来る様になりますが、特定の文字だけを禁止することは今のところ出来なさそうです。

エンタープライズのレガシーなID管理のシナリオだと未だにCSV万能説な文化なので、パスワードに特定の文字を使えなくしたい、というニーズがそこそこあります。
例えば、「,」（カンマ）とか「”」（ダブルクォート）とか「’」（シングルクォート）とかですね。なぜなら、平文パスワードをCSVに載せてFTPで送りつける、ということをしようとすると、この辺りの記号が邪魔をするんですよね・・・。

この辺りに起因する不具合を防止するために、CTRL＋ALT＋DELを使ったパスワード変更をグループポリシーで禁止して、ID管理パッケージの持つパスワード管理画面からしかパスワードを変更させない様に構成、ID管理システムではパスワードに利用できない文字を定義する、というのが従来の王道パターンでした。

しかし、やはりWindowsの標準の仕組みでパスワード変更を許可したい、というニーズは根強く、各社パスワード・フック用のモジュールをリリースしていたり、という状況です。

当ブログでもほぼ10年前に紹介した「Active Directoryのパスワード変更をフックする」という記事へのアクセスが以外と息が長く、今でもアクセス数トップ3くらいには入っていたりして、何とかしてADのパスワードを引っこ抜いてやろう、という人々が数多く存在するんだな～（違）と感じている今日この頃です。


最近も某所でCSVにパスワードを出力したいからカンマを使えない様にしたい、と言う雑談をしていたりしたので、良し悪しはおいておいてちょっと書いてみました。

この辺りにおいてあります。
　https://github.com/fujie/pwdpol

Visual Studio 2017でC++のDLLを書く、というのも最近は中々無い経験なので新鮮な感じです。

ちゃちゃっと書いたので、エラーハンドリングやログ出力などもありませんし、Visual Studio 2017 on Windows 10 Proで作って、Windows Server 2012 R2で動作確認をしたので、VC++のランタイムのバージョンを合わせるのが面倒だったので、必要なDLL（msvcp140d.dll、vcruntime140d.dll、ucrtbased.dllの3つ）をC:\Windows\System32へコピーするとか強引なことをしてますが、皆さんはちゃんと必要なランタイムの再配布用パッケージをダウンロードして使ってください。

使い方は、ドメインコントローラ上で
・必要なDLLをC:\Windows\System32へ配置
・レジストリへの登録
・再起動
という3ステップですが、こちらは昔の記事と何も変わらないので、こちらをご参照ください。
https://idmlab.eidentity.jp/2018/06/azure-ad-ngad.html

こんなコードです。
＜本体：pwdpol.cpp＞

#include "stdafx.h"
#include <ntsecapi.h>
#include <regex>

#ifndef STATUS_SUCCESS
#define STATUS_SUCCESS ((NTSTATUS)0x00000000L)
#endif

using namespace std;

// initialize
BOOLEAN NTAPI InitializeChangeNotify(void) {
    return TRUE;
}

// evaluate filter
BOOLEAN NTAPI PasswordFilter(
    PUNICODE_STRING AccountName,
    PUNICODE_STRING FullName,
    PUNICODE_STRING Password,
    BOOLEAN SetOperation) {

    BOOLEAN ret;

    // filter in regular expression
    const wchar_t* pattern = LR"([\"\',])";

    // convert PUNICODE_STRING to wstring
    std::wstring pwd(Password->Buffer, Password->Length / sizeof(WCHAR));
    
    // search filtered charactors
    regex_search(pwd, wregex(pattern)) ? ret = FALSE : ret = TRUE;

    // clear buffer
    SecureZeroMemory((PVOID)pwd.c_str(), pwd.size());

    return ret;
}

// notify change
NTSTATUS NTAPI PasswordChangeNotify(
    PUNICODE_STRING UserName,
    ULONG RelativeId,
    PUNICODE_STRING NewPassword) {

    // nop
    return STATUS_SUCCESS;
}

＜定義：pwdpol.def＞

LIBRARY "pwdpol"
EXPORTS
    InitializeChangeNotify
    PasswordFilter
    PasswordChangeNotify

DLLの配置をして再起動すると上手くいけばポリシーが有効になります。
管理者がカンマを含むパスワードでリセットしようとしても

ユーザが自分でしようとしても、

ダメです。弾かれます。

これでパスワードをCSVに出力し放題です。何も気にすることはありません。どんどん出力してFTPでばらまきましょう。ファイルサーバにおいてCIFSで共有するのもいいアイデアです。

良い子はマネしちゃいけませんよ。

[Azure AD/パスワード保護] NGワードの登録、オンプレADへのポリシー適用

（6/20 更新：モジュールのダウンロードが復活したのでリンクを張りました）
こんにちは、富士榮です。

現状のAzure Active Directory（Azure AD）におけるクラウド・ユーザのパスワード・ポリシーは有効期限と期限切れ通知に関する設定の2点だけしかカスタマイズすることが出来ません。（しかも、Office365のポータルもしくはPowershellコマンドレットで変更するしか方法がありません）

基本的な考え方として、単純なパスワードや漏えいの恐れのあるパスワードや使いまわされているパスワードなどはAzure ADが自動的にブロックしてくれているので、オンプレミスのADに比べてかなり強力な保護が実装されており、そのまま任せておくのがベターというポリシーに基づいているものと思われます。

※Azure AD Connectで同期をしているユーザはオンプレミスのActive Directoryのパスワードポリシーに準拠しますので、グループポリシーで複雑性要件をカスタマイズすることが可能です。
※ちなみにAzure AD B2Cでは複雑性ポリシーなどをカスタマイズすることが可能です。

参考）Azure Active Directory のパスワード ポリシーと制限
https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/concept-sspr-policy


しかし、一方でせっかくAzure ADが強力なパスワード保護機能を持っているので、この機能をオンプレミスにも適用したり、更にNGワードを追加したり（例えば会社名など組織内では一般的な用語など）することで全体としてパスワード保護を強化したくもなってきます。（オンプレとクラウドでポリシーがバラバラになることで利用者の混乱を招く可能性も大きいと思いますし）

今回Preview公開されたAzure ADのパスワード保護機能では、以下の機能が実装されています。

• ロックアウトまでのログイン試行回数の設定
• ロックアウトが自動的に解除されるまでの時間（秒数）
• 利用できない文字列の設定
• オンプレミスADへのポリシーの適用

（2018/06/16時点）

ちなみに昨晩まではオンプレミスADへのポリシー適用に使うためのエージェントモジュールのダウンロードが出来たんですが、本日はリンクが切れています。

おそらく何らかの不具合がありモジュールを引っ込めたと思うので、再公開を待ちましょう。

ということで、オンプレミスADへのポリシー適用については試せていませんので、他の機能を紹介していきます。

6/20更新）以下のページからダウンロードができるようになりました。
　https://www.microsoft.com/en-ie/download/details.aspx?id=57071
オンプレミスADへのポリシー統合に関するドキュメントも合わせて公開されています。
　https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad-on-premises

手順は確認したら別途紹介したいと思います。

◆パスワード保護設定

Azure PortalよりActive Directoryを開くと[Authentication Methods]というメニューが表示されていますので開くと、[Password Protection(Preview)]という設定項目が出てきます。

この画面で先に紹介したロックアウト関連、NGワード登録、オンプレADへの適用に関する設定を行います。

ちなみにオンプレADへの適用についてはAzure ADのライセンス適用状況によってはグレーアウトされます。（おそらくPremium P1かP2のどちらかが必要そう。確認中）

6/20）ドキュメントを見るとやはりAzure AD Premiumが必要とのことです。

◆ロックアウトポリシーを変更する

まずはロックアウトされるまでの認証失敗回数を変更してみます。初期値は10ですので、既に上記の画面ショットでは2回に変更してあります。

つまり、上記の画面の設定だと、2回パスワードを間違えると60秒間ロックされます。

というわけで2回間違えるとこんなメッセージが表示されます。

◆NGワードの登録

Custom banned password listという項目に最大1000個までNGワードを登録できます。
ちなみに、大文字・小文字の判別は無く、oと0、aと@などの代替文字の読み替えも自動的にやってくれます。

ちなみに今回は試しに「hogehage」というNGワードを登録しておき、「H0geh@ge」というパスワードを設定しようとすると以下のように弾かれました。

何度も使っている訳ではないので、メッセージは微妙ですが実際に設定が出来なくなりました。中々便利です。

後はオンプレADへこれらのポリシーを含むAzure ADのパスワード保護が適用できるとかなり便利になると思うので、ダウンロードが回復したら試してみようと思います。

スマートフォンを使ってマイクロソフトアカウント認証を行う

こんにちは、富士榮です。

Windows 10へマイクロソフトアカウントでサインインして、IEもしくはEdgeしか使わない、という人はPCとブラウザのシングルサインオンが有効なので気にすることは無いかも知れませんが、一般人はChromeやFirefoxなども利用していると思いますので、MSDNやLive等のマイクロソフトの提供するサービスを利用する際がマイクロソフトアカウントとパスワードを使ってログインしていると思います。（そして、もちろん2段階認証も使っていると思います）

このように、パスワードをなるべく使わない方向に世の中シフトしてきてはいますが、なかなか一般人の利用方法だと完全にパスワードの利用を無くすのが難しいのも現実です。

※ちなみに以前紹介したWindows 10のPC自体へのログインをスマートフォンで行ったりWindows Helloを使った生体認証を使うと本当にパスワードを使うことなく日々の生活が送れてしまいます。


そこで本日はマイクロソフトアカウントでサインインする際に、パスワードの代わりにスマートフォンを利用する方法を紹介します。
（最近、iOS版アプリが更新されて使えるようになりました）

必要なもの

・マイクロソフトアカウント（～@live.jpなど）
・スマートフォン（iOS、Android、Windows Phone）
・Microsoft Authenticatorアプリ（スマートフォンにインストール）
 ※iTunesストアなどよりインストール

設定（利用の準備）

まず、マイクロソフトアカウントのページ（https://account.microsoft.com）へサインインします。

ログイン後、セキュリティのメニューを開きます。

次にセキュリティ情報の更新の「更新情報」を開きます。

「追加オプション」を開きます。なかなか深い階層に設定がありますね・・・

ここでようやく目的の認証アプリの設定項目が見つかりますので、「本人認証アプリをセットアップ」を開いて設定を行います。

設定画面を開くと、アプリケーションをインストールしたデバイスを選択することになるので、先にアプリをインストールしたデバイスの種類を選択して次へをクリックします。

スマートフォンアプリケーション側での設定を促されるので、アプリ側の設定を行います。この際、アプリ側の設定が終わるまではこの画面の「次へ」をクリックしないでください。

アプリを開くと設定するアカウントの種類を選択させられるので、「個人のアカウント」を選択します。

ここでマイクロソフトアカウントでのサインインを要求されるので、スマートフォンサインインを使いたいマイクロソフトアカウントでサインインします。さすがにここはパスワードでのサインインです。

設定が完了すると画面上にワンタイムパスワードが羅列された画面になるので、先のブラウザに戻って「次へ」をクリックします。

これで設定は完了です。

サインインしてみる

サービスはなんでもいいです。MSDNやOutlook、Azure Portalなどでも大丈夫です。

アカウント名を入れると通常のパスワード入力画面に飛びますが、設定がうまくいっていればこの際「代わりにアプリを使用する」というリンクが出てくるようになるので、このリンクをクリックします。

すると、アプリへ認証要求が飛び、ブラウザ側はアプリ側の承認を待機します。

アプリ側はこんな感じでサインイン要求が来るので、「承認」をタップします。
この際、TouchIDが使えるiPhone/iPadであればTouchを求められます。

上手くいくとブラウザ側でのログインが完了し、対象のサービスへ遷移します。※この例ではAzure Portalへアクセスしています。

これまで、Windows 10、Edge/IE、組織アカウントの組み合わせで限定的に使えていたパスワードレス認証の範囲が、他のブラウザへも広がってきており、いよいよパスワードを使うことなく生活できる日も近くなってきた感があり、今後の展開を含め非常に楽しみですね。

[FIDO]Injectorでパスワードの使いまわしや簡単なパスワードの利用を防止する

こんにちは、富士榮です。

先日のOpenIDファウンデーション・ジャパン、Enterprise Identity Working Group（EIWG）の成果報告会で、Cloud Identity Summit 2016（CIS）への参加についてBlockchainとHashgraphとアイデンティティに関する報告をさせてもらいました。

　資料等は前回のポストで。
　Blockchain、Hashgraphとアイデンティティ
　http://idmlab.eidentity.jp/2016/06/blockchainhashgraph.html


実はCISではセッションの他にExpoという形で各社がソリューションを持ち寄る展示会があり、その中でFIDO関係のブースで出展をしていたBluink社のInjectorというデバイスがとても面白かったので、取り寄せてみました。

Injectorには、Injector USB DeviceとInjector Miniという2種類がありますが、あんまり機能差がなさそうなので、持ち運びを考えてInjector Miniを購入しました。

公式サイトのストアで$29.99＋日本への送料（$15.00）の合計$44.99で購入できます。


2週間くらいで届いたので、早速試してみます。

◆何をするものなのか？

まず、そもそもこれは何をするものなのか？というと、「スマートフォンアプリに各種ログオン情報を記憶させておき、Injector（ドングル）を挿したPCでの各種ログインをスマホ経由で行う」ためのものです。

１．IDとパスワードの入力を代行する入力デバイス

（公式サイトの解説より）

簡単に言うと、PCに挿したBluetoothアダプタが入力デバイスとして認識され、スマホからログインに必要なキーストローク情報を送り込む、というかなり原始的な？仕組みです。
尚、この仕組みをとるのでPC側には基本的には何の追加ソフトウェアもいりません。
（QRコードを使って対象アプリケーションの選択を簡素化したい場合はブラウザのアドオンを入れる必要がありますが、自分でスマホ上で対象のアプリケーションを選択するなら本当に何もいりません）

試しにLinkedInへのログインを動画にしてみました。



２．FIDO U2Fに対応した2要素目のデバイス

また、違った一面としてFIDO U2Fに対応しているので、GoogleなどU2Fに対応したサービスへのログイン時の2要素目としても利用が可能です。

こちらも同じくGoogleへのログイン時の2要素目として使ってみました。

◆まずは準備

では、早速使ってみます。
準備として、スマホ用のアプリケーションをダウンロード～インストールします。

アプリを立ち上げると、マスタパスワード（このアプリ自体の起動パスワード。Touch IDも使えます）の登録およびInjectorデバイスとのペアリングを行うことになります。
（この段階でPCへInjectorデバイスを挿入します）

尚、このペアリングですが、工場出荷時はオープン状態（どのスマホとでもペアリング可能な状態）のはずなんですが、私の手元に届いたものはどうしてもうまくペアリングできず、サポートとやり取りをしてリセットをしてもらいました。（15分くらいでリセット用のコードを発行してもらいました。現地は土曜日の昼頃だったはずなんですが、驚異的なスピードです！）


うまくいくと、こんな感じでデバイスが登録された状態になります。

◆ログイン対象を登録

これでアプリとデバイスの準備が出来たので、次はアプリケーションの登録です。

アプリでAdd Credentialというメニューがあり、ある程度のアプリケーションはプリセットされているので、そこから選択すると簡単に登録ができます。

ここでアプリを選んでログインに使うIDとパスワードを登録していく、という形をとります。
尚、注意点ですが先に書いたとおり、キーストロークを送り込むという仕組みになっている以上、キーボード配列が違うと特に記号がうまく入りません。
これを使うときはPCを英語キーボードモードにしておきましょう。

後は先の動画で紹介したように各アプリを開いてスマホ側でログインをするだけです。

◆FIDO U2Fとしての登録

次は、基本的な使い方に加えてFIDO U2FデバイスとしてInjectorを登録してみましょう。
尚、これも注意点なんですが、U2Fに使う場合、キーストローク入力型の基本的な使い方との両立が現時点でうまくいっていません。（私の環境の問題かもしれませんが）
基本的な使い方の方に戻したければU2Fとしての登録を一旦削除してあげる必要があります。


動きは先に動画で紹介したので、GoogleへのInjectorデバイスの登録の方法を簡単に紹介します。基本はFIDOなのでYubikeyなどと同じくデバイスを事前に登録しておくだけです。

Googleの2段階認証セットアップを開き、セキュリティキーの登録を行います。
基本は画面の指示に従ってキーの挿入をし、アプリケーション側に表示されるRegistration確認を行うだけです。

（Googleのセキュリティキーの登録画面から指示に従いデバイスを登録する）

（うまく認識するとアプリに登録確認が出てくるので回答する）

これで完了です。
後は2段階認証の際にデバイスを挿してアプリで回答するだけです。

◆使ってみた感想

意外と良いかもしれません。
LastPass見たいなサービスに依存するものもなく、あくまでペアリングされたデバイスに依存するので、オフラインでも使えますし（それこそWindowsやMacへのログインにも使えます）、キーストローク入力するだけの簡単な仕組みなので対象のアプリケーションを選びません。
これで各アプリ向けのパスワードは本当にランダムなものを使ってしまっても問題ないかもしれませんし、ブラウザにパスワードを覚えさせる必要もありません。
（忘れた場合、Injectorの設定データのバックアップからパスワードを復元するためのツールが提供されています）

ただ、課題がないわけでもありません。
具体的にはあくまでUSB入力デバイスなので、モバイルのネイティブアプリやブラウザでの利用は出来ません。ネイティブアプリの場合はアプリケーションパスワードなどをうまく利用すればよいでしょうが、ブラウザの場合は困ってしまうので今後に期待です。
（現状でもiOSのSafariの場合はIntentでアプリを呼び出してキー入力させる様にできるみたいです）

[SAML/OpenID Connect]どうなる？Microsoft Passportを使った場合のacr/amr

こんにちは、富士榮です。

SAMLやOpenID ConnectではIdentity Provider（IdP）でユーザがどのような方法で認証されたのかをAssertionやid_tokenの中に含めてRelying Party（RP）へ連携を行います。

この目的は、RPがIdPから渡される認証手段を検査して、求めるLoA（Level of Assurance/保証レベル）を満たしているかどうかを判断し、ログインを許可するかどうかを判断させることにあります。例えば、決済に関するサービスであればパスワードを使った認証では不十分で多要素認証を求める、などの判断を行います。

では、Azure ADに参加したWindows 10のPCにログオンし、Microsoft Passportを使ってアプリケーションへシングルサインオンした場合、IdPであるAzure ADはRP（アプリケーション）へどのような値を連携するのでしょうか？Microsoft Passportを使うということは、Azure ADへのログオン時に一切パスワードを使っていません。
（ついでに言うと今回のテスト時、PCへのログオンはWindows Helloを使ったので、PCへのログオン時にもパスワードは一切使っていません）

早速見てみましょう。
今回は、SAMLおよびOpenID Connectに対応したアプリケーションを用意し、fiddlerで実際にどのような値が渡ったのかを覗いてみます。

◆SAMLとOpenID Connectにおける認証手段の表現方法

まずSAMLとOpenID Connectにおける認証手段の表現方法を確認しておきましょう。

• SAML
• AuthnContextのAuthnContextClassRef属性を利用します。例えば、パスワードで認証されたことを示す場合は、[urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport]がセットされたり、AD FSなどを使って統合Windows認証が使われた場合は[urn:federation:authentication:windows]が使われたりします。
• OpenID Connect
• （2016/03/07追記）SAMLと同じくacr（Authentication Context Class References）を使います。OpenID Connectにおいてはid_tokenの中に値が設定されます。が、現状Azure ADにおいてはacrはセットされないようです。（B2Cテナントにおいては何故か固定値[b2c_1_sign_in]がセットされます）
• id_tokenの中のamr（Authentication Methods References）クレームを利用します。どのような値が使われるかはプロトコルの規定外ですが、パスワードで認証された場合は[pwd]が使われたりします。

◆SAML対応アプリケーションへ渡されるAssertionを覗いてみる

では、早速SAML対応のアプリケーションへログオンしてみます。
Azure ADに参加したWindows 10のPCへAzure ADユーザでログオンし、アクセスパネル（https://myapps.microsoft.com）をMicrosoft Passportに対応したブラウザ（今回はEdgeを使いました）でアクセスします。

Microsoft Passportが有効なので、パスワードを入力することなくアクセスパネルが開きますので、SAMLに対応したアプリケーション（今回はGoogle Appsを使います）を開いてみます。

このとき、fiddlerを立ち上げて通信をキャプチャしておき、Google AppsのAssertion Consumer Service（www.google.com/a/ドメイン名/acs）へPOSTされるSAMLResponseを拾います。

拾ったSAMLResponseはSAML AssertionをBase64URL Encodeしたものなので、Decodeしてから目的のAuthnContextClassRefを探します。
ちなみに、SAML2 debuggerというサイトを使うとSAMLのメッセージをEncode/Decodeできるので便利です。
　参考）SAML2 Debugger
　　　https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php

結果、[urn:oasis:names:tc:SAML:2.0:ac:classes:Password]が入っています。
パスワードで認証したわけではないのに、パスワードで認証されたことになっている、ということです。
Azure ADを使ってSAMLアプリケーションにログインする場合は、どんな認証手段を使ったかについてはあてにならない、ということですね。

◆OpenID Connectアプリケーションへ渡されるid_tokenを覗いてみる

次は、OpenID Connectです。
SAMLの場合と同じく、Azure ADと連携したアプリケーションへMicrosoft Passportが有効な環境でログオンしてみます。

id_tokenをアプリケーションへ渡す方法（response_mode）も色々ありますが、今回のアプリケーション（自作）ではAzure ADの初期値であるform_postでid_tokenを渡しているので、Azure ADでログオンを行うとformを含むhtmlがダウンロードされ、JavaScriptで自動的にformデータがPOSTされます。
fiddlerで見ると、こんな感じに見えます。

このid_tokenの中身を覗いてみます。今度はJSON Web Token（JWT）なので、decodeするとPayload部分のJSONに各種クレーム（属性）が出てきます。

SAMLではSAML2 Debuggerを使いましたが、OpenID Connectの場合はjwt debuggerを使います。
　参考）jwt debugger
　　　http://jwt.io/

こんな感じで出力されます。

amrクレームの値を見ると、[pwd]と[rsa]の2つの値が入っています。
SAMLの場合と異なり、一応署名検証を使った認証を使ったことも認識されているようです。
（実際には使っていないパスワードも使ったことになっていますが）


ちなみに、Microsoft Passportが無効な環境で同じアプリケーションにアクセスした場合は[pwd]のみしかamrクレームに入ってきませんので、一応認証方式が異なることを表現してはいるようです。

こちらが、Microsoft Passportなしでログインした場合のamrの値です。

◆結論？

現段階において、Azure ADと連携するアプリケーションを開発する場合は、SAMLにおけるAuthnContextClassRefやOpenID Connectにおけるamrを見て認証方式や強度を判断するのは困難なようです。（OpenID Connectの方が若干マシですが、pwdが残ってるのは？です）


いずれにしても、想定している認証手段でログオン～ID連携が行われた場合にアプリケーションがどのような値を受け取るのか？についてはテスト段階で十分に検証を行っておく必要がありますね。

[Windows 10]PIN対パスワード、そしてWindows Passport

こんにちは、富士榮です。

昨年夏のリリース時から「パスワードは時代遅れです」というメッセージで世の中を混乱の渦に巻き込んできたWindows 10ですが、半年が経過した今でも「やっぱり意味がよくわからない」という声をしばしば耳にします。
※ちなみにTH2のビルドだと「PINのセットアップ」というメッセージになっています。

これまでも各所の記事やセミナなどでは簡単に話をしたことはあるのですが、ちょうど前回から書き始めているWindows 10のドメイン参加やサインインの仕組みの大前提になる話でもあり、良い機会でもあるので簡単にまとめておきたいと思います。
（ちなみに多分に私見が入っています）


◆何が議論されているのか？
まず、これまで起きている議論はどういうものなのか、簡単にまとめておきます。

Windows 10をセットアップすると「PINはパスワードを使用するよりも早くて安全です」というメッセージ表示されます。また、短いPINが長いパスワードより安全な理由として「PINはこのデバイスでしか動作しないからです」と説明されています。

これを見て、
「数字4桁のPINの方がなんでパスワードより安全なの？」
とか、
「Windows 10ではPINに数字以外が使えるようになったし桁数も増やせるから！！」
とか、
「Windows Helloで生体認証と組み合わせられるから安全なんだ！」
とか、
「PINは端末とセットだからパスワードより安全なんだ！」
など、色々な疑問や意見がやり取りされて来ました。


それぞれの疑問や意見を見ると、もっともらしいものもありますが、いまいち何の話をしているのかがよくわからない、というのが正直な感想です。


◆なぜモヤモヤするのか？
まず、これらの議論を考えるうえで圧倒的に欠けているのは、「安全かどうか？」という話の大前提は「相対論」である、という点だと思います。
つまり、疑問が発生するのは「何と何を」、「どうやって」比べて相対的に「安全」なのか？という前提が抜け落ちているからではないでしょうか？

例えば、桁数や複雑性を比較軸としてPINとパスワードを比べると、パスワードの方が安全、という結果になることが多いと思いますし、有効範囲（端末をまたいで使えるか）の広さを考えるとPINの方が安全（でも結局同じPINを使いまわすんじゃない？？？）みたいな話です。

このあたりがごっちゃになってしまっているので、ある一部分を切り取るとPINの方が安全に見えるし、違う見方をするとそうでもない、という話になり混乱を招いているといったところでしょう。


◆整理してみる
では、軸を整理してきちんと比較すればPINとパスワードのどちらが安全なのかが見えてくるんでしょうか？

まずリスクとなりうるポイントを洗ってみます。

＃	ケース	PIN	パスワード	コメント
①	のぞき見される	×	○	通常、複雑性はパスワードの方が有利
②	通信経路で盗まれる	○	×	PIN自体は通信経路を流れないのでPINの方が有利
③	フィッシングサイトに入力する	○	×	PINでサイトへログインすることは無いのでPINの方が有利
④	サービスのDBから漏えいする	○	×	PINでサイトへログインすることは無いのでPINの方が有利
⑤	リストを使ってサインインを試行	○	×	PINは端末とセットなので、漏れたPINで別端末へログインはできない
⑥	リスト攻撃される	○	×	PINでサイトへログインすることは無いのでPINの方が有利

いかがでしたか？
結論は出ましたか？


一見PINが安全に見えますが、やっぱりモヤモヤは止まりません。


◆ではマイクロソフトは何が言いたかったのか？
結論から言いますと、そもそも単純にPINとパスワードを比べてしまっている段階で間違えているんだと思います。
マイクロソフトが言いたかったのは、Windows 10で新たに採用された「Microsoft Passport」を使ったサインインは従来のIDとパスワードを使ったサインインに比べて安全である、ということを言いたかったんだと思います。

ただ、その安全性を正しく理解するには、ベースとなっているFIDOの考え方やデジタル署名やTPMなどの用語を説明し理解してもらう必要性がある中、メッセージを単純化しようとして「やりすぎた」んではないか？と私は思います。


Microsoft Passportを使ったサインインの本質は、端末内（TPM）に保存された秘密鍵を使ってデジタル署名をしたサインイン要求を、認証サーバ側にあらかじめ登録したペアとなる公開鍵を使って検証することをもって正当性を判断することにあります。

この仕組みにおいてPINなどユーザを認証するための情報（クレデンシャル）はリクエストに署名するための秘密鍵へアクセスするために端末内でだけ使われるため、ネットワーク上を流れず、従来のサインインに比べて安全である、ということです。

参考）Windows 10におけるサインイン時のフロー（Azure AD参加/Microsoft Passport利用）

これが認証サーバはデバイスを、デバイスは利用者を信頼・認証する、つまり「利用者の認証と端末の認証を分離する」というFIDO（https://fidoalliance.org/）そしてMicrosoft Passportの基本的な考え方です。

この考え方では利用者の認証手段を問いませんので、もちろん従来通りパスワードを使って問題はありませんが、
・端末内だけで使うため利便性を上げるにはシンプルな方法が望ましい
・パスワードは使いまわしや漏えいしていることが前提なのでもはや単体で使っても安全ではない
などの理由でPINがデフォルト、さらに利便性と安全性を高めるためにWindows Helloを使った生体認証を使うことが出来るように設計されているのだと考えられます。


つまり、最終的にマイクロソフトが言いたかったことは、
「安心してください、流れてませんから」
「Microsoft Passportという新しい仕組みを使うことでクレデンシャルの盗難が起きないようにしたから、パスワードのように運用上面倒なものを使わなくても安全ですよ」ということです。

少しはすっきりしましたかね。。。やっぱり難しいですね。

参考）昨年のidconで使った資料：FIDO in Windows 10
http://www.slideshare.net/naohiro.fujie/fido-in-windows10