アカウント名:
パスワード:
同じく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に合わせりゃいい
なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない
意味がないから。送られてたもの保存してたら平文と違い何もないじゃん。
これ、少なくないユーザーが他のサービスでもパスワードを使いまわしてるから、平文が漏れるのとハッシュが漏れるのとではダメージが違う、という事らしいよ。
そのままサーバに保存してたら既にそこの会社の従業員にパスワードが漏れてることにならないか。facebookみたいなとこだと、他社システムの認証に使われたりするんだからその考えはやばすぎね？
いや、例えば初回にハッシュ関数1000回掛けたのを送信・保存しておいて、次回からは500回掛けたのを送信すりゃええやん。その際別のソルトでハッシュ関数1000回掛けたパスワードで更新する。そうすれば、
あれ、500回じゃなくて999回でいいんだっけ？ハッシュされた時点で十分な長さがあるもんな。999回→998回と減らしていくってのもありなのかな。
つまりブラウザにパスワード強度判定機能も載ると。属性で最低強度も指定できるとか。
1000回と500回は属性で区別する？ブラウザ間の互換も問題になりそうな。サーバー側でやったほうがいい気がするけどな。
アルゴリズムや鍵を秘密にして安全っていう考えたかは暗号業界の主流からは外れますが。
いやさすがに鍵は秘密にしないと。公開鍵以外は。
え、こいつ本気で言ってんの？ネタだよね？
セキュリティはまず守る対象を明示し、それを確実に守れる方法のうち最も単純な方法を選択しなければならない。(クライアントでハッシュ化して、公開レベルの不明瞭な中継サーバーでハッシュ化して、念のためその先のサーバーでもハッシュ化してといった馬鹿げたシステム設計が始まるからだ。)
まず、送信事前にハッシュ化するアイデアで何を(どのようなケースのパスワード漏洩から)保護しようとしているのか明示するべきだろう。
生パスワードが必要なシステムだった場合 => しようがない生パスワードが必要ないシステムだった場合 => 生パスワードが必要ないのに保存してるような馬鹿がハッシュしてから送るとか、気の利いたことを出来るわけがない。
馬鹿を見分けられるじゃないの。「何で生パスワードを要求するんですか」みたいな事になる。
サービスAに認証しているとサービスBでも認証が通る必要がある。サービスBはサービスAの認証から時間が経った後に接続される。サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。
サービスAの認証トークン受け取ればよくね？
サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。
サービスAをわざわざ出したということは、認証主体はサービスAでサービスBは問い合わせてるだけだろ。サービスBに生パスワードを送る必要はなく、サービスBに送った値でサービスAにログインできればいい。
なんとかの後知恵。2012年頃にパスワードリスト攻撃が認知されるまでは、平文パスワード=問答無用で危険という風潮ではなかった。
POP -> APOPとか HTTPのDigest認証とか telnet->sshとか ネットに平文pass流すなとは昔から言われてましたが
ソルトは秘密情報だからいいんじゃないの？バレバレのソフトだと、既知のテーブルは使えなくなるがそこはあんまり重要じゃ無くね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
社内の専用アプリケーション (スコア: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に合わせりゃいい
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)
セキュリティは
まず守る対象を明示し、
それを確実に守れる方法のうち最も単純な方法を選択しなければならない。
(クライアントでハッシュ化して、公開レベルの不明瞭な中継サーバーでハッシュ化して、念のためその先のサーバーでもハッシュ化してといった馬鹿げたシステム設計が始まるからだ。)
まず、送信事前にハッシュ化するアイデアで何を(どのようなケースのパスワード漏洩から)保護しようとしているのか明示するべきだろう。
Re: (スコア:0)
生パスワードが必要なシステムだった場合 => しようがない
生パスワードが必要ないシステムだった場合 => 生パスワードが必要ないのに保存してるような馬鹿がハッシュしてから
送るとか、気の利いたことを出来るわけがない。
Re:社内の専用アプリケーション (スコア:1)
馬鹿を見分けられるじゃないの。
「何で生パスワードを要求するんですか」みたいな事になる。
Re: (スコア:0)
サービスAに認証しているとサービスBでも認証が通る必要がある。
サービスBはサービスAの認証から時間が経った後に接続される。
サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。
Re: (スコア:0)
サービスAの認証トークン受け取ればよくね？
Re: (スコア:0)
サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。
Re: (スコア:0)
サービスAをわざわざ出したということは、認証主体はサービスAでサービスBは問い合わせてるだけだろ。
サービスBに生パスワードを送る必要はなく、サービスBに送った値でサービスAにログインできればいい。
Re: (スコア:0)
なんとかの後知恵。2012年頃にパスワードリスト攻撃が認知されるまでは、平文パスワード=問答無用で危険という風潮ではなかった。
Re: (スコア:0)
POP -> APOPとか HTTPのDigest認証とか telnet->sshとか ネットに平文pass流すなとは昔から言われてましたが
Re: (スコア:0)
ソルトは秘密情報だからいいんじゃないの？
バレバレのソフトだと、既知のテーブルは使えなくなるがそこはあんまり重要じゃ無くね？