アカウント名:
パスワード:
第三者が端末にログイン出来る=暗号化したストレージに第三者がアクセス出来る前提なら、総当りに耐えられる暗号でないと意味が無い。そして128bitの鍵を作るには少なくとも20文字くらいのパスワードが必要。ほとんどのユーザーが使う8文字くらいのパスワードでは生のまま保存してるのと大差はない。
(パスワードの強さを議論せずに)マスターパスワードさえあれば端末へのアクセスを許してもいい、or 端末にアクセスされても暗号化してさえあればなんとかなる、なんて考える人が出てくるのが実際なんだから>「ユーザーに誤った安心感を与えて危険な行動を助長したくない」ってのの方が真っ当な意見だと思う。
#プライベートブラウジングは終了時に情報を削除する機能なので、次回に復号しなきゃならないパスワードの保存方法とは関係ない
マスタパスワードを設定するメリット/デメリットとして、以下を主張しており、デメリットがメリットに比べて大きいからやらない、ってことを言ってるんだよね。
◆メリット20文字くらいのマスタパスワードを設定すれば安全
◆デメリットマスタパスワードを8文字位に設定する場合、総当たりに耐えられないが、「マスタパスワードを設定したら安心」と思わせてしまう
ko-zu氏にコメントをつけている人はメリットの大小ばかりを議論しているけれど、デメリットと比べて、という視点がないとかみ合わない。デメリットが無視できたら、メリットが少しでもあるものはやるべきという判断になるので。
「ログインできる」=「端末に触ることができる環境」かつ「OSのロックが不適切」なので、アプリケーション側で出来るのは利用するストレージの暗号化だけ。
アプリは強いパスワードを要求することはできるけれど、ユーザーに端末を正しくロックすることを(ICカード証明書のようなハードウェア的なサポートなしには)強制することが出来ない。そして、ブラウザがマスタパスワード入力フォームを出したとして、それが本当にブラウザの出した入力フォームなのか、誰かがインストールしたスパイウェアが模倣した偽の入力フォームなのか、OSの助けが無いとわからない。時々ブラウザのアドレスバーが偽装できてしまう問題も、やってることの階層が違うだけで同根。
ユーザーの不注意で端末のロックが不適切であれば、ブラウザにどんなに強いマスタパスワードをかけても、ユーザーが(偽のフォームに)最初にパスワードを入力した瞬間に漏れることになるので、マスタパスワードは意味が無い。
OSのスクリーンロックを適切に行えば、アプリ側のPWがあってもなくても問題はない。一方で暗号化は、丸ごと盗まれるようなOSのスクリーンロックなどを迂回された場合の保険になるが、それには暗号として弱すぎる。
つまり、アプリ側PWがプラスに作用するのは、「マスタパスワードに強いPWを設定できる」かつ「端末のストレージ全体は暗号化していない」かつ「端末のロックを適切に行い」かつ「盗難などで端末のスクリーンロックが迂回される」場合に限られる。それ以外の人にとって、アプリ側のOS側の両方で複数のパスワードを入力させれば、ロックの頻度や鍵の品質に影響するのは誰の目にも明らかと思う。#暗号としても、64bitの二種類の鍵をかけると衝突まで2^33程度にしかならないが、128bitの鍵一つなら一気に2^64になる
結局、極僅かな(不適切な暗号化の利用法をしている)人のためだけに、アプリ側が意味のないPWフォームを提示することで、殆どの人にとって事態は悪化することになる。それはベターな手法とは言えない。だからこそ、Firefoxなどもマスターパスワードをデフォルトにしていない。
また強い鍵を必要とする人は、端末のストレージ全体を適切な鍵で暗号化しているし、ストレージを二重に暗号化するのは鍵の総当り探索からいって損することになることを理解している。
丁寧な説明ありがとう。#2438595のACだけど、理解して納得した。ko-zu氏の意見が正しい。
デメリット側の危険性からアプローチした方が納得し易いな、これは。この説明で完全に目が覚めたわ。
そして、ブラウザがマスタパスワード入力フォームを出したとして、それが本当にブラウザの出した入力フォームなのか、誰かがインストールしたスパイウェアが模倣した偽の入力フォームなのか、OSの助けが無いとわからない。時々ブラウザのアドレスバーが偽装できてしまう問題も、やってることの階層が違うだけで同根。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
暗号化してもパスワードが弱すぎる (スコア:2)
第三者が端末にログイン出来る=暗号化したストレージに第三者がアクセス出来る前提なら、総当りに耐えられる暗号でないと意味が無い。
そして128bitの鍵を作るには少なくとも20文字くらいのパスワードが必要。ほとんどのユーザーが使う8文字くらいのパスワードでは生のまま保存してるのと大差はない。
(パスワードの強さを議論せずに)マスターパスワードさえあれば端末へのアクセスを許してもいい、or 端末にアクセスされても暗号化してさえあればなんとかなる、なんて考える人が出てくるのが実際なんだから
>「ユーザーに誤った安心感を与えて危険な行動を助長したくない」
ってのの方が真っ当な意見だと思う。
#プライベートブラウジングは終了時に情報を削除する機能なので、次回に復号しなきゃならないパスワードの保存方法とは関係ない
Re: (スコア:0)
マスタパスワードを設定するメリット/デメリットとして、以下を主張しており、
デメリットがメリットに比べて大きいからやらない、ってことを言ってるんだよね。
◆メリット
20文字くらいのマスタパスワードを設定すれば安全
◆デメリット
マスタパスワードを8文字位に設定する場合、総当たりに耐えられないが、
「マスタパスワードを設定したら安心」と思わせてしまう
ko-zu氏にコメントをつけている人はメリットの大小ばかりを議論しているけれど、
デメリットと比べて、という視点がないとかみ合わない。
デメリットが無視できたら、メリットが少しでもあるものはやるべきという判断になるので。
Re:暗号化してもパスワードが弱すぎる (スコア:2)
「ログインできる」=「端末に触ることができる環境」かつ「OSのロックが不適切」
なので、アプリケーション側で出来るのは利用するストレージの暗号化だけ。
アプリは強いパスワードを要求することはできるけれど、ユーザーに端末を正しくロックすることを(ICカード証明書のようなハードウェア的なサポートなしには)強制することが出来ない。
そして、ブラウザがマスタパスワード入力フォームを出したとして、それが本当にブラウザの出した入力フォームなのか、誰かがインストールしたスパイウェアが模倣した偽の入力フォームなのか、OSの助けが無いとわからない。時々ブラウザのアドレスバーが偽装できてしまう問題も、やってることの階層が違うだけで同根。
ユーザーの不注意で端末のロックが不適切であれば、ブラウザにどんなに強いマスタパスワードをかけても、ユーザーが(偽のフォームに)最初にパスワードを入力した瞬間に漏れることになるので、マスタパスワードは意味が無い。
OSのスクリーンロックを適切に行えば、アプリ側のPWがあってもなくても問題はない。一方で暗号化は、丸ごと盗まれるようなOSのスクリーンロックなどを迂回された場合の保険になるが、それには暗号として弱すぎる。
つまり、アプリ側PWがプラスに作用するのは、「マスタパスワードに強いPWを設定できる」かつ「端末のストレージ全体は暗号化していない」かつ「端末のロックを適切に行い」かつ「盗難などで端末のスクリーンロックが迂回される」場合に限られる。
それ以外の人にとって、アプリ側のOS側の両方で複数のパスワードを入力させれば、ロックの頻度や鍵の品質に影響するのは誰の目にも明らかと思う。
#暗号としても、64bitの二種類の鍵をかけると衝突まで2^33程度にしかならないが、128bitの鍵一つなら一気に2^64になる
結局、極僅かな(不適切な暗号化の利用法をしている)人のためだけに、アプリ側が意味のないPWフォームを提示することで、殆どの人にとって事態は悪化することになる。それはベターな手法とは言えない。だからこそ、Firefoxなどもマスターパスワードをデフォルトにしていない。
また強い鍵を必要とする人は、端末のストレージ全体を適切な鍵で暗号化しているし、ストレージを二重に暗号化するのは鍵の総当り探索からいって損することになることを理解している。
Re:暗号化してもパスワードが弱すぎる (スコア:1)
丁寧な説明ありがとう。
#2438595のACだけど、理解して納得した。ko-zu氏の意見が正しい。
デメリット側の危険性からアプローチした方が納得し易いな、これは。この説明で完全に目が覚めたわ。
そして、ブラウザがマスタパスワード入力フォームを出したとして、それが本当にブラウザの出した入力フォームなのか、誰かがインストールしたスパイウェアが模倣した偽の入力フォームなのか、OSの助けが無いとわからない。時々ブラウザのアドレスバーが偽装できてしまう問題も、やってることの階層が違うだけで同根。
ユーザーの不注意で端末のロックが不適切であれば、ブラウザにどんなに強いマスタパスワードをかけても、ユーザーが(偽のフォームに)最初にパスワードを入力した瞬間に漏れることになるので、マスタパスワードは意味が無い。