アカウント名:
パスワード:
前世紀から足掛け苦節ン十年、啓蒙の甲斐あってようやく「idとパスワードは違う文字列にしとけ」という警告が受け入れられつつある所なのです。
複数のサービスでパスワードの使いまわしがあったとしても、何を驚く事がありましょうか。
// パスワードのサービス毎の切り替えが浸透したら、// 今度は類推しやすいパスワードの排除が待っています// http://srad.jp/security/article.pl?sid=10/01/26/118234 [srad.jp]// セキュリティ：漏えいした3200万のパスワードを米企業が分析、// 最も使われていたのは「123456」
//// 俺たちはまだ登り始めたばかりだからな//// この果てしの無いセキュリティ坂をよ！！！ 未完？
同意。
一体何％の人が銀行口座およびクレジットカードの暗証番号を会社ごとに管理してるんでしょうか？その数字と比較しないと多いかどうか判断ができません。
別件ですがここにぶら下げます。
細々とゲームサイトを運営してますが、登録にメールアドレスを必須にしているスクリプトの場合、パスワードをcryptしてから保存し、その旨を通知してパスワードの問い合わせには応じていません。SNS等のパスワードに統一している可能性を考慮すると、何かあったときに変な嫌疑が掛かるのは嫌ですからね。とはいえ、生パスワードは受け取っていますので保存をすることは原理的に可能であり、クローズドソースで運営する以上釈明として不十分であるという認識でいますがね。
生パスワードを受け取らずにログインを実装するにはOpenID対応ぐらいしか思いつきません。目下サーバー移転作業中なので移転が完了したら勉強しようかと。
> 生パスワードを受け取らずにログインを実装するにはOpenID対応ぐらいしか思いつきません。
JavaScript必須でよければ、クライアント側で暗号化して送信すればいいんじゃないかな。APOPみたいな古典的チャレンジレスポンスだとサーバ側に生パスワードが必要ですが、HTTPのダイジェスト認証みたいに、二重にハッシュ処理すれば、生パスワードは保管不要です。
JavaScriptのMD5ライブラリとかも世に出回っているので、結構簡単に実現できます。
ありがとうございます。
以下の部分がよく分かってないので的外れなことを言っているかもしれませんが。
APOPみたいな古典的チャレンジレスポンスだとサーバ側に生パスワードが必要ですが、HTTPのダイジェスト認証みたいに、二重にハッシュ処理すれば、生パスワードは保管不要です。
あらかじめ.jsにcryptさせたものをperlで受けとって処理するには、.jsとperlの双方の暗号化において同じソルトを使用する必要があると思います。
当時は「javascriptデフォルトでオフにせよ」がWebの主流になると思っていたので「ソルトになる文字列が固有で、.jsのソースに残るようでは甘い」と考え、javascript必須をユーザーに要求するほどの実装ではないと思いました。
なんかうまい方法で解決できるもんですかね?
当時考えたことを思い出しながらそのまま書いたんですけど、なんか変ですね。
初回生成時に.jsに作らせた暗号化文字列を受け取る何らかの機構が用意できればperl側にcryptは必要なく、ソルトもランダム値をとり得ますね。
仮登録結果の表示ページからpostさせるとか？
あれ？自己解決?してる？
チャレンジ・レスポンス認証では、昔ながらのcryptにおける「ソルト」に相当するものはありません。
以下、digest認証のおおざっぱな説明です。
HTTPのdigest認証では、サーバ側では、「文字列1(realm)+パスワード」をハッシュ化した文字列を保存しています。この文字列1は、ランダムではなく、サイト固有の文字列にします。そうすることで、サーバが保管している『「文字列1+パスワード」のハッシュ』は他のサイトに流用することはない、ということを保証できます。
認証時には、サーバからはクライアントにこの「文字列1(realm)」と、認証ごとにランダムに生成する「文字列2(nounce)」を送ります。
クライアント側でも、ランダムに「文字列3(cnounce)」を生成し、受け取った文字列1と入力されたパスワードから「文字列1+パスワード」のハッシュを計算し、さらに文字列2と文字列3から『「文字列1+パスワード」のハッシュ+文字列2+文字列3』のハッシュを計算し、このハッシュを文字列3と共にサーバに送ります。
サーバ側では、受け取った文字列3と自身が持っている情報から『「文字列1+パスワード」のハッシュ+文字列2+文字列3』のハッシュを計算し、クライアントから送られてきたハッシュ文字列と比較して認証します。
このように、通常の認証過程では、生パスワードやパスワードから一意に定まるような文字列は、まったく流れませんし、サーバ側でも生パスワードの保存は不要になります。また、クライアント側で「固定のソルト」のようなマジックナンバーは不要です。
度々丁寧なレス、ありがとうございます。digest認証のに関する無知の件はおかげさまで解消致しました。
ユーザーがパスワードを任意のものに変更することを許容する場合はどうなりますでしょう？ユーザーからみてrealmが秘匿されている前提で、希望のパスワードに対して同様の認証を実現する方法が思い当たりません。
Ajaxの隆盛の産物でそういうことを想定したライブラリが既にあるんじゃないかと思って検索をしてみましたが見つからず。＃いい検索ワードが思い当たらないせいだと思いますが。
連結の順番を入れ替えて『「realm+パスワード」のハッシュ+cnounce+nounce』のハッシュと『realm+「パスワード+cnounce」のハッシュ+nounce』のハッシュが等価になるようなハッシュ関数が存在する、なんてことはまずなさそうだし・・・。
もしかしたらすごいバカなことを聞いているんでしょうか？
ん？ん？
固有のrealmを諦めて、ハッシュとペアで保存するようにし、変更時はクライアント側でランダムなrealmを生成し、realmとハッシュのペアを受け取ればいいんですかね？
ちょっと眠くて検証する脳力が・・・。書き置きだけして明日考えます・・・。
遅くなりまして申し訳ありません。＃待っていただいていたかどうかは別として暗号に関する技術資料やらWikipediaやらを読み漁って大いに脱線をしておりました。
結論から申し上げると、私が実装したい「生パスワードは一切受け取っていませんよ」と客観的に主張できるライブラリは見当たりませんでした。
既存のライブラリの応用から上記のライブラリを作ることは（taka2さんに頂いたヒントを元にすれば）それほど難しくないだろうとは思いましたが、・javascript必須を回避しうる・ログインスキームの一元化（OpenID採用サイトとの統一）・ユーザーに対する説得の手間などの点でやはり素直にOpenIDのAPIを勉強して採用することのほうがコストが低いであろうとの結論に達しました。
謝意が伝わるように、taka2さんのコメントへのレストして投稿させていただきます。ありがとうございました。
なお、このオフトピ気味のツリーでも何かの役に立つかもしれませんので関連リンクを以下にまとめます。
javascriptによるmd５の実装ライブラリ1.世界標準? http://pajhome.org.uk/crypt/md5/ [pajhome.org.uk]2.日本人による実装では最速らしい http://labs.cybozu.co.jp/blog/mitsunari/2007/07/md5js_1.html [cybozu.co.jp]
成果物はsourceforge.jpにいくつか見つかりました。1. http://osdn.jp/projects/freshmeat_perl-md5-login/ [osdn.jp]上記の1.を含んだajaxライブラリ
2. http://osdn.jp/projects/sfnet_clean-ajax/ [osdn.jp]perlスクリプトが出力するHTMLの中に上記の1.を含んでいます。ソースを読む限りではユーザ側で任意のパスワードに変更する例は直接示されておらず、パスワードの生成はサーバー側で行うことのみを想定しているようです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
驚くような話ではない (スコア:1)
前世紀から足掛け苦節ン十年、啓蒙の甲斐あってようやく
「idとパスワードは違う文字列にしとけ」
という警告が受け入れられつつある所なのです。
複数のサービスでパスワードの使いまわしがあったとしても、
何を驚く事がありましょうか。
// パスワードのサービス毎の切り替えが浸透したら、
// 今度は類推しやすいパスワードの排除が待っています
// http://srad.jp/security/article.pl?sid=10/01/26/118234 [srad.jp]
// セキュリティ：漏えいした3200万のパスワードを米企業が分析、
// 最も使われていたのは「123456」
//// 俺たちはまだ登り始めたばかりだからな
//// この果てしの無いセキュリティ坂をよ！！！ 未完？
Re:驚くような話ではない (スコア:1)
同意。
一体何％の人が銀行口座およびクレジットカードの暗証番号を会社ごとに管理してるんでしょうか？
その数字と比較しないと多いかどうか判断ができません。
Youthの半分はバファリンでできています。
サイト管理者の自己防衛の側面 (スコア:2, 興味深い)
別件ですがここにぶら下げます。
細々とゲームサイトを運営してますが、
登録にメールアドレスを必須にしているスクリプトの場合、
パスワードをcryptしてから保存し、その旨を通知してパスワードの問い合わせには応じていません。
SNS等のパスワードに統一している可能性を考慮すると、何かあったときに変な嫌疑が掛かるのは嫌ですからね。
とはいえ、生パスワードは受け取っていますので保存をすることは原理的に可能であり、
クローズドソースで運営する以上釈明として不十分であるという認識でいますがね。
生パスワードを受け取らずにログインを実装するにはOpenID対応ぐらいしか思いつきません。
目下サーバー移転作業中なので移転が完了したら勉強しようかと。
Youthの半分はバファリンでできています。
Re:サイト管理者の自己防衛の側面 (スコア:1)
> 生パスワードを受け取らずにログインを実装するにはOpenID対応ぐらいしか思いつきません。
JavaScript必須でよければ、クライアント側で暗号化して送信すればいいんじゃないかな。
APOPみたいな古典的チャレンジレスポンスだとサーバ側に生パスワードが必要ですが、
HTTPのダイジェスト認証みたいに、二重にハッシュ処理すれば、生パスワードは保管不要です。
JavaScriptのMD5ライブラリとかも世に出回っているので、結構簡単に実現できます。
Re:サイト管理者の自己防衛の側面 (スコア:1)
ありがとうございます。
以下の部分がよく分かってないので的外れなことを言っているかもしれませんが。
あらかじめ.jsにcryptさせたものをperlで受けとって処理するには、
.jsとperlの双方の暗号化において同じソルトを使用する必要があると思います。
当時は「javascriptデフォルトでオフにせよ」がWebの主流になると思っていたので
「ソルトになる文字列が固有で、.jsのソースに残るようでは甘い」と考え、
javascript必須をユーザーに要求するほどの実装ではないと思いました。
なんかうまい方法で解決できるもんですかね?
Youthの半分はバファリンでできています。
Re:サイト管理者の自己防衛の側面 (スコア:1)
当時考えたことを思い出しながらそのまま書いたんですけど、なんか変ですね。
初回生成時に.jsに作らせた暗号化文字列を受け取る何らかの機構が用意できれば
perl側にcryptは必要なく、ソルトもランダム値をとり得ますね。
仮登録結果の表示ページからpostさせるとか？
あれ？自己解決?してる？
Youthの半分はバファリンでできています。
Re:サイト管理者の自己防衛の側面 (スコア:1)
チャレンジ・レスポンス認証では、昔ながらのcryptにおける「ソルト」に相当するものはありません。
以下、digest認証のおおざっぱな説明です。
HTTPのdigest認証では、
サーバ側では、「文字列1(realm)+パスワード」をハッシュ化した文字列を保存しています。
この文字列1は、ランダムではなく、サイト固有の文字列にします。
そうすることで、サーバが保管している『「文字列1+パスワード」のハッシュ』は
他のサイトに流用することはない、ということを保証できます。
認証時には、サーバからはクライアントにこの「文字列1(realm)」と、認証ごとにランダムに生成する「文字列2(nounce)」を送ります。
クライアント側でも、ランダムに「文字列3(cnounce)」を生成し、受け取った文字列1と入力されたパスワードから
「文字列1+パスワード」のハッシュを計算し、さらに文字列2と文字列3から
『「文字列1+パスワード」のハッシュ+文字列2+文字列3』のハッシュを計算し、
このハッシュを文字列3と共にサーバに送ります。
サーバ側では、受け取った文字列3と自身が持っている情報から
『「文字列1+パスワード」のハッシュ+文字列2+文字列3』のハッシュを計算し、
クライアントから送られてきたハッシュ文字列と比較して認証します。
このように、通常の認証過程では、
生パスワードやパスワードから一意に定まるような文字列は、まったく流れませんし、
サーバ側でも生パスワードの保存は不要になります。
また、クライアント側で「固定のソルト」のようなマジックナンバーは不要です。
オフトピ）Re:サイト管理者の自己防衛の側面 (スコア:1)
度々丁寧なレス、ありがとうございます。
digest認証のに関する無知の件はおかげさまで解消致しました。
ユーザーがパスワードを任意のものに変更することを許容する場合はどうなりますでしょう？
ユーザーからみてrealmが秘匿されている前提で、希望のパスワードに対して同様の認証を実現する方法が思い当たりません。
Ajaxの隆盛の産物でそういうことを想定したライブラリが既にあるんじゃないかと思って検索をしてみましたが見つからず。
＃いい検索ワードが思い当たらないせいだと思いますが。
連結の順番を入れ替えて
『「realm+パスワード」のハッシュ+cnounce+nounce』のハッシュと
『realm+「パスワード+cnounce」のハッシュ+nounce』のハッシュが
等価になるようなハッシュ関数が存在する、なんてことはまずなさそうだし・・・。
もしかしたらすごいバカなことを聞いているんでしょうか？
Youthの半分はバファリンでできています。
Re:オフトピ）Re:サイト管理者の自己防衛の側面 (スコア:1)
ん？ん？
固有のrealmを諦めて、ハッシュとペアで保存するようにし、
変更時はクライアント側でランダムなrealmを生成し、realmとハッシュのペアを受け取ればいいんですかね？
ちょっと眠くて検証する脳力が・・・。
書き置きだけして明日考えます・・・。
Youthの半分はバファリンでできています。
Re:サイト管理者の自己防衛の側面 (スコア:1)
遅くなりまして申し訳ありません。
＃待っていただいていたかどうかは別として
暗号に関する技術資料やらWikipediaやらを読み漁って大いに脱線をしておりました。
結論から申し上げると、私が実装したい「生パスワードは一切受け取っていませんよ」と客観的に主張できるライブラリは見当たりませんでした。
既存のライブラリの応用から上記のライブラリを作ることは（taka2さんに頂いたヒントを元にすれば）それほど難しくないだろうとは思いましたが、
・javascript必須を回避しうる
・ログインスキームの一元化（OpenID採用サイトとの統一）
・ユーザーに対する説得の手間
などの点でやはり素直にOpenIDのAPIを勉強して採用することのほうがコストが低いであろうとの結論に達しました。
謝意が伝わるように、taka2さんのコメントへのレストして投稿させていただきます。ありがとうございました。
なお、このオフトピ気味のツリーでも何かの役に立つかもしれませんので関連リンクを以下にまとめます。
javascriptによるmd５の実装ライブラリ
1.世界標準? http://pajhome.org.uk/crypt/md5/ [pajhome.org.uk]
2.日本人による実装では最速らしい http://labs.cybozu.co.jp/blog/mitsunari/2007/07/md5js_1.html [cybozu.co.jp]
成果物はsourceforge.jpにいくつか見つかりました。
1. http://osdn.jp/projects/freshmeat_perl-md5-login/ [osdn.jp]
上記の1.を含んだajaxライブラリ
2. http://osdn.jp/projects/sfnet_clean-ajax/ [osdn.jp]
perlスクリプトが出力するHTMLの中に上記の1.を含んでいます。
ソースを読む限りではユーザ側で任意のパスワードに変更する例は直接示されておらず、パスワードの生成はサーバー側で行うことのみを想定しているようです。
Youthの半分はバファリンでできています。