アカウント名:
パスワード:
同じく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自体にSHA-1、SHA-2は使われている。古いブラウザが新しいハッシュ関数をサポートしないって事態は普通にあるだろうけど、ブラウザ毎に分散するって事はまず考えられないでしょう。現状でも古いSSLの無効化で旧ブラウザが切り捨てられているし、ログイン画面はSSLなんだから古いハッシュ関数しかサポートしないブラウザはどちらにせよ切り捨てられる。おそらくハッシュアルゴリズムの更新は旧ハッシュアルゴリズムに対応したブラウザがサポート外、普通にSSLで蹴られる状況になってからになるはずです。
セキュリティ強化と互換性の兼ね合いで新旧二つのハッシュを保存する事態はあり得なくはないでしょうが、それでもパスワードの列が二つになる程度です。それにSHA-2が一般化してからSHA-1が破られるまでにはかなりの時間差がありました。加えて破られたハッシュ関数を利用しつづけたとしても起きる事はせいぜい現状のSSL下で平文を送るのと同じになる程度ですからあわてる事もありません。
ソルト付与の仕方(接続文字とか)で分散する可能性も全くないわけではないが、別にブラウザ屋は分散させたくて分散してるわけではないですからね。
それから別のところで書きましたが、この手法はログイン時にはID入力後にソルトを貰う必要があるのでいわばネゴシエーション的な事はその時行われるでしょう。単純にヘッダに対応するハッシュ関数が載せられる形でしょうね。今はIDとパスワードを同時に入力するのが普通ですからその点は実際に不便になります。フォーム送信データの仕様は別にそこまで複雑になりません。
<input type="password" hash="true" hash_method="SHA-256" hash_salt_generate="false" hash_salt="[...]" hash_stretching="1000" name="password" value="" />
程度には見苦しくなるでしょうけど。パスワード登録時にはソルト送信用のnameも加わるかもしれませんね。
追記:上で触れてなかったですがハッシュ切り替え時には二つパスワード欄を用意すればいいだけですね。ハッシュ関数切り替えなんてのは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)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
社内の専用アプリケーション (スコア: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のぐだぐだを見ると、それぞれのブラウザが独自のハッシュを実装する事態は容易に想像できるし、結局のところサーバ側には複数のアルゴリズムのハッシュを格納しておかないと使い物にはなら
Re:社内の専用アプリケーション (スコア:0)
いや、歴史的な偶然もあるだろうけどハッシュ関数は動画圧縮方式とかとは違ってそんなにうじゃうじゃ分かれてないし、特許上の問題などは起きていない。
そもそもSSL自体にSHA-1、SHA-2は使われている。
古いブラウザが新しいハッシュ関数をサポートしないって事態は普通にあるだろうけど、ブラウザ毎に分散するって事はまず考えられないでしょう。
現状でも古いSSLの無効化で旧ブラウザが切り捨てられているし、ログイン画面はSSLなんだから古いハッシュ関数しかサポートしないブラウザはどちらにせよ切り捨てられる。
おそらくハッシュアルゴリズムの更新は旧ハッシュアルゴリズムに対応したブラウザがサポート外、普通にSSLで蹴られる状況になってからになるはずです。
セキュリティ強化と互換性の兼ね合いで新旧二つのハッシュを保存する事態はあり得なくはないでしょうが、それでもパスワードの列が二つになる程度です。
それにSHA-2が一般化してからSHA-1が破られるまでにはかなりの時間差がありました。
加えて破られたハッシュ関数を利用しつづけたとしても起きる事はせいぜい現状のSSL下で平文を送るのと同じになる程度ですからあわてる事もありません。
ソルト付与の仕方(接続文字とか)で分散する可能性も全くないわけではないが、別にブラウザ屋は分散させたくて分散してるわけではないですからね。
それから別のところで書きましたが、この手法はログイン時にはID入力後にソルトを貰う必要があるのでいわばネゴシエーション的な事はその時行われるでしょう。
単純にヘッダに対応するハッシュ関数が載せられる形でしょうね。
今はIDとパスワードを同時に入力するのが普通ですからその点は実際に不便になります。
フォーム送信データの仕様は別にそこまで複雑になりません。
<input type="password" hash="true" hash_method="SHA-256" hash_salt_generate="false" hash_salt="[...]" hash_stretching="1000" name="password" value="" />
程度には見苦しくなるでしょうけど。
パスワード登録時にはソルト送信用のnameも加わるかもしれませんね。
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に合わせりゃいい