ポイント ●ワンタイム・パスワードとは，一度しか使えないパスワード（使い捨てパスワード）のこと。これを実装するための仕組みを意味する場合もある。 ●事前に認証する側と，される側でハードウエアや関数を共有しておく必要がある。

　固定式のパスワードだと，セキュリティ向上のために定期的に変更したり，類推されにくい文字列を使用したりする必要がありました。逆に考えれば，「パスワードを毎回異なるものにして，意味のない文字列を使う」ことができれば理想的です。これを仕組みとして実装したものが，ワンタイム・パスワードです。

　ワンタイム・パスワードの実装は製品によってまちまちです。しかも，見たり使ったりしても内部の仕組みはわかりません。そこで，今回はワンタイム・パスワードを実現するために利用されている代表的な技術を2つ紹介します。どちらも「毎回異なるパスワードを利用する」と仕組みを実現するために，事前に認証する側とされる側でハードウエアや関数などを共有しておきます。違いはどんなハードウエアや関数を共有するかという点です。

時刻同期方式（タイムスタンプ方式）のしくみ

　その一つがタイムスタンプ方式です。タイムスタンプ方式では，利用者（認証される）側にトークンと呼ばれるパスワード生成器をあらかじめ配布しておきます。トークンにはICカードのようなものUSBキーのようなもの，キーホルダーのような形をしているもの，インストールして使用するソフトウエア・タイプなど，さまざまな形態があります。そして，このトークンには，例えば6桁の数字が表示されていて，これが時刻の経過に伴って別の数字に切り替わります。この数字がパスワードというわけです。

　ユーザーが認証を受けるときは，自分のID（識別番号）とともに，トークンに表示された数字をパスワードとしてサーバー側（認証する側）へ送信します。

　サーバー側では，誰がどのトークンを使っているか，そして各トークンがどの時刻にはどんな数値を表示するかを把握しています。そこで，サーバーはアクセスしてきた時刻と送られてきたパスワード，および識別番号を検証することにより，アクセス元が正規ユーザーかどうかを認証することができます（図1）。

図1　タイムスタンプ方式のしくみ

　なお，トークンが表示する数字を切り替えるタイミングは，より短時間になっていた方が安全は高まります。ただ，あまり細かすぎると，使い勝手が悪くなってしまいます。現在流通している製品では，1分間に1度だけ数字を変化させるのが主流のようです※1。

タイムスタンプ方式では時刻同期が必須

　このタイムスタンプ方式では，実装に当たって考えておかなければならないことがあります。それはトークンとサーバーの時刻同期です。いくら機器の性能が良くてもトークンとサーバーはまったく別の機器です。このため，時刻のズレが生じます。このズレを吸収するための仕組みが必要になるのです。ここでは時刻同期のための仕組みの一例を紹介しましょう。

　まず，すべての基準となる時刻を明確にしておく必要があります。今回は認証する機器となる，サーバーの時刻を基準にイメージしてください。

　サーバーの現在時刻に対して，トークンの現在時刻がまったく同じならば問題はありませんが，ズレは必ず生じているものです。そこで，例えば「サーバーの現在時刻に対してプラス・マイナス1分」などとズレに対しての許容範囲を決めます。

　仮にユーザーAのトークンがサーバーの時計に対して１分進んでいた（図1の状態で9:01）としましょう。このタイミングでユーザーAが認証を試みる際には「440613」という値を送信してきます。

　ここで「885139」という値が送られてくれば問題なく認証できますが，異なる値が送られてきたので許容範囲となっている前後1分のパスワードと一致するかを調べます。調査の結果9：01のパスワードと一致するので，ユーザーAのトークンは1分進んでいるのだろうと推測し，許容範囲内と判断して認証します。

　そして，サーバーはトークンとの時間のズレ（ユーザーAのトークンは１分進んでいる）を記憶しておき，次にアクセスを受けたときは自分の時刻よりも１分進んだ時刻を起点にプラス・マイナス１分を新たな許容範囲とします。

　でも，これだと久しぶりにアクセスしたときなど，時刻のズレが許容範囲を超えてしまうかもしれません。ただし，大きなズレが発生するには，通常は長い時間がかかるので，この部分は運用でカバーするのが一般的です。例えば，「最低でも1カ月に一度は必ずアクセスすること」といった規則を決めておき，誤差が許容範囲を超えてしまう前に修正するようにするのです。また，著しくズレが大きくなってしまった場合に管理者が同期の取り直しを行い，強制的に補正できるようにする製品もあります。

チャレンジ・レスポンス方式

　チャレンジ・レスポンス方式で使用されるチャレンジとは，「意味のないビット列」のことです。この値は同じものを使用せず，毎回ランダムに変化させます。

　レスポンスとは「チャレンジを計算した結果算出された答」のことです。

　この方式を利用するためには，あらかじめサーバーとクライアントでレスポンスを生成するための仕組みを共有することが必要になります。

　例えば，あらかじめ電卓のような機器（レスポンス生成器）を持っておき，送られてきたチャレンジを入力してボタンを押すとレスポンスが表示され，これを認証画面に入力する，などのような流れを想像していただければイメージしやすいでしょう。

　ここでは認証する側とされる側であらかじめ「関数」を共有していると考えて，具体的な流れを確認していきましょう（図2）。

図2　チャレンジ・レスポンス方式の仕組み

　ユーザーがサーバーへアクセス要求を送ると（1），サーバーからユーザーに意味のないビット列が送られてきます（2）。この意味のないビット列が「チャレンジ」です。ユーザー側ではこのビット列を基に，サーバー側と事前に共有している関数を使って別のビット列を算出します（3）。この算出されたビット列が「レスポンス」です。そして，このレスポンスをサーバーへ返信します（4）。

　サーバー側では，ユーザーに送ったチャレンジと自分が記憶している関数を使って（3）'独自にレスポンス（4）'を計算します。そこで，サーバーはユーザー側から送られてきたレスポンスと独自計算したレスポンスを比較します（5）。そして，これら二つのレスポンスが一致したら，事前に共有していた関数が同一であると判断できます。つまり，サーバーはアクセス元が正規ユーザーであると判断でき，認証します（6）。

　サーバー側が最初に送るチャレンジを毎回変えることで，レスポンスも毎回変化します。このことから，ワンタイム・パスワードの要件（使い捨て）を満たしていることがわかります。