はじめに
Webサイトへのログイン時に行われる認証の種類について整理する
1. Basic認証
1-1. 処理方式
- IDとパスワードをBase64エンコードする
- Authorizationフィールドに記載する
1-2. Base64エンコードとは
(※1)
R a i
01010010 01100001 01101001
↓
文字列を3バイトし、以下のように6ビットに編成しなおす
U m F p
010100 100110 000101 101001
各バイトの先頭2ビットに0を付加する
文字列のバイトが3の倍数にならない場合は、3の倍数になるように文字列の最後に「=」が1 or 2回登場する。
00010100 00100110 00000101 00101001
1-3. メリット・デメリット
メリット
実装が容易
デメリット
盗聴されれば簡単に解析できてしまう
1-4. Authorizationヘッダーの書き方
(※2)
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
2. Digest認証
2-1. 処理方式
(※3)
- Basic認証の改良版
- ID、パスワード、nonce、リクエストURIからハッシュ値を計算する
- 認証にはIDやパスワードは送信せず、ハッシュ値のみ送信する
- ハッシュ値の計算にはMD5やSHA-256が利用される
- サーバはユーザーから受け取ったハッシュ値と、サーバ自身で計算したハッシュ値が一致することを確認する
2-2. nonceとは
- サーバから送信されるランダムな文字列
- アクセストークンの認可でも利用される
- ITセキュリティ関連の用語で「1度きりの値」という意味を持つ
2-3. MD5とは
入力文字列に対して、128ビットの固定長ハッシュ値を算出する
特徴
異なる入力データが同じハッシュ値を持つ可能性が低い。
どのような長さの入力でも128ビットのハッシュ値を生成。
デメリット
・衝突困難性の破綻
異なる入力データが同じハッシュ値を持つ「衝突」を効率的に見つける手法が発見された
例えば、2011年の研究では、当時の2.6GHzプロセッサを使用して約10秒で衝突するペアを見つけることが可能であると報告されている
・ブルートフォース攻撃への脆弱性:
MD5の128ビットという出力長は短すぎるため、総当たり攻撃によって数日以内に解読される可能性があります。
代替案
現在ではSHA-2やSHA-3などのより安全なハッシュ関数が推奨されている
2-4. SHA256とは
- 入力文字列に対して、256ビットの固定長ハッシュ値を算出する
- SHA-256がSHA-2ファミリーの中で実装のしやすさから最も普及しているらしい
- Secure Hash Algorithmの一種
- SHA-2ファミリーというのがあり、SHA256はその一つ
対衝突性としてはMD5 < SHA256
2-5. メリット・デメリット
メリット
Basic認証よりパスワードがばれるリスクが低い。
デメリット
実装難度がBasic認証より高い
一部のサーバではサポートされていない可能性あり
【後述するBearer認証に比べた時のデメリット】
・セッションを保持するという概念がない。つまりログアウトという概念が存在しない
一度認証されると認証されっぱなしになる？
2-6. Authorizationヘッダーの書き方
(※4)
Authorization: Digest username=<username>
realm="test@gmail.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0eeigb0c093", nonce:サーバから送られてきたランダム文字列
opaque="5cc1452c4023baf9f0171e95eFf40e41"
3. Bearer認証
3-1. 処理方式
ユーザー認証後、アクセストークンを使ってサーバとやりとりをする
3-2. メリット・デメリット
【メリット】
・アクセストークンの期限設定や、リフレッシュトークンの再発行
・アクセストークンの失効できる（なりすまし等による防御策）
・認可による柔軟な権限付与ができる
【デメリット】
・アクセストークンを盗聴されるとなりすましでアクセスされてしまう。
3-3. Authorizationヘッダーの書き方
Authorization: Bearer <token>4. フォーム認証(Session管理方式)
4-1. 処理方式
Formに入力したID,Passwordをリクエストヘッダーに載せる
SessionIDをサーバとユーザーそれぞれで共有することで、どのユーザーがログインされたかを判別するようにする。
4-2. SessionIDはどこに保存されるのか
Cookie
LocalStorage
SessionStorage
IndexedDB
4-3.Authrizationヘッダーの書き方
※Session管理方式は認証ではなく、認証を維持し続けるための仕組み（※5）
そのため Authorization: ~~~ の書き方は存在しない。
ユーザー名、パスワードはリクエストボディに追加される
認証方式の整理
| 認証方式名 | ステート | 利用頻度 | |||||||||||
| Basic認証 | ステートレス | ほとんど使われない（ルーター管理画面等特殊な画面で使われていることはあるそうで） | |||||||||||
| Digest認証 | ステートレス | ほとんど使われない | |||||||||||
| Bearer認証 | ステートレス | よく使われる | |||||||||||
| フォーム認証 | ステートフル | よく使われる | |||||||||||
Webサイトにおける認証の特定方法
とあるWebサイトにて、どの認証方式が利用されているのかを特定する。
- リクエストヘッダーに「Authorization: ~~」の記述がある
⇒ Basic or Digest or Bearer - Set-Cookieがあり、「set-cookie: user_session=XXXXX」のような記載がある
Request bodyに ID/passwordの記述がある
⇒ フォーム認証（Session/Cookie方式）
参考サイト
※1 Base64とは？概要やアルゴリズムについてご紹介 – Rainbow Engine
※2 Authorization ヘッダー – HTTP | MDN
※3 ダイジェスト認証とは？仕組みやメリットなどをわかりやすく解説 – IT用語一覧
※5 【図解】セッションとは？Webサイトでユーザを識別する仕組み