😸
登壇ノート「ユーザ認証の遷移と基礎知識」
以下のイベントの登壇ノートです。
認証：認証 & 承認 & セッション管理
- Authentication（認証）：ユーザが「誰であるか」を証明するプロセス
- Authorization（承認）：特定ユーザが「何ができるか／何が見えるか」を判断するプロセス
- Session 管理：認証情報を元にした状態管理（ログイン状態など）
- なぜ区別が重要か（責任分離、安全設計、誤用防止等）
Authentication（認証）
認証とは
- HTTP/ウェブの標準仕様として最初の認証（と思われる）「Basic認証」
- Apacheのデフォルト機能としての
.htpasswd- 最低限の認証を考えるなら、権限の
boolean - Base64エンコード / 平文保存処理 / セッション管理なし！
- 「流出してもいいセキュリティ」で現在でも使われる
- 最低限の認証を考えるなら、権限の
- Apacheのデフォルト機能としての
- 認証は「この鍵があうかどうかのプロセス」に例えられることが多い
- 入室権限があるかどうか。なので厳密には、認証 = 一意の特定ではない
- 鍵を紛失したら、鍵自体の取り替えするよね。そういうこと。
ユーザ認証へのステップアップ
-
個人ごとに鍵が違うのがユーザ認証
-
主な方式
- 実装者リスクが多い
- パスワード認証（辞書=一意なキーワード + パスワード）
- 実装者リスクが少ない
- スマホアプリに多いUUID認証
- 多要素認証 (MFA, 2FA)
- OAuth / OpenID Connect
- パスワードレス認証
- 実装者リスクが多い
-
パスワード認証の一般的な実装
- メールアドレス + パスワードのペア
- なぜメールアドレス？
- 所有者確認ができて一意である
- パスワード忘れた時に、再設定用URLを送信できる
- マーケティング用のメールアドレスを別途聞かなくていい
- ユーザが忘れにくい（ことを期待できる）
- なので、根本的にはユーザ名等一意であれば何でもいい
- なぜパスワード？
- 本人しか知っていないと期待できる
- 特別なデバイス等必要ないので、ユーザにとってアカウント作成コストが低い。
-
実装者のリスク
- 鍵のペアを実装者が持つため、流出リスクを常に抱える
- リスクを下げるための「マナー」
- 知るべきではない情報は、管理者であっても知らないべき
- パスワードを忘れたと問い合わせが多いので、パスワードは見れる方が便利
- パスワードは知らないべきなので、パスワード再設定機能をつくりましょう
- ユーザIDとパスワードを照合するために
- ハッシュ化（暗号化と違い復元不可能）な状態で照合する
- ユーザIDは一意性を保つために平文で保存し、パスワードのみハッシュ化
- 同じパスワードでも異なるユーザを区別するためにユーザIDが必要
- 知るべきではない情報は、管理者であっても知らないべき
- 「メールアドレス + パスワード」の組み合わせは、使い回しが多いので、流出したら他サイトでログインできる可能性がある
- パスワードを復元不可能な状態で保存してたら本当に大丈夫？
- 「パスワードの加工前」に注目
- パスワードの複雑さ
- ブルートフォース攻撃、辞書攻撃対策
- パスワードリセットも実装によってはセキュリティリスクあったりも・・・。
-
せっかく実装の話をしたので、承認 & セッション管理の話も
-
承認
- 認証：鍵穴に鍵があうか / 承認：どの部屋まで入れるか
- 承認の代表的モデル
- ロールベース：役割（AWS IAMとかわかりやすい）
- 属性ベース：部署や位置情報、決済情報の有無等
- アクセス制御リスト：リソース毎に設定。正直やってられない
-
セッション
- 通信の度に、鍵を必要とすると、鍵をユーザも保存しないといけない
- 当然、暗号化前。まぁ、ありえないよね
- 鍵の代わりとなる入室許可のイメージ
- サーバーサイドセッション or トークンベース（ステートレス）
-
では、実装者リスクが少ない方式の方が優れてる？
- スマホアプリに多いUUID認証
- 多要素認証 (MFA, 2FA)
- OAuth / OpenID Connect
- パスワードレス認証
-
外部サービスを使って認証しよう
- Firebase Authentication
- Auth0
-
プライバシーポリシーと開示請求
- 電気通信事業者の開示義務
- プロバイダ責任制限法
- 認証を自分で実装することはコスト以上にリスクを抱えることになる
- 責任の限界分岐点をつくろう
Discussion