アカウント名:
パスワード:
公式 blog [linkedin.com] の記述だと、
... the enhanced security we just recently put in place, which includes hashing and salting of our current password databases.
という事は、対策を取る前は、ソルトはおろか、ハッシュ値でもなかった、とも読めるんだけど、ホント？
最初に徳丸さんのツイート [twitter.com]を読んで、対策前はソルトなしで、ソルトを付けるようになった、という話かと思ったんだけど、でも、掲載されているデータがソルト無しの SHA-1 だったからといって、LinkedIn がソルト無しの SHA-1 だったという保証はなくて、生パスワードをごっそり持っていて、SHA-1 にして公開した、という可能性もあるかなぁ、と。
IT Pro のニュース記事 [nikkeibp.co.jp]によると、とりあえず、ソルト無しのハッシュ値だったみたいですね。
元米Yahoo!副社長兼最高情報セキュリティ責任者のGanesh Krishnan氏などの専門家で構成されるセキュリティチームのもと、これまでハッシュアルゴリズムによる暗号化のみだったパスワードのデータベースシステムに、ソルト（salt）と呼ばれる暗号強化技術を導入した。
「ひょっとしたら生？」というのが、私の杞憂だったということで、ちょっとホっとした。
ソルトもハッシュも法律で義務付けられてるわけじゃないからね。平文保存なんて世界中で行われていると思うよ。
個人的には、非公開の個人情報が盗まれている時点でアウトで、ハッシュ値だからセーフという訳でも無いと思うので、平文保存はいかんという論理も少し腑に落ちきらないところがあります。管理側の人間にも容易に確認されないようにとの主張もありますが、どちらかというとその他の個人データの方が見られたく無い訳で。また、利用者視点では管理側の不正やミスを疑い、パスワードの使い回しは避けるのが当然の姿勢と思います。
とは言え、このように実際に事故が起きた時、平文で持ってたことがバレるとみっともないとは思うんですよね。
管理側の人間にも容易に確認されないようにとの主張もありますが、どちらかというとその他の個人データの方が見られたく無い訳で。
容易に確認出来ると、単に「見られる」というだけじゃなくて、「なりすまし」が可能になるわけで...
単純なハッシュ値だと、レインボーテーブルを使って、短時間で解析可能、という問題はあるので、気休めかもしれませんが、ソルト付きであれば、きちんとしたパスワードであれば、ブルートフォースで見つかるまで、それなりに時間が稼げるので、ソルト付きハッシュ値の形式での流出であれば、発覚してからパスワードを変更しても、充分に間に合う事が期待できます。
実際のパスワード流出の経路としては、管理サイドからよりも、マルウェアやニセサイトを使った、クライアント側から奪取の方が多いと思うので、こうした、サーバサイドでの努力だけでは防げないのが現実だと思いますが、サーバ側をきちんとしていれば、きちんとしたユーザは救える（少なくとも、エンドユーザがパスワードを変更するまでの時間稼ぎは出来る）ことになります。
いっそ、既にソルト付きっぽく見えるパスワードを運用してはどうだろう。『漏れたパスワードがどんな状態なのかを最終的に判断するのは人間』ということを利用した高度な自己防衛だ！
# $1$qwertyui$abcdefghijklmnopqrstuv ……ねぇな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
どうやって、パスワードを保存していたのか？ (スコア:1)
公式 blog [linkedin.com] の記述だと、
という事は、対策を取る前は、ソルトはおろか、ハッシュ値でもなかった、とも読めるんだけど、ホント？
最初に徳丸さんのツイート [twitter.com]を読んで、対策前はソルトなしで、ソルトを付けるようになった、という話かと思ったんだけど、でも、掲載されているデータがソルト無しの SHA-1 だったからといって、LinkedIn がソルト無しの SHA-1 だったという保証はなくて、生パスワードをごっそり持っていて、SHA-1 にして公開した、という可能性もあるかなぁ、と。
Re:どうやって、パスワードを保存していたのか？ (スコア:1)
IT Pro のニュース記事 [nikkeibp.co.jp]によると、とりあえず、ソルト無しのハッシュ値だったみたいですね。
「ひょっとしたら生？」というのが、私の杞憂だったということで、ちょっとホっとした。
Re: (スコア:0)
ソルトもハッシュも法律で義務付けられてるわけじゃないからね。
平文保存なんて世界中で行われていると思うよ。
Re: (スコア:0)
個人的には、非公開の個人情報が盗まれている時点でアウトで、ハッシュ値だからセーフという訳でも無いと思うので、
平文保存はいかんという論理も少し腑に落ちきらないところがあります。
管理側の人間にも容易に確認されないようにとの主張もありますが、どちらかというとその他の個人データの方が見られたく無い訳で。
また、利用者視点では管理側の不正やミスを疑い、パスワードの使い回しは避けるのが当然の姿勢と思います。
とは言え、このように実際に事故が起きた時、平文で持ってたことがバレるとみっともないとは思うんですよね。
Re:どうやって、パスワードを保存していたのか？ (スコア:2)
容易に確認出来ると、単に「見られる」というだけじゃなくて、「なりすまし」が可能になるわけで...
単純なハッシュ値だと、レインボーテーブルを使って、短時間で解析可能、という問題はあるので、気休めかもしれませんが、ソルト付きであれば、きちんとしたパスワードであれば、ブルートフォースで見つかるまで、それなりに時間が稼げるので、ソルト付きハッシュ値の形式での流出であれば、発覚してからパスワードを変更しても、充分に間に合う事が期待できます。
実際のパスワード流出の経路としては、管理サイドからよりも、マルウェアやニセサイトを使った、クライアント側から奪取の方が多いと思うので、こうした、サーバサイドでの努力だけでは防げないのが現実だと思いますが、サーバ側をきちんとしていれば、きちんとしたユーザは救える（少なくとも、エンドユーザがパスワードを変更するまでの時間稼ぎは出来る）ことになります。
Re: (スコア:0)
いっそ、既にソルト付きっぽく見えるパスワードを運用してはどうだろう。
『漏れたパスワードがどんな状態なのかを最終的に判断するのは人間』ということを利用した高度な自己防衛だ！
# $1$qwertyui$abcdefghijklmnopqrstuv ……ねぇな。