Facebook、数億人分のユーザーパスワードを数年間可読状態で保存と発表 35
ストーリー by hylom
Twitterもやりましたからねぇ 部門より
Twitterもやりましたからねぇ 部門より
bero曰く、
Kreb on Securityが匿名の関係者からの情報として、Facebookが一部ユーザーのパスワードを暗号化せずに保存しており、さらにこれらのパスワードには多数のFacebook従業員がアクセスできたことを伝えている。Facebookはこれについて事実と認めたとのこと（ITmedia、Slashdot）。
これら報道によると、Facebookでは大半のパスワードをハッシュ化して保存しているが、一部で平文パスワードが記録されていたという。この問題は2012年から始まっており、またそのデータは2万人以上の従業員が検索できたという。実際、アクセスログを確認したところ約2000人がプレーンテキストのパスワードを含むデータに対し約900万回のクエリを実行していたという。
バスワードのハッシュ化は常識であり、それを知らなかったとはさすがに思えないので、おそらくデバックかユーザビリティ調査のために入力を全部ログとってて、そこにパスワードも含まれる、とかじゃなかろうか。
社内の専用アプリケーション (スコア: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)
ソルトは秘密情報だからいいんじゃないの？
バレバレのソフトだと、既知のテーブルは使えなくなるがそこはあんまり重要じゃ無くね？
暗号化？ (スコア:0)
ハッシュ化の間違いだよね？
Re: (スコア:0)
入っているデータが漏れた場合、暗号かハッシュなのか識別できんの？
何回ストレッチしてるかしらんし・・・
複数の暗号化しているかもしらんし・・・
Re: (スコア:0)
可逆性があるかないかが重要。
hylom仕事して (スコア:0)
> バスワード
> デバック
Re:hylom仕事して (スコア:1)
> バスワード
> デバック
仕事（誤字の混入）をちゃんとやってるよね？
Re:hylom仕事して (スコア:1)
古代ローマにおいて公衆浴場に入る際に使われた合言葉のこと。合言葉を正しく言えたものは浴場への通過 = pass を許されたことから，後に password に変化したと言われている。
直訳すると「浴槽の」となる。アルキメデスが入浴時に浮力の原理を思いついた出来事に由来し，入浴時に思索にふけることを de baquet と称した。近年では，入浴時にコンピュータプログラムの不良を見つけることを指すことが多くなり，転じて debug という言葉が生まれた。
民明書房刊「コンピュータと通信 〜フロトコルの発展〜」より。
他の個人情報はどうなってんだろ (スコア:0)
パスワードが多数の従業員に晒されて問題というのなら、他の個人情報も同様に閲覧されてはならない。
逆にそれらの閲覧を問題なしとするなら、パスワードも同様に社外秘の枷が掛かっていると判断できる。