JP5419960B2 - サーバを操作する方法、サーバ自体、ならびに該サーバを操作するコンピュータ・プログラム製品及びコンピュータ・プログラムにおける期限切れパスワードの処理（期限切れパスワードの処理） - Google Patents

Description

本発明は、サーバを操作する方法、サーバ自体、ならびに該サーバを操作するコンピュータ・プログラム製品及びコンピュータ・プログラムに関するものである。特に、本発明は、サーバを操作する方法、サーバ自体、ならびに該サーバを操作するコンピュータ・プログラム製品及びコンピュータ・プログラムにおける期限切れパスワードの処理に関するものである。

サービスに電子的にアクセスする際は一般に、アクセスを行う当事者を識別するために許可が必要とされる。例えば、多くの銀行口座は、インターネットを介した遠隔アクセスが可能である。ユーザは、各自の銀行口座にアクセスするにあたり、個人のＩＤを許可するのに使用されるユーザ名及びパスワードを、銀行口座に対するアクセスを提供するサーバに供給しなければならない。サーバは、ユーザ名（必ずしもセキュアである必要はない）と、パスワード又はパスワードのダイジェスト（セキュア）とを記憶し、受信されたパスワードを記憶済みのパスワード又はダイジェストと突き合わせて検査する。

許可プロセスをより強固なものにするために、パスワードの寿命を制限することが一般に行われている。多くのシステムでは、パスワードがユーザによって初めて選択されると、そのパスワードは所定の長さの時間だけ有効とされる。この時間は、例えば９０日とされる可能性がある。この期間中であれば、ユーザは、各自のユーザ名及びパスワードを使用することによって電子サービスにアクセスすることができるが、制限された寿命期間が経過すると、そのパスワードを使用してサービスにアクセスすることはできなくなる。この時点で、パスワードは期限が切れているといわれる。ユーザが所望のサービスに対するアクセスを継続するには、古いパスワードの代わりに新しいパスワードを提供する必要がある。

例えば、米国特許第６８２６７００号は、既存のパスワードの期限が切れている場合にウェブ・アプリケーション・サーバが新しいパスワードを自動的に要請する方法及び装置を開示する。この特許には、ワールド・ワイド・ウェブと結合されたインターネット端末を利用してダイアログ・ベース要求フォーマットを有する既存のプロプライエタリ・データベース管理システムにアクセスする装置及び方法が開示されている。インターネット端末は、パスワードを必要に応じて提供するデータベース管理システムにサービス要求を転送する。期限切れパスワードを有するサービス要求が行われたときは、データベース管理システムは問題を認識する。インターネット端末に対して一定のパラメータの有無が照会され、データベース管理システムは、期限が切れていない新しいパスワードを自動的に再割り当てする。

米国特許第６８２６７００号

RFC2617,HTTP Authentication: Basic and Digest Access Authentication（http://www.ietf.org/rfc/rfc2617.txt） RFC1123,Requirements for Internet Hosts -- Application and Support（http://www.ietf.org/rfc/rfc1123.txt） RFC822,Standard for the format of ARPA Internet text messages（http://www.ietf.org/rfc/rfc822.txt）

期限切れパスワードを処理する既知の方法は、改良が可能である。上記の特許に記載されるようなシステムは、複雑であるだけでなく、いくつかの既存のネットワーク通信規格と互換性がない。また、ネットワークのクライアント・サイドでより高い柔軟性がサポートされる、期限切れパスワードの処理方法も必要とされている。

したがって、当業界では上述の課題を解決することが必要とされている。

本発明の第１の態様によれば、サーバを操作する方法であって、パスワードを含む許可要求を受信するステップと、前記パスワードの有効期限にアクセスするステップと、前記有効期限を含む応答を送信するステップと、前記パスワードの期限が切れているかどうかを確認するステップと、前記パスワードの期限が切れている場合は新しいパスワードを受信するステップと、を含む方法が提供される。

本発明の第２の態様によれば、サーバであって、パスワードを含む許可要求を受信し、前記パスワードの有効期限にアクセスし、前記有効期限を含む応答を送信し、前記パスワードの期限が切れているかどうかを確認し、前記パスワードの期限が切れている場合は新しいパスワードを受信するように構成されるサーバが提供される。

本発明の第３の態様によれば、サーバを操作する、コンピュータ可読媒体上のコンピュータ・プログラム製品及びコンピュータ・プログラムであって、パスワードを含む許可要求を受信する命令と、前記パスワードの有効期限にアクセスする命令と、前記有効期限を含む応答を送信する命令と、前記パスワードの期限が切れているかどうかを確認する命令と、前記パスワードの期限が切れている場合は新しいパスワードを受信する命令と、を含む、コンピュータ・プログラム製品及びコンピュータ・プログラムが提供される。

本発明の好ましい一実施形態は、期限が切れたパスワード及び無効化されたパスワードを処理することが可能な改良されたメッセージ要求／応答転送プロトコルを提供する。新しいヘッダを使用してサーバが新しいプロトコルに参加するかどうかが指示される。これに基づいて、クライアント・デバイスは、それ自体が新しいフォーマットの応答ヘッダをサーバに送信してもよいことを判断すると同時に、パスワードの期限が切れているかどうか、あるいはパスワードが無効化されているかどうかを判断することができ、パスワードの期限が切れる場合に新しいパスワードを先見的に送信することが可能となる。

本発明によれば、メッセージ要求／応答転送プロトコルにおいてパスワードを処理し、それらの期限切れに対処する柔軟なシステムを提供することが可能となる。サービス・アクセス要求が行われ、その要求がパスワードを含む場合は、有効期限のようなパスワード・ステータス情報を含む応答がサーバから常に返されることになり、その結果、クライアント・デバイスは、パスワードの現在のステータスを監視し、クライアント・ソフトウェアからエンド・ユーザに対してクレデンシャルを求めるプロンプトが出される手法を修正することを含めて、クライアント・デバイスが適切と考える形で情報を処理することが可能となる。有効期限を含む応答は、パスワードが実際に期限切れとなっているか否かに関わらず、サーバからクライアント・デバイスに送信され、その結果、クライアント・デバイスは必要に応じて事前措置を講じることが可能となる。この応答は、ハイパー・テキスト転送プロトコル（ＨＴＴＰ）のような現行規格の範囲内で有効期限をヘッダに含めることができる。

送信される前記応答は更に、前記パスワードの最後の使用を表す日付、又は再試行パラメータを表す整数値、あるいはその両方を含むことが好ましい。クライアント・デバイスに返送される応答に更なる情報を追加すれば、ユーザ・パスワードの期限切れ（又は期限の切迫）に対処する点でクライアント・デバイスが利用可能な選択肢の範囲が広がることになる。

有利なことに、前記プロセスは、新しいパスワードを含む要求を受信するステップと、前記新しいパスワードが受け入れられないことを確認するステップと、前記再試行パラメータを表す前記整数値を含む応答を、前記整数値を変更せずに送信するステップと、を更に含む。前記再試行パラメータは、セキュリティ対策として使用することができるが、何らかの理由で（例えば古いパスワードとの類似性が高すぎる等の理由で）受け入れられないと判断された新しいパスワードが提示された場合は、前記再試行パラメータは減分されない。

理想的には、前記プロセスは、古いパスワードを含む要求を受信するステップと、前記再試行パラメータを表す前記整数値を含む応答を、前記整数値を１だけ減分して送信するステップと、を更に含む。パスワードの期限が切れた後に古いパスワードが再提示された場合は、アクセス要求が拒否され、減分された再試行パラメータが送信される。これにより、前記再試行パラメータがゼロまで低下した場合はサーバ側のサービスにアクセスするプロセスが完全に拒否される恐れがあることが、クライアント・デバイスに警告される。

以下では単なる例示として、添付図面を参照しながら本発明の諸実施形態について説明する。

クライアント・デバイス及びサーバを含むシステムの概略図である。 クライアント・デバイスとサーバの間の通信を示す図である。 サーバを操作する方法のフローチャートである。 図１のシステムの別の概略図である。

図１は、ネットワーク１４を介してサーバ１２と接続されるクライアント・デバイス１０を備えるシステムを示す。クライアント・デバイスは、図１により詳細に示されるディスプレイ１６を有する。ユーザは、各自のクライアント・デバイス１０を利用して、サーバ１２によってホストされるサービスにアクセスする。ディスプレイ１６内に示されるように、ユーザは、各自のユーザ名及びパスワードを入力することによってサービス・アクセスの許可を得る必要がある。図１に示されるシステムでは、クライアント・デバイス１０がパーソナル・コンピュータとして示されているが、クライアント・デバイス１０は、携帯電話や適切に動作可能化された携帯情報端末（ＰＤＡ）のようなモバイル・デバイスとすることも当然可能である。同様に、広域ネットワーク（インターネット）として示されるネットワーク１４もイントラネットのようなローカル・ネットワークとすることが可能である。サーバ１２は、ユーザのユーザ名を各自のパスワード又は各自のパスワードから導出される他の何らかのデータ（パスワードのダイジェスト等）と共に記憶し、ユーザがサーバ１２から提供されるサービスに対するアクセス試行を行ったときは、これらのデータを使用してユーザ許可が行われる。

クライアント・デバイス１０とサーバ１２の間の通信は、例えば事前定義されるハイパー・テキスト転送プロトコル（ＨＴＴＰ）のようなメッセージ要求／応答転送プロトコルによって処理される。ＨＴＴＰプロトコルでは、ユーザが各自の認証を行ってサーバ１２のようなセキュアなＨＴＴＰサーバを使用することを可能にする２つの方法が識別される。これらは、ＲＦＣ２６１７（RFC2617,HTTP Authentication: Basic and Digest Access Authentication（http://www.ietf.org/rfc/rfc2617.txt）参照）に記載されるベーシック認証（BasicAuthentication）方式及びダイジェスト認証（Digest Authentication）方式である。これらの方式では、クライアント・デバイス１０によって実行されるＨＴＴＰクライアント・ソフトウェア（通常はウェブ・ブラウザ）からエンド・ユーザに対して各自のクレデンシャル（ユーザ名及びパスワード）を求めるプロンプトが出され、その後、各クレデンシャルがエンコードされた後、サーバ１２に送信される。

いずれの方式でも、サーバ１２は、クレデンシャルが有効なレルム名を含むWWW-Authenticateヘッダが収容されたHTTP 401メッセージを返すことにより、認証チャレンジを開始する。ダイジェスト認証方式では、サーバ１２は、nonce値（任意のバイナリ値）もクライアント・デバイス１０に送信し、クライアント・デバイス１０は、ユーザ名、パスワード、nonce値、ＨＴＴＰメソッド、及び要求されたユニフォーム・リソース・ロケータ（ＵＲＬ）の暗号チェックサム（ダイジェスト）を返さなければならない。ベーシック認証方式では、nonceは使用されず、クライアント・デバイス１０は、通常は暗号によって秘匿されないが、パスワードが偶然突き止められるのを防止するためにトリビアルにエンコードされたユーザ名及びパスワードを単に返すだけである。

これらの方式はいずれも、ユーザ名毎に一意のパスワードが存在し、それらが一旦確定されれば、クライアント・デバイス１０によって実行されるクライアント・ソフトウェアがクレデンシャルをキャッシュすることが可能となり、それらのクレデンシャルをＨＴＴＰ要求がサーバ１２に送られる度に繰り返し提示できるようになることを想定している。ダイジェスト認証方式を用いると、nonceを失効させることが可能となり、また、ユーザに対して新しいクレデンシャルを求めるプロンプトを出す必要なくnonceをリフレッシュすることが可能となる。

しかしながら、ＩＢＭ（Ｒ）ｚ／ＯＳ（Ｒ）Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｅｒ（ＲＡＣＦ（Ｒ））及び一部のＵＮＩＸ（Ｒ）実装環境を含めた他の現行のパスワード・ベース・セキュリティ・システムでは、多くの場合、ユーザ名とパスワードの関連付けは永続的でない（「ＩＢＭ」及び「ｚ／ＯＳ」は、インターナショナル・ビジネス・マシーンズ社の米国又は他の国あるいはその両方における商標であり、「ＵＮＩＸ」は、Ｔｈｅ Ｏｐｅｎ Ｇｒｏｕｐの米国及び他の国における登録商標である）。このようなシステムでは、パスワードが固定の日数後に期限切れとなる可能性があり、サーバ１２へのアクセスを継続するための新しいパスワードをエンド・ユーザに対して求めるプロンプトを出さなければならなくなる。更に、ユーザが少ない試行回数で有効なパスワードを供給することができない場合はユーザ名が無効化され、それ以降は正しいパスワードが入力されたか否かに関わらず、そのユーザ名を使用する試行を行うことはできなくなる。

現状では、（ＨＴＴＰの）ベーシック認証方式もダイジェスト認証方式も、期限が切れた又は無効化されたパスワードに対処することはできない。図１のシステムは、こうしたパスワード状態をサポートする拡張機能を各方式に提供するように構成することができる。サーバ１２がパスワード・ステータス情報をクライアント・デバイス１０に返すことが可能となるメカニズムが提供される。その後、クライアント・デバイス１０は、パスワード・ステータス情報をそれ自体が既に保存しているクレデンシャルと共に記憶することができる。このパスワード・ステータス情報を使用して、クライアント・デバイス１０によって実行されるクライアント・ソフトウェアからエンド・ユーザに対してクレデンシャルを求めるプロンプト、特に期限切れパスワードの置き換えを促すプロンプトが出される手法を修正することができる。

サーバ１２が期限が切れた又は無効化されたパスワードを管理することが可能であることをクライアント・デバイス１０に知らせたい場合、サーバ１２は、クレデンシャルが収容されたＨＴＴＰ要求に応答してPassword-Expiryヘッダを送信する必要がある。Password-Expiryヘッダには以下の内容が収容される。

オプションのretries=nnパラメータは、誤ったパスワード試行が何回まで許容されるかを指示する。サーバ１２は、任意選択でパスワードの最後の正常な使用を記述する情報ヘッダも送信することができる。

日付スタンプ

及び

は、それぞれＲＦＣ１１２３フォーマットである（日付／時刻フォーマットに関するRFC1123,Requirements for Internet Hosts -- Application and Support（http://www.ietf.org/rfc/rfc1123.txt）参照）。これらの２つのヘッダの例を以下に示す。
Password-Expiry: Thu,01 Mar 2007 00:00:00 GMT; retries=5
Password-Last-Used:Fri, 16 Feb 2007 17:45:20 GMT

サーバ１２からPassword-Expiryヘッダが送信される場合は、サーバ１２が拡張Authorizationヘッダ内の新しいパスワードを受け入れる準備が整ったことが指示される。新しいパスワードの指定フォームは、認証方式がベーシックであるのかそれともダイジェストであるのかに依存する。以下、クライアント・デバイス１０から送信されるフォームについて詳述する。

サーバ１２が受け入れられない新しいパスワードを含む拡張Authorizationを受信した場合、サーバ１２は、Password-Expiryヘッダが収容されたHTTP 401応答を返す必要があるが、retries値は変更されないままである。（古いパスワードが受け入れられない場合は、retries値が１だけ減分されることになる。）

クライアント・デバイス１０がPassword-Expiryヘッダを受信した場合、クライアント・デバイス１０は、有効期限及び再試行カウント（供給された場合）を記録する必要がある。再試行カウントがゼロである場合は、ユーザ名が無効化されていること、及びクライアントがそれ以上許可試行を行ってはならないことが指示される。有効期限が本日の日付（又はそれ以前）である場合は、クライアント・デバイス１０によって実行されるクライアント・アプリケーションは、エンド・ユーザに対して新しいパスワードを求めるプロンプトを直ちに出し、その新しいパスワードを後述の拡張Authorizationヘッダのうちの１つにエンコードしなければならない。

有効期限が近く、構成可能な日数以内である場合は、クライアント・デバイス１０によって実行されるクライアント・アプリケーションは、パスワードの期限が切れかかっていることをエンド・ユーザに知らせ、新しいパスワードを承諾し送信するよう提案することができる。エンド・ユーザが新しいパスワードの提供を拒んだ場合には、ベーシック認証又はダイジェスト認証を適宜使用して、新しいパスワードなしで認証が継続される。一方、エンド・ユーザが新しいパスワードを提供した場合には、新しいパスワードを後述の拡張Authorizationヘッダのうちの１つにエンコードする必要がある。

サーバ１２からPassword-Expiryヘッダが送信されない場合は、サーバ１２が拡張Authorizationヘッダを受け入れる準備が整ったことが指示されないので、クライアント・デバイス１０は、拡張Authorizationヘッダを送信してはならない。クライアント・デバイス１０がPassword-Last-Usedヘッダを受信した場合には、クライアント・デバイス１０は、その内容を、該当するパスワードが許可されたユーザによって最後に指定された時点から使用されていないことの確認として、エンド・ユーザに表示することができる。ただし、このヘッダは、認証チャレンジにも新しいパスワードの提供にも関与しない。

サーバ１２からパスワード変更に対するHTTP 401応答が送信され、パスワード有効期限及び再試行カウントが変更されないままとなった場合は、該当する新しいパスワードが受け入れられないことが指示され、したがって、エンド・ユーザに対して別の新しいパスワードを求めるプロンプトが出されることになる。クライアント・デバイス１０が新しいパスワードをサーバ１２に送信した後に、サーバ１２からHTTP 200OK応答を受信した場合は、古いパスワードは破棄され、指定のサーバに関してキャッシュされたクレデンシャル内の古いパスワードは、正常に有効化された新しいパスワードに置き換えられることになる。同じサーバ１２に対する後続の要求では、（そのパスワード自体の期限が切れるまで）新しいパスワードだけが送信されることになる。

図２は、ユーザがパスワードを使用して要求を行う状況でクライアント・デバイス１０とサーバ１２の間で行われる通信を示す概略図である。まず、ユーザは、クライアント・デバイス１０を利用してサーバ１２から提供されるサービスに対するアクセス要求を行うことによってサーバ１２に接続する。次に、サーバ１２は、ユーザの権限詳細（ユーザ名及びパスワード）をクライアント・デバイス１０に要求することによって応答する。クライアント・デバイス１０は、それ自体のユーザ名及び現在のパスワードを返す。次に、パスワードの期限が切れているか否かに応じて、サーバ１２は、有効期限を伴うヘッダが収容された応答を含むメッセージを返す。パスワードの有効期限が既に切れている場合は、ユーザは新しいパスワードを供給しなければならない。ユーザがこれを行うと、新しいパスワードがクライアント・デバイス１０からサーバ１２に送信され、この時点でユーザは所望のサービスにアクセスすることが許可される。

ＨＴＴＰのベーシック認証方式における新しいパスワードの指定は、以下のように行われる。ベーシック方式において、新しいパスワードは、それ自体をAuthorizationヘッダのベーシック・クレデンシャルに含めることによってエンコードされる。

この場合、新しいパスワードを提供するためのＲＦＣ８２２（拡張バッカス・ナウア記法（augmentedBackus-Naur Form）構文に関するRFC822, Standard for the format of ARPA Internet textmessages（http://www.ietf.org/rfc/rfc822.txt）参照）で定義される拡張ＢＮＦ構文は、以下のようになる：

換言すると、期限切れの古いパスワードがユーザ名の後にコロンを置いて付加されるのと同様に、新しいパスワードも古いパスワードの後に第２のコロンを置いて付加される。その結果は、ｂａｓｅ６４エンコーディングを使用してエンコードされる。

ダイジェスト認証方式における新しいパスワードの指定では、古いパスワードが通常暗号によって秘匿されるのと同様に、新しいパスワードも暗号によって秘匿されなければならない。このような秘匿は、新しいパスワードのダイジェスト化では達成することができないが、適切な暗号鍵が考案され得る場合は、新しいパスワードを暗号化することによって達成することができる。クライアント・デバイス１０とサーバ１２は共に期限が切れるパスワードを認識しているので、このことを利用して、新しいパスワードを暗号化する鍵として使用され得る共有シークレットを生成することが可能となる。

この場合、暗号化された新しいパスワードの生成用に提案されるアルゴリズムは、以下のようになる。
・ＲＦＣ２６１７に記載されるように、典型的にはストリングusername:realm:passwordのＭＤ５ハッシュであり、次のステップで暗号鍵として使用される共有シークレットＨ（Ａ１）を計算する。
・新しいパスワードをＡＥＳ暗号化アルゴリズムを使用して１２８ビットの鍵で暗号化する。
・暗号化された結果をｂａｓｅ６４エンコーディングを使用してエンコードする。

その後、ＨＴＴＰ設定では、ｂａｓｅ６４エンコード結果を、通常はHTTPDigest Authorizationヘッダの形で送信されるパラメータに追加的なnewpasswordキーワードとして渡すことができる。

ＨＴＴＰのダイジェスト認証方式における新しいパスワードの復号化が行われる。newpasswordパラメータが上述のAuthorizationヘッダに含まれる場合、パスワードは、それ自体の暗号化に使用されたプロセスと逆のプロセスによって復号化されることになる。即ち、
・古いパスワードの２０バイトのＳＨＡ‐１ダイジェストを生成する。
・その結果得られたダイジェストの下位１６バイトを使用して１２８ビットの復号鍵を取得する。
・ｂａｓｅ６４エンコードされた新しいパスワードをデコードする。
・デコードされた新しいパスワードをＡＥＳ復号化アルゴリズムを使用して１２８ビットの鍵で復号化する。

このようにして、新しいパスワードを暗号化形式で単純且つ効率的に作成し送信することが可能となる。クライアント・デバイス１０とサーバ１２の間で暗号化チャネルをオープンする必要はなく、また、クライアント・デバイス１０又はサーバ１２に課されるストレージ又は処理要件が高まることもない。

図３は、サーバ１２からクライアント・デバイス１０に対する有効期限を含むヘッダの通信に関する上述のプロセスをより詳細に示す。このプロセスは、サーバ１２によって実行される。サーバ１２を操作する本方法は、まず、パスワードを含む許可要求をクライアント・デバイス１０から受信するステップＳ１を含む。次に、ステップＳ２で、サーバ１２は、受信されたパスワードの有効期限にアクセスし、ステップＳ３で、有効期限を含むＨＴＴＰメッセージ内のヘッダのような適切なフォームの応答を、クライアント・デバイス１０に送信する。有効期限は、パスワードの期限が切れているか否かに関わらず、サーバ１２からクライアント・デバイス１０に返される。これによりクライアント・デバイス１０の様々な構成がサポートされ、その結果、クライアント・デバイス１０は、パスワードの期限が切れる前に必要に応じて措置を講じることが可能となる。クライアント・デバイス１０は、例えばユーザのパスワードがもうすぐ期限切れになることをユーザに警告することができる。

サーバ１２を操作する本方法は更に、パスワードの期限が切れているかどうかを確認するステップＳ４と、パスワードの期限が切れている場合は新しいパスワードを受信するステップＳ５と、を含む。サーバ１２は、パスワードの期限が切れているかどうかを検査し、そのパスワードが受け入れられないものとなっている場合は、新しいパスワード手順をトリガし、又はクライアント・デバイス１０から新しいパスワードを受け入れる。いずれの場合も古いパスワードによる許可はブロックされる。新しいパスワードの作成手順は、サーバ１２がクライアント・デバイス１０と通信して新しいパスワードを取得するサーバ１２の能動的な動作とすることができる。一方、この作成手順を受動的な動作とした場合には、サーバ１２は、クライアント・デバイス１０によって新しいパスワードが作成され、サーバ１２に送信され、サーバ１２がその新しいパスワードを記憶することを想定する。サーバ１２に送信される新しいパスワードは、上述の古いパスワード（又はそのパスワードのダイジェスト）を使用して暗号化することができる。

図４は、図１のシステムにおける上述のパスワード処理に関するメッセージ・トラフィックの一部を示す。サーバ１２は、データベース２０を含む。クライアント・デバイス１０は、サーバ１２から提供されるサービスに対するアクセス要求２４を送信する。要求２４は、パスワード２６を含む。サーバ１２が要求２４を受信すると、サーバ１２は、それぞれのデータベース２０にアクセスして、受信されたパスワード２６の有効期限２８を検索する。次に、サーバ１２は、有効期限２８が収容されたヘッダを含む応答３０をクライアント・デバイス１０に返す。このようにすれば、特定のパスワード２６によるサービス・アクセス試行が行われたときに、パスワード２６の有効期限に関する情報が常にクライアント・デバイス１０に提供されることになる。

以上、例示的な諸実施形態に関して本発明を説明してきたが、本発明はこれらの実施形態に限定されるものではなく、本発明の範囲には多数の可能な変形例及び修正例が含まれることが当業者には理解されるだろう。

本開示の範囲には、新規性ある特徴又は本明細書に開示される特徴の組み合わせが含まれる。本出願人は、本願又は本願から派生する他のすべての出願の出願手続中に、このような特徴又は特徴の組み合わせに対して新たな請求項が考案され得ることをここに予告する。特に、添付の特許請求の範囲に関しては、従属請求項の特徴を独立請求項の特徴と組み合わせることが可能であり、また、独立請求項の特徴は、それぞれ特許請求の範囲で列挙される特定の組み合わせに限らず任意の適切な形で組み合わせることが可能である。

疑義が生じないように、本明細書及び特許請求の範囲全体で使用される「備える／含む（comprising）」という用語は、「〜のみから成る（consisting only of）」という意味に解釈すべきではないことを付記する。

Claims (15)

1. サーバにおけるパスワード変更方法であって、前記サーバが、
   ・パスワードを含む許可要求を受信するステップと、
   ・前記パスワードの有効期限にアクセスするステップと、
   ・クライアントがユーザに対してクレデンシャルを求めるプロンプトを出す手法を修正することが可能となるように、前記有効期限とアクセス要求可否のための再試行パラメータを表す整数値を含む応答を送信するステップと、
   ・前記パスワードの期限が切れているかどうかを確認するステップと、
   ・前記パスワードの期限が切れている場合は新しいパスワードを受信するステップと、
   を含む方法。
2. 送信される前記応答は、前記パスワードの最後の使用を表す日付を更に含む、請求項１に記載の方法。
3. 新しいパスワードを含む要求を受信するステップと、該要求に係る古いパスワードが受け入れられ、かつ前記新しいパスワードが受け入れられないことを確認するステップと、前記再試行パラメータを表す前記整数値を含む応答を、前記整数値を変更せずに送信するステップと、を更に含む、請求項１に記載の方法。
4. 古いパスワードを含む要求を受信するステップと、前記受信がパスワードの期限が切れた後の受信である場合にはアクセス要求拒否のため、前記再試行パラメータを表す前記整数値を含む応答を、前記整数値を１だけ減分して送信するステップと、を更に含む、請求項３に記載の方法。
5. 前記有効期限を含む応答を送信する前記ステップは、前記有効期限を含むヘッダが収容されたメッセージを送信するステップを含む、請求項１乃至４のいずれか一項に記載の方法。
6. 前記方法は、前記サーバをハイパー・テキスト転送プロトコルの要求／応答転送プロトコルに従って操作するステップを更に含み、送信される前記応答は、前記プロトコルに従う応答である、請求項５に記載の方法。
7. 送信される前記応答は、前記プロトコルに従う応答であり、前記サーバによって許可要求が受信される度に送信される、請求項６に記載の方法。
8. サーバであって、
   ・パスワードを含む許可要求を受信し、
   ・前記パスワードの有効期限にアクセスし、
   ・クライアントがユーザに対してクレデンシャルを求めるプロンプトを出す手法を修正することが可能となるように、前記有効期限とアクセス要求可否のための再試行パラメータを表す整数値を含む応答を送信し、
   ・前記パスワードの期限が切れているかどうかを確認し、
   ・前記パスワードの期限が切れている場合は新しいパスワードを受信する
   ように構成されるサーバ。
9. 送信される前記応答は、前記パスワードの最後の使用を表す日付を更に含む、請求項８に記載のサーバ。
10. 新しいパスワードを含む要求を受信し、該要求に係る古いパスワードが受け入れられ、かつ前記新しいパスワードが受け入れられないことを確認し、前記再試行パラメータを表す前記整数値を含む応答を、前記整数値を変更せずに送信するように更に構成される、請求項８に記載のサーバ。
11. 古いパスワードを含む要求を受信し、前記受信がパスワードの期限が切れた後の受信である場合にはアクセス要求拒否のため、前記再試行パラメータを表す前記整数値を含む応答を、前記整数値を１だけ減分して送信するように更に構成される、請求項１０に記載のサーバ。
12. 前記有効期限を含む応答を送信する際に、前記有効期限を含むヘッダが収容されたメッセージを送信するように構成される、請求項８乃至１１のいずれか一項に記載のサーバ。
13. 前記サーバは、ハイパー・テキスト転送プロトコルの要求／応答転送プロトコルに従って操作され、送信される前記応答は、前記プロトコルに従う応答である、請求項１２に記載のサーバ。
14. 送信される前記応答は、前記プロトコルに従う応答であり、前記サーバによって許可要求が受信される度に送信される、請求項１３に記載のサーバ。
15. コンピュータ・システムにロードされ、前記コンピュータ・システム上で実行されたときに、請求項１乃至７のいずれか一項に記載の方法のすべてのステップを前記コンピュータ・システムに実行させるコンピュータ・プログラム・コードを含む、コンピュータ・プログラム。

Images