ログイン
コンテキスト
「安全」と「安心」を実現するログイン機能を提供する。
安全: システムを危険にさらすことのない状態のこと。
安心: システムのユーザの心理として、危険にさらされるかもしれないと思うことなくシステムを利用できること。
Knowledge factors
人が記憶しているものを想定する。
パスワード
PIN
Possession factors
ワンタイムトークン
Inherent factors
生体認証
ソリューション
一般的に使われているログイン時の認証の組み合わせ
1. パスワード認証Only
2019年現在においても、もっとも多くのサイトで採用されているログイン方式であるが、パスワードの強度が十分でないと、攻撃に対して脆弱になるので、パスワード登録時に以下のバリデーションを強固に行う。
長さ
含む文字種
パスワードの強度をあげても、パスワードを複数サイトで使い回したり、パスワードを紙に書き出したりと、ユーザによるパスワードの運用が適切に行われないことが問題である。
2. パスワード認証 + ソフトウェアトークン
パスワード認証Onlyと同じパスワード運用をしたうえで、Possession factorsを使った2要素目の認証も実行させる。
メールでトークンを送り、これをユーザに入力させる
SMSでトークンを送り、これをユーザに入力させる
サービス全体において、この2要素認証を全ユーザに強制することはメールアドレスや電話番号が本人のものであるという確証がとれていないと難しい。だが、GitHubやSlackのようにサービス内でグループを作ることができるようなものでは、グループのポリシーとしてパスワード認証Onlyを拒否し、2要素認証を強制する設定ができるようにしておくとよい。(企業ユーザのセキュリティポリシーを満たせるように)
3. Magic Link
Posession factorsのみの認証の形態の一種である。ソフトウェアトークン付きのワンタイムログインリンクを送信し、ユーザがリンクを踏むと、ログイン成功とする。
そのサービスの利用者層を考慮したときに、パスワードが正しく運用されないことが想定される場合は、パスワード認証Onlyよりも安全なものになるが、2.と同じくメールアドレスのベリフィケーションができていることが、この方式の採用前提になる。
4. OpenId Connect
小さなサービスでパスワード認証機能を提供する場合、ユーザに「安心」を提供するのは難しい。したがって、OpenId Connectで既に「安全」と広く認識されているGoogleやLINEなどの外部サービスで認証させ、自サービスではパスワードを持たないことによって「安心」を提供する。
補足
上記コンテキストが一意に定まらない場合は、併用を考える。
実装
ソフトウェアトークン
以下のいずれかを使うとよい。
HOTP (RFC4226)
TOTP (RFC6238)
ユーザ登録時に、そのユーザ固有のkeyを発行しておく。HOTPの場合は、カウンターもユーザごとに管理する必要がある。
一般には6桁であることが多いが、Magic Linkのようにトークンを手入力することが無いものは、もっと長い列を生成してもよい。
KeyCloakによるMagic Link
Experimentalという名目であるが、以下のAddOnで実現できる。
1. Keycloakにデプロイする:
mvn clean install wildfly:deploy
2. RealmのSMTPサーバの設定をする。
3. Realmの認証フローを設定する。
ブラウザフローのコピーを作る。
"Username Password Form" と "OTP Form"を消す。
"Copy Of Browser Forms"の次のアクションをクリックし、"Addexecution"をクリックする。
"Magic Link"を追加する。
"Magic Link"を"Required"にする。
Bindingsのタブをクリックし、"Browser flow"を"Copy of browser flow"に変更する。