パスワードを忘れた? アカウント作成
13867983 journal
日記

beroの日記: Facebook、数億人分のユーザーパスワードを数年間可読状態で保存と発表 35

日記 by bero

Facebook、数億人分のユーザーパスワードを数年間可読状態で保存と発表 (itmedia)

米Facebookは3月21日(現地時間)、Facebook、Instagram、Facebook Liteの数億人分のパスワードが可読な状態で社内に保存されていることに1月に気づき、修正したと発表した。

パスワードのプレーンテキストでの保存は2012年から始まっており、2万人以上の従業員が検索できたという。アクセスログでは約2000人がプレーンテキストのパスワードを含むデータに、約900万回のクエリを実行していた。

ちょ..え..
バスワードのハッシュ化は常識、というのをしてなかった、とはさすがに思えないので、
おそらくデバックかユーザビリティ調査のために入力を全部ログとってて、そこにパスワードも含まれる、とかじゃなかろうか

  • by Anonymous Coward on 2019年03月23日 15時41分 (#3585969)

    同じくITmediaだけどこちら [itmedia.co.jp]の方が詳しそう?
    データの構造化はしていただろうから、「パスワードも含まれる」じゃなくて
    「パスワードも含めてた」だと思われる。
    もはやパスワードを平文で送信することが脆弱性になりそう。
    ブラウザの段階で適当にハッシュ化されるようになったりして。

    ここに返信
    • by Anonymous Coward

      なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない。
      まぁ当時ならsaltなしで弱いハッシュ関数を一回分とかになっていただろうけどそうだとしてもhtml5ができた頃には、そこそこまともなハッシュ関数とストレッチングのサポート・セキュリティ警告・多重ハッシュ(サーバー側にはハッシュ化済みのパスワードしかないはずなので)、程度には改良されていたはず。
      少なくとも平文が漏れ出すとか使いまわしが問題になるとかはかなり少なかったでしょ。

      別に今ならJavaScriptでハッシュ関数にかけるくらいできるけどね。

      • 生のパスワードが必要な用途もありますが。
        例えば、オープンソースなWebベースのMUAだと、POP/IMAP4のID/パスワードをそのまま使ってログインするものが多いですが、そこで「何かしらのハッシュ」を受け取っても何の役にもたたない。

        ハッシュ送信機能は強制ではなくオプションにするしかないし、そうなると、ハッシュ送信機能なんて誰も使わないでしょう。

        ていうか、ハッシュアルゴリズムが変わると認証が通らなくなるから、そんな怖いもの使う気にはならないな…

        • by Anonymous Coward

          現状、SSL無しでパスワード送信も可能だけど別に誰も使わないって事にはなってないよね。
          むしろそんなサイトは誰も信用しないし使わない。ちょっと前まではあった気もするけど…。

          もちろん、ハッシュアルゴリズムはログイン時に更新できるだろうし、互換性維持の努力はされるでしょう。

          とはいえ、

          hash="true"を指定した場合、hash_methodを指定しないとデフォルトのMD5が使用されます。
          MD5は現在脆弱なハッシュ関数とみなされているので必ずhash_methodには有効な値を指定してください。
          また古いブラウザの場合hash_methodが無視されたり指定されたハッシュ関数が非対応の場合があります。
          その場合もMD5が利用されるので文字列長から判断してください。

          みたいな事態になっただろうとは容易に想像できる。

          • ハッシュアルゴリズムはログイン時に更新

            それをやろうとしたら、新旧両方のハッシュをサーバに送る必要がありますね。旧アルゴリズムのハッシュで認証してOKなら、新アルゴリズムのハッシュで更新。

            でも、それで、新アルゴリズムのハッシュだけをサーバで格納したら、旧アルゴリズムしかサポートできていないブラウザからは使えない、ということになってしまいます。HTML5のぐだぐだを見ると、それぞれのブラウザが独自のハッシュを実装する事態は容易に想像できるし、結局のところサーバ側には複数のアルゴリズムのハッシュを格納しておかないと使い物にはならなさそう。
            さらには、ブラウザがサポートしているアルゴリズムを確認するためにSSLのネゴシエーションみたいなことをする必要があるだろうし フォーム送信データの仕様としては複雑すぎるかと。

            そもそも、ブラウザが生成したパスワードハッシュをそのままサーバ側に保存するから、そういった問題が出てくるわけで、「サーバ側の生パスワード隠蔽のためのハッシュ保持」と「通信路の秘密保持のためのパスワード送信暗号化」は分けて考えて、通信路保持のための暗号化は一方向ハッシュではなく、復号可能な暗号を使うほうが無難でしょう。

            要するに、SSLで通信路を秘匿した上で、フォームからのパスワード送信は生パスワードのままってのが順当かと。

            • by Anonymous Coward

              いや、歴史的な偶然もあるだろうけどハッシュ関数は動画圧縮方式とかとは違ってそんなにうじゃうじゃ分かれてないし、特許上の問題などは起きていない。
              そもそもSSL自体にSHA-1、SHA-2は使われている。
              古いブラウザが新しいハッシュ関数をサポートしないって事態は普通にあるだろうけど、ブラウザ毎に分散するって事はまず考えられないでしょう。
              現状でも古いSSLの無効化で旧ブラウザが切り捨てられているし、ログイン画面はSSLなんだから古いハッシュ関数しかサポートしないブラウザはどちらにせよ切り捨てられる。
              おそらくハッシュアルゴリズムの更新は旧ハッシュアルゴリ

              • by Anonymous Coward

                追記:
                上で触れてなかったですがハッシュ切り替え時には二つパスワード欄を用意すればいいだけですね。
                ハッシュ関数切り替えなんてのは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" /

              • by Anonymous Coward

                ブラウザはバズワードハッシュと使用アルゴリズム送れば良いだけやん
                ソルトはIDのとnanceのハッシュで差し支えないしイラン
                アルゴリズム切り替えは時は旧ハッシュわさらに新アルゴでハッシュにするだけで良いしそんなややこしい指定や再入力はいらんでしよ

                サーバ側はhttpヘッダに受け入れ可能なハッシュアルゴリズム入れれば良いし、それならソース変えなくていいから手間ないし

                ブラウザは対応する一番いいhashで送る
                サーバは必要なら再ハッシュしてDBに合わせりゃいい

      • by Anonymous Coward

        なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない

        意味がないから。
        送られてたもの保存してたら平文と違い何もないじゃん。

        • by Anonymous Coward

          これ、
          少なくないユーザーが他のサービスでもパスワードを使いまわしてるから、平文が漏れるのとハッシュが漏れるのとではダメージが違う、という事らしいよ。

          • by Anonymous Coward

            そのままサーバに保存してたら既にそこの会社の従業員にパスワードが漏れてることにならないか。
            facebookみたいなとこだと、他社システムの認証に使われたりするんだからその考えはやばすぎね?

        • by Anonymous Coward

          いや、例えば初回にハッシュ関数1000回掛けたのを送信・保存しておいて、次回からは500回掛けたのを送信すりゃええやん。
          その際別のソルトでハッシュ関数1000回掛けたパスワードで更新する。
          そうすれば、

          • サーバー側でハッシュ500回分掛けてる事がユーザーに分かる。
          • ハッシュされたパスワードが流出しても元パスワードを知らないとログインできない。
          • 平文は自分しか知らない→使いまわしは問題にならない。
          • 挙動を調査すればハッシュ500回分で単純比較していないと分かる。
          • ソルトのランダムさがユーザー側で担保できる。
          • by Anonymous Coward

            あれ、500回じゃなくて999回でいいんだっけ?
            ハッシュされた時点で十分な長さがあるもんな。
            999回→998回と減らしていくってのもありなのかな。

          • by Anonymous Coward

            つまりブラウザにパスワード強度判定機能も載ると。
            属性で最低強度も指定できるとか。

          • by Anonymous Coward

            1000回と500回は属性で区別する?ブラウザ間の互換も問題になりそうな。
            サーバー側でやったほうがいい気がするけどな。

          • by Anonymous Coward

            アルゴリズムや鍵を秘密にして安全っていう考えたかは暗号業界の主流からは外れますが。

            • by Anonymous Coward

              いやさすがに鍵は秘密にしないと。公開鍵以外は。

          • by Anonymous Coward

            え、こいつ本気で言ってんの?
            ネタだよね?

          • by Anonymous Coward

            セキュリティは
            まず守る対象を明示し、
            それを確実に守れる方法のうち最も単純な方法を選択しなければならない。
            (クライアントでハッシュ化して、公開レベルの不明瞭な中継サーバーでハッシュ化して、念のためその先のサーバーでもハッシュ化してといった馬鹿げたシステム設計が始まるからだ。)

            まず、送信事前にハッシュ化するアイデアで何を(どのようなケースのパスワード漏洩から)保護しようとしているのか明示するべきだろう。

      • by Anonymous Coward

        生パスワードが必要なシステムだった場合 => しようがない
        生パスワードが必要ないシステムだった場合 => 生パスワードが必要ないのに保存してるような馬鹿がハッシュしてから
        送るとか、気の利いたことを出来るわけがない。

        • by Anonymous Coward on 2019年03月25日 20時39分 (#3587142)

          馬鹿を見分けられるじゃないの。
          「何で生パスワードを要求するんですか」みたいな事になる。

          • by Anonymous Coward

            サービスAに認証しているとサービスBでも認証が通る必要がある。
            サービスBはサービスAの認証から時間が経った後に接続される。
            サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。

            • by Anonymous Coward

              サービスAの認証トークン受け取ればよくね?

              • by Anonymous Coward

                サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。

              • by Anonymous Coward

                サービスAをわざわざ出したということは、認証主体はサービスAでサービスBは問い合わせてるだけだろ。
                サービスBに生パスワードを送る必要はなく、サービスBに送った値でサービスAにログインできればいい。

      • by Anonymous Coward

        なんとかの後知恵。2012年頃にパスワードリスト攻撃が認知されるまでは、平文パスワード=問答無用で危険という風潮ではなかった。

        • by Anonymous Coward

          POP -> APOPとか HTTPのDigest認証とか telnet->sshとか ネットに平文pass流すなとは昔から言われてましたが

    • by Anonymous Coward

      ソルトは秘密情報だからいいんじゃないの?
      バレバレのソフトだと、既知のテーブルは使えなくなるがそこはあんまり重要じゃ無くね?

  • by Anonymous Coward on 2019年03月25日 17時42分 (#3587012)

    ハッシュ化の間違いだよね?

    ここに返信
    • by Anonymous Coward

      入っているデータが漏れた場合、暗号かハッシュなのか識別できんの?
      何回ストレッチしてるかしらんし・・・
      複数の暗号化しているかもしらんし・・・

      • by Anonymous Coward

        可逆性があるかないかが重要。

  • by Anonymous Coward on 2019年03月25日 19時15分 (#3587090)

    > バスワード
    > デバック

    ここに返信
    • by Suzuno (48093) on 2019年03月25日 21時20分 (#3587165) 日記

      > バスワード
      > デバック

      仕事(誤字の混入)をちゃんとやってるよね?

    • by Anonymous Coward on 2019年03月25日 21時23分 (#3587167)
      バスワード【bath word・英】

      古代ローマにおいて公衆浴場に入る際に使われた合言葉のこと。合言葉を正しく言えたものは浴場への通過 = pass を許されたことから,後に password に変化したと言われている。

      デバック【de baquet・仏】

      直訳すると「浴槽の」となる。アルキメデスが入浴時に浮力の原理を思いついた出来事に由来し,入浴時に思索にふけることを de baquet と称した。近年では,入浴時にコンピュータプログラムの不良を見つけることを指すことが多くなり,転じて debug という言葉が生まれた。

      民明書房刊「コンピュータと通信 〜フロトコルの発展〜」より。

  • by Anonymous Coward on 2019年03月25日 22時51分 (#3587235)

    パスワードが多数の従業員に晒されて問題というのなら、他の個人情報も同様に閲覧されてはならない。
    逆にそれらの閲覧を問題なしとするなら、パスワードも同様に社外秘の枷が掛かっていると判断できる。

    ここに返信
typodupeerror

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

読み込み中...