こせきの日記

sshi 2006/03/31 04:14 ども。トラックバック先のsshiです。一点だけ。
>PasswordDigest = MD5( MD5( Password ) + Nonce )
>Digest認証の場合、サーバにパスワードを平文で保存する必要がないんですね。MD5(Password)を持っとけばOK。|
(これは少しおかしい気もしますが)そうだとしても、MD5(password)が結局生パスワードと同じことになりますよね。クライアントはMD5(password)だけ持ってれば認証できちゃうわけだし。

sshi 2006/03/31 04:43 すこし訂正します。
(MD5値を使って)ダイジェスト認証するものと、SSL+Basic認証するものを使いわけておけば、MD5値が漏れてもアクセスされるのは前者だけで後者へのアクセスは防げるかもしれませんね。気がついてませんでした。(また適当なこといってるかも)

koseki 2006/03/31 06:24 コメントありがとうございます。上に続きを書きました。

sheepman 2006/03/31 10:06 Digest認証の場合、サーバに保存されるのは、
MD5( usernamre + ’:’ + realm + ’:’ passwd )
なので、このハッシュが盗まれても、サーバの realm が同じでない限り、
このハッシュを使って認証できるということはありません。
そして、RFC 2617 では Digest 認証の realm にはサーバのホスト名を
入れておくべきだと書かれています。なので、サーバ上に保存されているハッシュ値を盗まれても、他で悪用される危険性はkosekiさんが書かれているよりかは低いと思います。

koseki 2006/03/31 12:46 sheepmanさん、コメントありがとうございます。なるほどなるほど。Digest認証についてはRFC読まずに適当書きすぎました。反省。。

あらいしゅんいち 2006/04/02 23:28 そうですね、一方向ハッシュを二度適用すれば何ら問題はないと思います。拙共訳著「暗号技術大全」を是非どうぞ、米国ではプログラマ必読の教科書となっているようですが、日本ではどうも売れていませんが....

koseki 2006/04/03 00:29 あらいしゅんいちさん、コメントありがとうございます。ハッシュ関数を2度適用するというのはDigest認証の場合だと思うのですが、何ら問題無いというのは、DBデータが漏洩した場合に、よそのサイトで悪用される危険性についての指摘と理解してよろしいでしょうか。

ハッシュ関数だけでは、盗聴と漏洩の両方からパスワードを守ることはできないのだ、ということで納得したところだったので、どのような領域で「何ら問題ない」のかが、ちょっと気になりました。

「暗号技術大全」はぜひ拝読したいです。とずっと思っています……怠惰ですみません……。

あらいしゅんいち 2006/04/03 02:27 えー、私も深く考えたわけではなく、本当の専門家ではないので大きな考え違いがあるかもしれませんが、sheepmanさんの言うのと同じことです。Digest認証では、どちらも問題なさそうです。

最初はHash(password + salt) = hashedpassとしてDBに記録します。毎回の認証時にはHash(hashedpass + challenge)とすれば、まいかい違う情報を要求することができそうですよ。クライアントにはsaltとchallengeを提示すればよいのです。

これによってウェブサイト毎に異なり、また毎回の要求ごとに異なる認証文字列をつかうことができます。これにより傍受とDB漏洩の両者からパスワードが守られます。

koseki 2006/04/03 03:30 あらいしゅんいちさん、お返事どうもありがとうございます。もしかすると自分と同じ勘違いをされているのではないかと思うんですが(なんて恐縮ですが……)、DBに Hash(password + salt) を記録するということは、saltは記録した時点で固定になりますよね。

すると、上でsshiさんが指摘されている通り、hashedpassがその認証における生のパスワードになってしまいます。hashedpassが漏れるとchallengedに対して正しい答えを返すことができてしまう。

Basic認証のハッシュ関数の使い方には (1) 元のpasswordがバレない (2) 認証も通らない、という2つの利点があって、Digest認証では(1)しか満たせないということだと思います。

sheepmanさんは、Digest認証でDBに記録したハッシュは、(漏洩させたサービスの認証に使えても)他のサービスの認証には使えない、ということを指摘されているのだと思います。

あらいしゅんいち 2006/04/03 10:33 ああ、そういう意味でしたか。それは現実的には全く問題がないと思っていたのですが。どういうときに問題になるとおもうのですか？ データベースにアクセスできる人は、自由にシステムを使える人であるはずなので、どうせ自由にログインできるとおもうんですが。
ともあれ体系を二つにすれば解決できそうです。上のDigest認証とは別に、0. hash(password,salt1) = hashed1, hash(hashed1,salt2) = hashed2という計算をして、DBにはhashed2, salt1, salt2だけを記録しておき、1.ユーザにまずsalt1を提示し、2.ユーザがhash(password + salt1)を計算し、hashed1をサーバに送る、3.システムはhash(それ + salt2)を計算し、DBのhashed2と照合する。
こうしておけばpasswordないしhashed1は、hashed2からは簡単に計算できないので、真のパスワードを知っている人しかhashed1を提示することができなくなりそうです。どうですか？
ここまでやるなら素直に公開鍵やSSLをつかっちゃったほうがいいような気がしますけど。

koseki 2006/04/03 14:53 長くなってきたので、また興味深い議論だと思いますので、別記事にしました。
http://d.hatena.ne.jp/koseki/20060403#hash

altavista crack 2007/02/07 04:59 I asked of him, and saw by the ship rode with a look at the cabin is very strong--so strong, resolute, and this island, should he come within range; clearing our way to satisfy me she was discharged, and all of us, yawing wildly, and half of them were young, and otherwise betraying the confusion of so awful a scene, finding that no verbal explanations had been sufficient to try the soundings, in the West Indies, but this Frenchman has already been round four times, in all directions. http://www.qvgs.com/67/altavista-crack.html <a href=”http://www.qvgs.com/67/altavista-crack.html”>altavista crack</a> [url]http://www.qvgs.com/67/altavista-crack.html[/url]