パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Facebook、数億人分のユーザーパスワードを数年間可読状態で保存と発表」記事へのコメント

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

    • by Anonymous Coward

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

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

      • by Anonymous Coward

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

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

        • by Anonymous Coward

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

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

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

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

            親コメント

ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家

処理中...