アカウント名:
パスワード:
同じくITmediaだけどこちら [itmedia.co.jp]の方が詳しそう？データの構造化はしていただろうから、「パスワードも含まれる」じゃなくて「パスワードも含めてた」だと思われる。もはやパスワードを平文で送信することが脆弱性になりそう。ブラウザの段階で適当にハッシュ化されるようになったりして。
なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない。まぁ当時ならsaltなしで弱いハッシュ関数を一回分とかになっていただろうけどそうだとしてもhtml5ができた頃には、そこそこまともなハッシュ関数とストレッチングのサポート・セキュリティ警告・多重ハッシュ(サーバー側にはハッシュ化済みのパスワードしかないはずなので)、程度には改良されていたはず。少なくとも平文が漏れ出すとか使いまわしが問題になるとかはかなり少なかったでしょ。
別に今ならJavaScriptでハッシュ関数にかけるくらいできるけどね。
生のパスワードが必要な用途もありますが。例えば、オープンソースなWebベースのMUAだと、POP/IMAP4のID/パスワードをそのまま使ってログインするものが多いですが、そこで「何かしらのハッシュ」を受け取っても何の役にもたたない。
ハッシュ送信機能は強制ではなくオプションにするしかないし、そうなると、ハッシュ送信機能なんて誰も使わないでしょう。
ていうか、ハッシュアルゴリズムが変わると認証が通らなくなるから、そんな怖いもの使う気にはならないな…
現状、SSL無しでパスワード送信も可能だけど別に誰も使わないって事にはなってないよね。むしろそんなサイトは誰も信用しないし使わない。ちょっと前まではあった気もするけど…。
もちろん、ハッシュアルゴリズムはログイン時に更新できるだろうし、互換性維持の努力はされるでしょう。
とはいえ、
hash="true"を指定した場合、hash_methodを指定しないとデフォルトのMD5が使用されます。MD5は現在脆弱なハッシュ関数とみなされているので必ずhash_methodには有効な値を指定してください。また古いブラウザの場合hash_methodが無視されたり指定されたハッシュ関数が非対応の場合があります。その場合もMD5が利用されるので文字列長から判断してください。
みたいな事態になっただろうとは容易に想像できる。
ハッシュアルゴリズムはログイン時に更新
それをやろうとしたら、新旧両方のハッシュをサーバに送る必要がありますね。旧アルゴリズムのハッシュで認証してOKなら、新アルゴリズムのハッシュで更新。
でも、それで、新アルゴリズムのハッシュだけをサーバで格納したら、旧アルゴリズムしかサポートできていないブラウザからは使えない、ということになってしまいます。HTML5のぐだぐだを見ると、それぞれのブラウザが独自のハッシュを実装する事態は容易に想像できるし、結局のところサーバ側には複数のアルゴリズムのハッシュを格納しておかないと使い物にはならなさそう。さらには、ブラウザがサポートしているアルゴリズムを確認するためにSSLのネゴシエーションみたいなことをする必要があるだろうし フォーム送信データの仕様としては複雑すぎるかと。
そもそも、ブラウザが生成したパスワードハッシュをそのままサーバ側に保存するから、そういった問題が出てくるわけで、「サーバ側の生パスワード隠蔽のためのハッシュ保持」と「通信路の秘密保持のためのパスワード送信暗号化」は分けて考えて、通信路保持のための暗号化は一方向ハッシュではなく、復号可能な暗号を使うほうが無難でしょう。
要するに、SSLで通信路を秘匿した上で、フォームからのパスワード送信は生パスワードのままってのが順当かと。
いや、歴史的な偶然もあるだろうけどハッシュ関数は動画圧縮方式とかとは違ってそんなにうじゃうじゃ分かれてないし、特許上の問題などは起きていない。そもそもSSL自体にSHA-1、SHA-2は使われている。古いブラウザが新しいハッシュ関数をサポートしないって事態は普通にあるだろうけど、ブラウザ毎に分散するって事はまず考えられないでしょう。現状でも古いSSLの無効化で旧ブラウザが切り捨てられているし、ログイン画面はSSLなんだから古いハッシュ関数しかサポートしないブラウザはどちらにせよ切り捨てられる。おそらくハッシュアルゴリズムの更新は旧ハッシュアルゴリ
追記：上で触れてなかったですがハッシュ切り替え時には二つパスワード欄を用意すればいいだけですね。ハッシュ関数切り替えなんてのは10年に一度とかのイベントなんで普通に「一年経過したので新しいパスワードにしてください」と同じ感覚ですね。
一度に送るか、https://srad.jp/comment/3586135の要領でハッシュを二つ送るという話だと上のタグがさらに見苦しくなる事になります。こんな感じ、
<input type="password" hash_1="true" hash_1_method="SHA-256" hash_1_salt_generate="false" hash_1_salt="[...]" hash_1_stretching="500" name_hash_1="password_old" hash_2_method="SHA-256" hash_2_salt_generate="true" hash_2_salt_name="newhash" hash_2_stretching="500" name_hash_2="password_new" value="" />
もう少しスマートにすれば
<input type="password"> <hash method="SHA-256" salt="[...]" stretching="500" name="password_auth" /> <hash method="SHA-256" salt_ref="salt_new" stretching="1000" name="password" /
ブラウザはバズワードハッシュと使用アルゴリズム送れば良いだけやんソルトはIDのとnanceのハッシュで差し支えないしイランアルゴリズム切り替えは時は旧ハッシュわさらに新アルゴでハッシュにするだけで良いしそんなややこしい指定や再入力はいらんでしよ
サーバ側はhttpヘッダに受け入れ可能なハッシュアルゴリズム入れれば良いし、それならソース変えなくていいから手間ないし
ブラウザは対応する一番いいhashで送るサーバは必要なら再ハッシュしてDBに合わせりゃいい
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
社内の専用アプリケーション (スコア:0)
同じくITmediaだけどこちら [itmedia.co.jp]の方が詳しそう？
データの構造化はしていただろうから、「パスワードも含まれる」じゃなくて
「パスワードも含めてた」だと思われる。
もはやパスワードを平文で送信することが脆弱性になりそう。
ブラウザの段階で適当にハッシュ化されるようになったりして。
Re: (スコア:0)
なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない。
まぁ当時ならsaltなしで弱いハッシュ関数を一回分とかになっていただろうけどそうだとしてもhtml5ができた頃には、そこそこまともなハッシュ関数とストレッチングのサポート・セキュリティ警告・多重ハッシュ(サーバー側にはハッシュ化済みのパスワードしかないはずなので)、程度には改良されていたはず。
少なくとも平文が漏れ出すとか使いまわしが問題になるとかはかなり少なかったでしょ。
別に今ならJavaScriptでハッシュ関数にかけるくらいできるけどね。
Re: (スコア:1)
生のパスワードが必要な用途もありますが。
例えば、オープンソースなWebベースのMUAだと、POP/IMAP4のID/パスワードをそのまま使ってログインするものが多いですが、そこで「何かしらのハッシュ」を受け取っても何の役にもたたない。
ハッシュ送信機能は強制ではなくオプションにするしかないし、そうなると、ハッシュ送信機能なんて誰も使わないでしょう。
ていうか、ハッシュアルゴリズムが変わると認証が通らなくなるから、そんな怖いもの使う気にはならないな…
Re:社内の専用アプリケーション (スコア:0)
現状、SSL無しでパスワード送信も可能だけど別に誰も使わないって事にはなってないよね。
むしろそんなサイトは誰も信用しないし使わない。ちょっと前まではあった気もするけど…。
もちろん、ハッシュアルゴリズムはログイン時に更新できるだろうし、互換性維持の努力はされるでしょう。
とはいえ、
hash="true"を指定した場合、hash_methodを指定しないとデフォルトのMD5が使用されます。
MD5は現在脆弱なハッシュ関数とみなされているので必ずhash_methodには有効な値を指定してください。
また古いブラウザの場合hash_methodが無視されたり指定されたハッシュ関数が非対応の場合があります。
その場合もMD5が利用されるので文字列長から判断してください。
みたいな事態になっただろうとは容易に想像できる。
Re:社内の専用アプリケーション (スコア:1)
それをやろうとしたら、新旧両方のハッシュをサーバに送る必要がありますね。旧アルゴリズムのハッシュで認証してOKなら、新アルゴリズムのハッシュで更新。
でも、それで、新アルゴリズムのハッシュだけをサーバで格納したら、旧アルゴリズムしかサポートできていないブラウザからは使えない、ということになってしまいます。HTML5のぐだぐだを見ると、それぞれのブラウザが独自のハッシュを実装する事態は容易に想像できるし、結局のところサーバ側には複数のアルゴリズムのハッシュを格納しておかないと使い物にはならなさそう。
さらには、ブラウザがサポートしているアルゴリズムを確認するためにSSLのネゴシエーションみたいなことをする必要があるだろうし フォーム送信データの仕様としては複雑すぎるかと。
そもそも、ブラウザが生成したパスワードハッシュをそのままサーバ側に保存するから、そういった問題が出てくるわけで、「サーバ側の生パスワード隠蔽のためのハッシュ保持」と「通信路の秘密保持のためのパスワード送信暗号化」は分けて考えて、通信路保持のための暗号化は一方向ハッシュではなく、復号可能な暗号を使うほうが無難でしょう。
要するに、SSLで通信路を秘匿した上で、フォームからのパスワード送信は生パスワードのままってのが順当かと。
Re: (スコア:0)
いや、歴史的な偶然もあるだろうけどハッシュ関数は動画圧縮方式とかとは違ってそんなにうじゃうじゃ分かれてないし、特許上の問題などは起きていない。
そもそもSSL自体にSHA-1、SHA-2は使われている。
古いブラウザが新しいハッシュ関数をサポートしないって事態は普通にあるだろうけど、ブラウザ毎に分散するって事はまず考えられないでしょう。
現状でも古いSSLの無効化で旧ブラウザが切り捨てられているし、ログイン画面はSSLなんだから古いハッシュ関数しかサポートしないブラウザはどちらにせよ切り捨てられる。
おそらくハッシュアルゴリズムの更新は旧ハッシュアルゴリ
Re: (スコア:0)
追記：
上で触れてなかったですがハッシュ切り替え時には二つパスワード欄を用意すればいいだけですね。
ハッシュ関数切り替えなんてのは10年に一度とかのイベントなんで普通に「一年経過したので新しいパスワードにしてください」と同じ感覚ですね。
一度に送るか、https://srad.jp/comment/3586135の要領でハッシュを二つ送るという話だと上のタグがさらに見苦しくなる事になります。
こんな感じ、
<input type="password" hash_1="true" hash_1_method="SHA-256" hash_1_salt_generate="false" hash_1_salt="[...]" hash_1_stretching="500" name_hash_1="password_old" hash_2_method="SHA-256" hash_2_salt_generate="true" hash_2_salt_name="newhash" hash_2_stretching="500" name_hash_2="password_new" value="" />
もう少しスマートにすれば
<input type="password">
<hash method="SHA-256" salt="[...]" stretching="500" name="password_auth" />
<hash method="SHA-256" salt_ref="salt_new" stretching="1000" name="password" /
Re: (スコア:0)
ブラウザはバズワードハッシュと使用アルゴリズム送れば良いだけやん
ソルトはIDのとnanceのハッシュで差し支えないしイラン
アルゴリズム切り替えは時は旧ハッシュわさらに新アルゴでハッシュにするだけで良いしそんなややこしい指定や再入力はいらんでしよ
サーバ側はhttpヘッダに受け入れ可能なハッシュアルゴリズム入れれば良いし、それならソース変えなくていいから手間ないし
ブラウザは対応する一番いいhashで送る
サーバは必要なら再ハッシュしてDBに合わせりゃいい