アカウント名:
パスワード:
運用コスト問題(ユーザーの使いやすさとかも含む)がある以上、「絶対に流出しないシステム」なんてのは不可能。そのうえで「万が一流出しても実質的な被害を出さない・最小限におさえる」ことも現実的なセキュリティ対策として大事になってくる。
その上で今回の「LastPass」の事例は、・十分に暗号化したデータだった(流失時に備えたデータ保存をしていた)・それでも危険度が高くなるものについてある程度指針を持って提示している(簡易すぎるパスワード)・データ流出発覚後割と早く適切な発表を行った(それを受けた報道機関が適切な情報を流すかは別)
というところで及第点なのでは。(とりあえず今入ってくる情報のみで判断すれば9
#括弧多すぎぃ…
> ハッシュ化も10万回実施されているので、よほど脆弱なマスターパスワードでなければ、解読される可能性は極めて低いそれこそストレッチングを魔法の言葉のようにミスリードさせられてませんかね?ハッシュの演算時間が定数オーダで増えるだけで、強度的は一切強化されませんよ。
攻撃側は現実的な時間内で攻撃するためにハッシュ関数の最適化や攻撃の最適化を行う上にハッシュに対する攻撃は1度で十分です。攻撃側演算量と防御側演算量の比(パスワード長に依存する)は、ストレッチングするとそうでない場合に比べて「圧倒的に悪化」します。ストレッチングはシステムの演算資源が余ってる場合にその範囲内で行うならば有意義ですが、そうでなければ泥縄です。
効果が無いとは言えないというか実際有効だろうけど、ソルトの導入などに比べるとコストも効果もかなり見劣りします。
# 暗号化済みユーザーデータが漏れてないというのは安心だけど、その調査はどこまで信用できるのか…# もし漏れてたら完全にオフラインでアタックが完結するからどうにもならんべ、マジで。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
とりあえず公式ソース情報を読めと (スコア:2)
これは酷いミスリード。流出したのは暗号化およびハッシュ化されたものであって、平文ではない。
またハッシュ化も10万回実施されているので、よほど脆弱なマスターパスワードでなければ、解読される可能性は極めて低い。
ソースの公式ブログ記事を貼っておく。
LastPass Security Notice | The LastPass Blog [lastpass.com]
# 絶対安全とは言い切れないが、十分に長いマスターパスワードと多要素認証を使っていれば無視できるレベルだと思う。
ここにつるしとくか (スコア:4, 興味深い)
運用コスト問題(ユーザーの使いやすさとかも含む)がある以上、「絶対に流出しないシステム」なんてのは不可能。
そのうえで「万が一流出しても実質的な被害を出さない・最小限におさえる」ことも
現実的なセキュリティ対策として大事になってくる。
その上で今回の「LastPass」の事例は、
・十分に暗号化したデータだった(流失時に備えたデータ保存をしていた)
・それでも危険度が高くなるものについてある程度指針を持って提示している(簡易すぎるパスワード)
・データ流出発覚後割と早く適切な発表を行った(それを受けた報道機関が適切な情報を流すかは別)
というところで及第点なのでは。(とりあえず今入ってくる情報のみで判断すれば9
#括弧多すぎぃ…
Re: (スコア:0)
> ハッシュ化も10万回実施されているので、よほど脆弱なマスターパスワードでなければ、解読される可能性は極めて低い
それこそストレッチングを魔法の言葉のようにミスリードさせられてませんかね?
ハッシュの演算時間が定数オーダで増えるだけで、強度的は一切強化されませんよ。
攻撃側は現実的な時間内で攻撃するためにハッシュ関数の最適化や攻撃の最適化を行う上にハッシュに対する攻撃は1度で十分です。
攻撃側演算量と防御側演算量の比(パスワード長に依存する)は、ストレッチングするとそうでない場合に比べて「圧倒的に悪化」します。
ストレッチングはシステムの演算資源が余ってる場合にその範囲内で行うならば有意義ですが、そうでなければ泥縄です。
効果が無いとは言えないというか実際有効だろうけど、ソルトの導入などに比べるとコストも効果もかなり見劣りします。
# 暗号化済みユーザーデータが漏れてないというのは安心だけど、その調査はどこまで信用できるのか…
# もし漏れてたら完全にオフラインでアタックが完結するからどうにもならんべ、マジで。