アカウント名:
パスワード:
同じくITmediaだけどこちら [itmedia.co.jp]の方が詳しそう?データの構造化はしていただろうから、「パスワードも含まれる」じゃなくて「パスワードも含めてた」だと思われる。もはやパスワードを平文で送信することが脆弱性になりそう。ブラウザの段階で適当にハッシュ化されるようになったりして。
なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない。まぁ当時ならsaltなしで弱いハッシュ関数を一回分とかになっていただろうけどそうだとしてもhtml5ができた頃には、そこそこまともなハッシュ関数とストレッチングのサポート・セキュリティ警告・多重ハッシュ(サーバー側にはハッシュ化済みのパスワードしかないはずなので)、程度には改良されていたはず。少なくとも平文が漏れ出すとか使いまわしが問題になるとかはかなり少なかったでしょ。
別に今ならJavaScriptでハッシュ関数にかけるくらいできるけどね。
なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない
意味がないから。送られてたもの保存してたら平文と違い何もないじゃん。
これ、少なくないユーザーが他のサービスでもパスワードを使いまわしてるから、平文が漏れるのとハッシュが漏れるのとではダメージが違う、という事らしいよ。
そのままサーバに保存してたら既にそこの会社の従業員にパスワードが漏れてることにならないか。facebookみたいなとこだと、他社システムの認証に使われたりするんだからその考えはやばすぎね?
いや、例えば初回にハッシュ関数1000回掛けたのを送信・保存しておいて、次回からは500回掛けたのを送信すりゃええやん。その際別のソルトでハッシュ関数1000回掛けたパスワードで更新する。そうすれば、
あれ、500回じゃなくて999回でいいんだっけ?ハッシュされた時点で十分な長さがあるもんな。999回→998回と減らしていくってのもありなのかな。
つまりブラウザにパスワード強度判定機能も載ると。属性で最低強度も指定できるとか。
1000回と500回は属性で区別する?ブラウザ間の互換も問題になりそうな。サーバー側でやったほうがいい気がするけどな。
アルゴリズムや鍵を秘密にして安全っていう考えたかは暗号業界の主流からは外れますが。
いやさすがに鍵は秘密にしないと。公開鍵以外は。
え、こいつ本気で言ってんの?ネタだよね?
セキュリティはまず守る対象を明示し、それを確実に守れる方法のうち最も単純な方法を選択しなければならない。(クライアントでハッシュ化して、公開レベルの不明瞭な中継サーバーでハッシュ化して、念のためその先のサーバーでもハッシュ化してといった馬鹿げたシステム設計が始まるからだ。)
まず、送信事前にハッシュ化するアイデアで何を(どのようなケースのパスワード漏洩から)保護しようとしているのか明示するべきだろう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
社内の専用アプリケーション (スコア:0)
同じくITmediaだけどこちら [itmedia.co.jp]の方が詳しそう?
データの構造化はしていただろうから、「パスワードも含まれる」じゃなくて
「パスワードも含めてた」だと思われる。
もはやパスワードを平文で送信することが脆弱性になりそう。
ブラウザの段階で適当にハッシュ化されるようになったりして。
Re: (スコア:0)
なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない。
まぁ当時ならsaltなしで弱いハッシュ関数を一回分とかになっていただろうけどそうだとしてもhtml5ができた頃には、そこそこまともなハッシュ関数とストレッチングのサポート・セキュリティ警告・多重ハッシュ(サーバー側にはハッシュ化済みのパスワードしかないはずなので)、程度には改良されていたはず。
少なくとも平文が漏れ出すとか使いまわしが問題になるとかはかなり少なかったでしょ。
別に今ならJavaScriptでハッシュ関数にかけるくらいできるけどね。
Re:社内の専用アプリケーション (スコア:0)
なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない
意味がないから。
送られてたもの保存してたら平文と違い何もないじゃん。
Re: (スコア:0)
これ、
少なくないユーザーが他のサービスでもパスワードを使いまわしてるから、平文が漏れるのとハッシュが漏れるのとではダメージが違う、という事らしいよ。
Re: (スコア:0)
そのままサーバに保存してたら既にそこの会社の従業員にパスワードが漏れてることにならないか。
facebookみたいなとこだと、他社システムの認証に使われたりするんだからその考えはやばすぎね?
Re: (スコア:0)
いや、例えば初回にハッシュ関数1000回掛けたのを送信・保存しておいて、次回からは500回掛けたのを送信すりゃええやん。
その際別のソルトでハッシュ関数1000回掛けたパスワードで更新する。
そうすれば、
Re: (スコア:0)
あれ、500回じゃなくて999回でいいんだっけ?
ハッシュされた時点で十分な長さがあるもんな。
999回→998回と減らしていくってのもありなのかな。
Re: (スコア:0)
つまりブラウザにパスワード強度判定機能も載ると。
属性で最低強度も指定できるとか。
Re: (スコア:0)
1000回と500回は属性で区別する?ブラウザ間の互換も問題になりそうな。
サーバー側でやったほうがいい気がするけどな。
Re: (スコア:0)
アルゴリズムや鍵を秘密にして安全っていう考えたかは暗号業界の主流からは外れますが。
Re: (スコア:0)
いやさすがに鍵は秘密にしないと。公開鍵以外は。
Re: (スコア:0)
え、こいつ本気で言ってんの?
ネタだよね?
Re: (スコア:0)
セキュリティは
まず守る対象を明示し、
それを確実に守れる方法のうち最も単純な方法を選択しなければならない。
(クライアントでハッシュ化して、公開レベルの不明瞭な中継サーバーでハッシュ化して、念のためその先のサーバーでもハッシュ化してといった馬鹿げたシステム設計が始まるからだ。)
まず、送信事前にハッシュ化するアイデアで何を(どのようなケースのパスワード漏洩から)保護しようとしているのか明示するべきだろう。