アーカイブ

第3章 1.アクセス制御: 本人認証

公開日:2007年9月26日

独立行政法人情報処理推進機構
セキュリティセンター

本ページの情報は2007年9月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。

アクセス制御は、許可された人物のみがデータやプログラムにアクセスできるようユーザのシステム利用に一定の制限をかける仕組みである。これはシステムのセキュリティ確保の目的で積極的に構築されるべき機能であり、重要なものである。アクセス制御の設計・実装に不備があったり機能そのものが欠如していると、システムおよびその中のデータが侵害を受ける。

アクセス制御は、本人認証とアクセス認可の2段階からなる

  • 図3-1: アクセス制御における本人認証

本人認証

本人認証は、アクセスしてきている人物がどのユーザであるかを識別し、その人物が本人であることを確認する手続きである。

本人認証には複数の方式があるが、どの方式の場合も次のふたつのものをユーザから受け取って判定を行う。

  • ユーザを一意に識別する情報
  • 本人しか提示できない秘密情報

本人認証の方式

本人認証には複数の方式がある。

(1) 固定パスワード

1) 固定パスワード

よくある本人認証方式として、ユーザIDと固定パスワードを用いる方式がある。固定パスワードとは、本人認証手続きのたびに値が変化することのないパスワードのことである。

2) 固定パスワードを破る試み

固定パスワードには、次のようなパスワード破りの手口およびそれらへの対策が知られている。

手口1. 異なるパスワードを次々と試行する

バリエーション: 辞書攻撃、総当たり攻撃
→ 対策:アカウントのロック
→ 対策の迂回手口:
  リバース攻撃=パスワードを固定して、ユーザIDを次々と変えてログインを試みる

手口2. ユーザ本人からパスワードを盗んで使う

→ 対策:パスワードの変更。
    自身のログイン履歴を参照可能にして他者の使用に気づけるようにする
→ 対策:固定パスワード以外の認証方式を使う、あるいは併用する

手口3. システムのユーザ登録簿を盗む

→ 対策:登録簿上のパスワードはハッシュ値あるいは暗号化された値にする
→ 対策の迂回手口:ハッシュ値破り
→ 対策:ユーザ登録簿を隠す

(2) チャレンジ・レスポンス

パスワードに毎回同じ値を用いたとしても、ネットワーク上を毎回同じ認証データが流れないように工夫された方式。

サーバがチャレンジと呼ばれるデータをクライアントに送り、クライアントはユーザが入力したパスワードとこのチャレンジの値に特定の演算を施してレスポンスをサーバに返す。

(3) ワンタイム・パスワード/使い捨てパスワード

本人認証手続きを行うごとに異なるパスワードを使い、二度と同じものを使わない方式。パスワードを生成するトークン(小さなデバイス)やソフトウェアモジュールを使う。ワンタイム・パスワードには次のようなバリエーションがある。

  • 時間同期型
    • 時刻にもとづいて払い出されたパスワードを、ユーザがサーバに送る方式
  • カウンタ同期型
    • 番号に対応づけられて払い出された一連のパスワード群の中から、サーバが示す番号に対応するものを選び、ユーザがサーバに送る方式
  • チャレンジ・レスポンス型
    • 上記の「チャレンジ・レスポンス」を実装したデバイスやソフトウェアを用い、算出したレスポンスをユーザ自らがサーバに送る方式

(4) SSLクライアント・ディジタル証明書

SSL、あるいはTLSを用い、サーバ側、クライアント側ともディジタル証明書を使う方式。

(5) バイオメトリクス認証

生物学的特徴を測定し数値化するデバイスを使い、そこで得られるパラメータを本人確認に用いる方式。

(6) その他の方式

  • ソフトウェアキーによるパスワード入力
  • マトリックス認証等

認証結果データを安全に維持する

ユーザがいったん本人認証に合格したら、合格したことを示すデータ──ここでは「認証結果データ」と呼ぶことにする──を十分安全に扱う必要がある。

(1) 認証結果データを隠す

認証結果データは、ユーザ本人や第三者の手の届かない、安全な場所に保持することが重要である。

認証結果データをユーザによる閲覧・書き変えの可能な記録媒体に置いていると、他のユーザを示す値への書き変えを行ってなりすましを行う機会を与えることになる。

(2) 認証結果データの露出対策

ソフトウェア・システム内に安全に認証結果データを保持できる場合は、その値としてユーザIDや整数値等の単純な値を使い、それをそのまま置いておくことができる。しかし、認証結果データをユーザの目に触る場所に置かざるをえない場合、次のような考慮が必要となる。

  • 他のユーザが認証結果データを目にしないようにする
    • 例えば、クライアント・サーバ・システムにおいて認証結果データをクライアント側に預けることにしている場合、クライアント・サーバ間の通信全体を暗号化する必要がある。認証結果データのみ単独で暗号化するのでは問題がある。暗号化された値でも、それを盗み見られてリプレイされ得るからだ。
  • ユーザ本人も認証結果データの成り立ちを容易に推測できないようにする
    • クライアントに預ける認証結果データは、例えば疑似乱数を用いて値を作る。可能なら「暗号学的に安全」とされるアルゴリズムを用いる。これはユーザが認証結果データの成り立ちを推測して別人の認証結果データをねつ造することを困難にするためである。
  • 毎回異なる値を用いる
    • 同一のユーザに対しても、認証結果データの値はユーザ認証を実施するたびに異なる値が発行されるようにする。毎回同じ値を使っていると、それを知った第三者は繰り返しその値を使ってなりすましを行う機会を得る。