アカウント名:
パスワード:
前世紀から足掛け苦節ン十年、啓蒙の甲斐あってようやく「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)」
度々丁寧なレス、ありがとうございます。digest認証のに関する無知の件はおかげさまで解消致しました。
ユーザーがパスワードを任意のものに変更することを許容する場合はどうなりますでしょう？ユーザーからみてrealmが秘匿されている前提で、希望のパスワードに対して同様の認証を実現する方法が思い当たりません。
Ajaxの隆盛の産物でそういうことを想定したライブラリが既にあるんじゃないかと思って検索をしてみましたが見つからず。＃いい検索ワードが思い当たらないせいだと思いますが。
連結の順番を入れ替えて『「realm+パスワード」のハッシュ+cnounce+nounce』のハッシュと『realm+「パスワード+cnounce」のハッシュ+nounce』のハッシュが等価になるようなハッシュ関数が存在する、なんてことはまずなさそうだし・・・。
もしかしたらすごいバカなことを聞いているんでしょうか？
ん？ん？
固有のrealmを諦めて、ハッシュとペアで保存するようにし、変更時はクライアント側でランダムなrealmを生成し、realmとハッシュのペアを受け取ればいいんですかね？
ちょっと眠くて検証する脳力が・・・。書き置きだけして明日考えます・・・。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
驚くような話ではない (スコア: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)」
オフトピ）Re:サイト管理者の自己防衛の側面 (スコア:1)
度々丁寧なレス、ありがとうございます。
digest認証のに関する無知の件はおかげさまで解消致しました。
ユーザーがパスワードを任意のものに変更することを許容する場合はどうなりますでしょう？
ユーザーからみてrealmが秘匿されている前提で、希望のパスワードに対して同様の認証を実現する方法が思い当たりません。
Ajaxの隆盛の産物でそういうことを想定したライブラリが既にあるんじゃないかと思って検索をしてみましたが見つからず。
＃いい検索ワードが思い当たらないせいだと思いますが。
連結の順番を入れ替えて
『「realm+パスワード」のハッシュ+cnounce+nounce』のハッシュと
『realm+「パスワード+cnounce」のハッシュ+nounce』のハッシュが
等価になるようなハッシュ関数が存在する、なんてことはまずなさそうだし・・・。
もしかしたらすごいバカなことを聞いているんでしょうか？
Youthの半分はバファリンでできています。
Re:オフトピ）Re:サイト管理者の自己防衛の側面 (スコア:1)
ん？ん？
固有のrealmを諦めて、ハッシュとペアで保存するようにし、
変更時はクライアント側でランダムなrealmを生成し、realmとハッシュのペアを受け取ればいいんですかね？
ちょっと眠くて検証する脳力が・・・。
書き置きだけして明日考えます・・・。
Youthの半分はバファリンでできています。