4. Webと認証 2016/10/24
講義資料
認証の必要性
ユビキタス社会
→ 誰もがどこでも計算機を使う
→ 計算機資源の共有がすすむ
→ どこでも認証が必要になる
認証のいろいろ
持っているものを利用
鍵、USB
自分自身の特徴を利用
生体認証
知っているものを利用
パスワード, チャレンジ質問
能力を利用
CAPTCHA
組み合わせ
銀行カード+暗証番号
生体認証+暗証番号?
Webページの認証
現在はパスワードベースがほとんど
画像認証も台頭中
パスワード認証
実装が割と簡単
認識技術が不要
パソコンでは利用しやすい
キーボードがあるから
正しく運用すれば安全
パスワードの問題点
適切なパスワードを選ぶのが困難
覚えるのに苦労する
すぐ忘れる
容易に解読される
安全な運用が難しい
簡単にコピー可能
文字入力装置が必要
認証ハードウェアの問題点
持ち歩くのが邪魔
持ち歩くのを忘れる
紛失/盗難の危険
生体認証の問題点
怪我や病気で使えなくなる
コピーされる可能性がある
変更が不可能
様々な認証
パスワードが一番マシという説も
http://gyazz.com/upload/be36ee9a3c80239387aea5e5776de6f5.pdf https://gyazo.com/dae200eef4281fe3b8e4f8dc6c9b44b9.png
ブラウザの認証
Basic認証
Digest認証
自力で認証
Basic認証のやりかた (Apache)
.htaccessに記述
code:text
AuthUserFile /home/masui/.htpasswd
AuthGroupFile /dev/null
AuthName "Password Required"
AuthType Basic
require user masui
パスワードファイルはhtpasswdコマンドで生成
平文でパスワードが流れる
.htaccessに記述
code:text
AuthType Digest
AuthName "member only"
AuthDigestDomain /server/script/digest/
AuthDigestFile /home/masui/.htdigest
require user masui
パスワードファイルはhtdigestコマンドで生成
サーバから渡されたIDをもとに暗号化
自力で認証する例
code:html
<center>
<input type="password" style="font-size:30pt;"><br>
<span style="font-size:24pt;"><input type="password" style="font-size:20pt;"></span>
</center>
HTTPSで通信
覗き見防止
パスワードのハッシュをサーバに記憶
流出防止
認証の継続
Cookieの利用が一般的
認証中を示す情報をサーバがブラウザに送る
ブラウザは認証が継続していることを毎回サーバに知らせる
Web上の証明機構
PKI (Public Key Infrastructure)
PGP (Pretty Good Privacy)
c.f. 実世界の認証機構
https://i.gyazo.com/58ba83f7368ca767ab28ffb25a368d1f.png
公証役場
公正証書の作成
私文書の認証
確定日付の付与
市役所
PKI
公開鍵暗号を使用したセキュリティ・インフラ
認証局 (Certificate Authority) を利用
https://gyazo.com/0647da8a7628a2081e047edfa16b4473.png
共通鍵の受け渡しの危険を回避
公開鍵(pk), 秘密鍵(sk)を利用
pk⇒sk、sk⇒pkを計算不可能
暗号化アルゴリズム<i>Epk</i>
復号化アルゴリズム<i>Dsk</i>
m == Dsk(Epk(x))
pkを公開
sshの場合
ssh-keygenで公開鍵と秘密鍵を生成
公開鍵 id_dsa.pub または id_rsa.pub
秘密鍵 id_dsa または id_rsa
公開鍵をサーバにコピー
パソコンに秘密鍵を保持
秘密鍵の管理は注意が必要
デモ: ssh
% ssh-keygen
SSL
Secure Sockets Layer
1994ごろNetscapeが開発
ブラウザとサーバの間で秘密通信に利用
公開鍵暗号の特徴
公開鍵を共有していれば安全な暗号化通信が可能
よく知らない相手の場合、公開鍵の正当性を検証する必要がある
認証局
公開鍵の正当性を証明 / 電子証明書発行
認証局が信用できれば、それにより署名された公開鍵を信用できる
認証局の公開鍵は充分信用できると仮定
ブラウザに登録されている
https://gyazo.com/9e9b7d53ce5f24737b725fcbe197a858.png
認証局の階層構造
https://gyazo.com/d3abed0b5c711d0bd2106c9facc4a53e.png
自前の認証局の発行する証明書
ブラウザに登録されていない
認証局に金を払っていない
証明の難しさ
情報の正当性を自力で証明するのは難しい
簡単に作成/コピーできるので
e.g. ある情報が特定の時点で存在したことを証明するのは難しい
公証役場利用
電子公証利用
電子公証の問題点
面倒
金がかかる
気楽に使えない
情報(のハッシュ)をあちこちに登録しておく
情報の存在の証明になるかもしれない
デジタルタイムスタンプ技術
時間に関係する認証
「2年後にならないと情報を公開できないデータを作れるか?」
その他いろいろありそう
オフィシャルな認証局を使わない
本人確認が済んでいる第三者によって署名されている公開鍵は「（ある程度）信用できる」と判断
知り合いに自分の公開鍵に署名してもらうことによって、自分の公開鍵の信用度を保証してもらう
Web上の個人認証サービス
FlickrAPI
TypeKey認証
はてな認証API
livedoor Auth
JugemKey認証API
Facebook のOAuth
特定サービスにパスワードを教えることなくFlickerにアクセスさせる
Flickerのパスワードで別のサービスを利用する
https://gyazo.com/5575fb6404ab2b6f6913944dfbc4456f.png
はてなアカウントによる認証を別サイトで利用
アカウント管理をはてなにアウトソーシング
直接収益なし
知名度向上や新規ユーザ獲得を期待
https://i.gyazo.com/8c320e4e21bc931f824736189f9f0b7c.png
問題点
https://i.gyazo.com/c545180dc113d2aaab03a2d664489bb0.png
各種サービスが乱立
サービスごとに仕様が違う
認証サービスが止まると困る
認証サービスの一本化/標準化
OpenID
OAath
背景技術
シングルサインオン (SSO)
認証と認可
認証 (Authentication)
認可 (Authorization)
認証
ネットワークやサーバへ接続する際に本人性をチェックし、正規の利用者であることを確認する方法。
一般には利用者IDとパスワードの組み合わせにより本人を特定する。
認証がなされると、本人が持つ権限でデータへのアクセスやアプリケーションの利用が可能となる。
不正利用を防ぐため、パスワードの漏えいなどには十分な注意が必要である。
認可
認証（Authentication）によって確認された利用者を識別して、アクセス権限の制御を行い、利用者ごとに固有のサービスを提供すること。
具体的には、利用可能なアプリケーションの制御、ファイルに対する“読み／書き／実行”の権限など、利用者の資格に応じて許可する。認可のための属性情報には、利用者ID／所属グループ／役職／部署／アクセス制御リスト（ACL）などがある。
認証を外部のサービスに任せる仕組み
自分のサービスでパスワード管理しなくてよい
シングルサインオンの標準化
ユーザの指定したURLをIDとして利用
Web用に再設計
ブラウザ利用が前提
認証のみ (認可はやらない)
OpenIDの登場人物
OP（OpenID Provider）
認証サービス提供者 (サービスプロバイダ)
RP（Relying Party）
OpenID認証利用サイト (コンスーマ)
OpenIDアカウント
ユーザ
OpenIDの原理
https://i.gyazo.com/98a5e827a405bd8d1192b65b6fd20700.png
OpenIDの原理
https://i.gyazo.com/25c180ad66415d47e5f6337848aa3e6d.png
OpenIDプロバイダ
https://gyazo.com/9b06c996489f365ae5daffd8a94c77f7.png
その他多数
上記ページのヘッダに以下を記述
code:html
<html>
<head>
<link rel="openid.server"
<link rel="openid.delegate"
voxの認証画面があらわれる
IDとパスワードを入力するとZoooomrに戻る
OpenIDの利用できるサイト
OpenIDの使い勝手
登録とセットアップが面倒
原理がわかりにくい
IDの入力が面倒
普通のID/パスワードのオマケになっている
他サイトに飛ばされるのが不思議/心配
現状
まだあまり人気がない模様
ブレイク可能??
仕様がスマートでない気配
心配事
パスワードの外部依託の問題
プロバイダの管理状況が不明
OpenIDのトレンド
https://gyazo.com/ffa849663d5a92192dc168a96e1f7f17.png
2007ごろ誕生
認可(Authorization)プロトコル
マッシュアップに有用
異なるサービス間のデータ共有をユーザが認可
e.g. TwitterのAPIアクセス権を他アプリに委譲
コンスーマ(e.g. smart.fm)がサービスプロバイダ(e.g. Google)のアクセス権を取得する
かなり複雑...
https://gyazo.com/02a7c417784367f814663dd9021f1056.png
0. ConsumerはService ProviderからあらかじめOAuth利用許可を得る
1. UserがConsumerに，Service Providerから認可が必要な情報へのアクセス権を取得するように指示する。
2. ConsumerはバックグラウンドでService Providerにアクセスし，未認可のRequest Tokenを取得する
3. ConsumerはUserをService Providerにリダイレクトさせる。この際Consumerは未認可のRequest TokenをURL Parameterに付加する
4. UserはService Provider上でConsumerへのアクセス権委譲を許可する。この際Service Providerは未認可のRequest Tokenを認可済とする
5. Service ProviderはUserをConsumerにリダイレクトさせる。この際Service Providerは認可済のRequest TokenをURLに含める
6. ConsumerはバックグラウンドでService Providerと通信を行い，認可済のRequest Tokenを実際のアクセス権を示すAccess Tokenと交換する
7. Consumerは6)で得られたTokenを利用して，特定の情報にアクセスする</span><br>
OAuth認証の例
https://gyazo.com/e5154feec4faf9726a793a39baff7068.png
OAuthのトレンド
https://gyazo.com/5ee32e560bcc66069952bcc9bc42d3ad.png
OpenID vs OAuth
https://gyazo.com/54250eb8aa215fa65f86a7b1d99c13d5.png
https://gyazo.com/f040693ab3e47621df5d5f537c86e378.png
認証サービス利用の問題点
原理が難しい!
誰もが理解して使えるのか?
詐偽されやすくならないか?
使い勝手がいまひとつ
うっかりフィッシングにひっかかりやすい
理想の認証を考える
誰でも
どこでも
簡単に
安全に
c.f. 安全と安心
安全 = 客観的
安心 = 主観的
安全とは
受け入れ不可能なリスクがないこと
安全ではないが安心しているもの
車
パスワード
鍵
安全なのに安心していないもの
化学物質
PKI?
安心するものとは
理解できるもの
慣れたもの
親しみのあるもの
歴史を経たもの
パスワードの問題点 (再)
適切なパスワードを選ぶのが困難
覚えるのに苦労する
すぐ忘れる
容易に解読される
安全な運用が難しい
簡単にコピー可能
文字入力装置が必要
認証ハードウェアの問題点 (再)
持ち歩くのが邪魔
持ち歩くのを忘れる
紛失の危険
盗難の危険
生体認証の問題点 (再)
怪我や病気で使えなくなる
コピーされる可能性がある
変更が不可能
理想的な認証
安全な運用
誰でもどこでも簡単に利用
認証デバイスを使わない
安心感がある
実現要件
脳内情報だけを利用
知識、能力、etc.
自分だけが実行できる技術を利用
⇒ エピソード記憶を利用
エピソード記憶の特徴
誰もが独自のエピソード記憶を持っている
忘れることがない
他人にはわからない
コピーできない
画像認証
記憶した画像を認証に利用
画像に関連する画像を利用
DéjàVu
自動生成した画像から認証画像を選択
https://gyazo.com/38a52f9d4f2c67eaf6f6cc7acdf3e13e.png
顔を選択
https://gyazo.com/918210f59d3892b2acdeb7aa276e9863.png
特定の点を選択
https://gyazo.com/2dbb4edc510938f3f23a0811e6b12ea6.png
PassPoints
画像のカテゴリを選択
OpenIDに対応
https://gyazo.com/a5e94fe05d651e09b942566eba50684b.png
三角形方式
自分の画像を頂点とする三角形の内側の画像を選択
覗き見対策
https://gyazo.com/351a3b2722a7f524c2271812f07308c5.png
GATESCEME
画像と数字を一緒に覚える
Recall-a-Story
画像に関連する物語を覚えておく
MARASIM
https://gyazo.com/7cc969827bd1b4d58449afc0b6daeafa.png
自分の知識にマッチする画像を選択
知識は別の画像を利用
https://gyazo.com/75adce63e0ef68b5e2e41aac155cab96.png
潜在記憶を利用するもの
https://gyazo.com/936884a1c4ed1dfec042c2e2d5fb501b.png
画像認証システムの問題点
記憶が持続すると思えないものが多い
異常に手間が多いものが多い
なぞなぞ画像認証
個人的記憶と結び付いた画像から問題を生成
正答を選ぶと認証成功
デモ
なぞなぞ画像認証の利点
忘れない
入力が簡単
認証レベルを設定できる
グループで利用できる
なぞなぞ画像認証の問題点
問題作成が面倒
安心感が欠如
エピソード記憶からパスワードを生成
なぞなぞ問題に答えてシード文字列をパスワード文字列に変換
http://EpisoPass.com https://gyazo.com/795316ca9f1305f4e41c5f095a0197e0.png
https://gyazo.com/ab3311de2243602584f0c262692f6fb1.png
EpisoPassの利点
パスワード生成に必要なあらゆる情報を公開可能
紛失の心配がない
パスワードを忘れることがない
どのようなマシンでも利用できる
既存パスワードも利用できる
シードが変わる
認証とヒューマンファクター
安全性の検討は多い
暗号の強度
認証の強度
ヒューマンファクターの議論が不充分
安心感
使いやすさ
運用上の問題
安心感
安心するためには理解が必要
パスワード?
暗号?
公開鍵?
認証局?
OpenID?
安全性が全くわからない
⇒ 安心できない
使いやすさ
インストールが面倒
毎回使うのが面倒
パスワードが覚えられない
⇒ 安全性を犠牲にしがち
運用上の問題
パソコンに重要情報が入りすぎ
ブラウザがパスワードを記憶
秘密鍵
sshのキー
パソコンを盗まれると大変困る
盗まれた後の対策が難しい
c.f. s/key
マシン毎にインストールが必要
毎回チャレンジ/レスポンスが必要
通信が暗号化されるわけではない
sshでは通信がすべて暗号化
現在は廃れてしまった?
システム/人間を総合的にセキュリティを考える
重要概念だが流行っていない
必要技術
人が安心できる方式
安全性を評価する技術
情報セキュリティ心理学とトラスト研究会
心理学な面からセキュリティを考える
2011年から活動
会員少ない
https://gyazo.com/a082e9d54a3f2e778c516bb82c47a376.png
将来展望
各種の新しいサービスが出現中
もっと良い認証/暗号化に期待
http://mypico.org/ http://gyazo.com/deca5de3a60363eaa7d6b14a70f5ca5c.png
Cambridge大学のパスワード撲滅システム
共同研究者として参加 (2016春学期)
認証端末を利用することでパスワード問題を解決
ビデオ: Pico
Android版Pico
Gyazo.comに簡単ログインする実験
![height=400]](https://gyazo.com/eb52cc445b41c141dae0c2425b962d19.png){kind=link}
![height=400]](https://gyazo.com/81ebd8dd7d8957b7a8418f515d42f7e9.png){kind=link}
![height=400]](https://gyazo.com/80cf70536ce29eb3e8afcde8e93f30f6.png){kind=link}