アカウント名:
パスワード:
パスワードを復元可能な形式で運用していたら社長以下専務・常務クラスまで獄門晒し首、仕様を作ったエンジニアも二度とIT業界での仕事ができないようにする、ぐらいしても良いのではないか。
GPUクラウドの時代、一般人が付けるような簡単なパスワード(人名+誕生日とか辞書に載っている単語+年号とか)ならSHA-2等でハッシュ化しても現実的な時間で解析できちゃうので無駄です。ソルトとストレッチングやっててもWebサーバで1秒以下で演算できるレベルならGPUクラウドで解析できちゃうし、強度の高いストレッチングやるためにパスワード認証するWebサーバのバックエンドにGPUクラウド使うわけでもないでしょ?
無論、10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワードとかはGPUクラウドで簡単に解析できないので、ハッシュ化の意味はあります。でも、そういう強度の高いパスワードをつけるようなセキュリティマニアは、そもそもパスワードを使いまわししないので、ハッシュ化によるセキュリティ向上の恩恵は受けられないのです。
あと、WEBサーバに不正アクセスされたならパスワードをリアルタイムに悪意のあるサーバに投げるJavaScriptの注入とかもできます。
ってことで、パスワードのハッシュ化なんてものは今の時代たいして役にたちません。パスワードやそのハッシュが漏洩しないようにセキュリティを万全にすることが第一で、そこを破られたらもうどうしようもないのです。
高木浩光大先生も、パスワードを使いまわししないのが常識になったのだから、パスワード表示機能はあっても良いと言い出してるね。
高木浩光先生はパスワードの定期的変更不要派で、パスワードのハッシュが漏洩する可能性を考慮してしまうとパスワードの定期的変更が必要派に餌を与えてしまうってことも影響しているだろうけどね(生パスワードの場合漏洩したら解析時間必要なく即悪用される可能性があるので定期的変更しても無駄だが、パスワードハッシュは解析に時間がかかるので定期的変更で攻撃を防げる場合がある)。
2012年https://twitter.com/HiromitsuTakagi/status/198005727317598208 [twitter.com]> しかし、業界の中にはそういう常識を共有していない愚事業者もいるわけで、パスワードをハッシュ化せずに保管したり、(略)するアホが未だ絶えない。
↓
2018年https://twitter.com/HiromitsuTakagi/status/986086337005547520 [twitter.com]> ハッシュ化パスワードを流出させた場合(この場合オフライン攻撃される)を想定する必要がないのは、他のサイトで同じパスワードを使わないのが今日では鉄則だから。
2018年https://twitter.com/HiromitsuTakagi/status/1029730665489547264 [twitter.com]> パスワードはサイト毎に別のものを設定するのが当然となってしまった今日、一周回ってdocomoのパスワード表示機能は妥当な設計ではないか?という時代に突入してきた感ある。
いつまでも昔のセキュリティの常識を絶対だと考えていると、老害扱いされるから気を付けた方が良いよ。昔常識だったパスワードの定期的変更や、入力時のパスワードのマスキング(アスタリスク化)が今では不要となってきているように、世の中は変化していっているから。
パスワードをサイト毎に変えるのが常識と言ってもそれはマニアの間だけで全然末端に浸透してないし、そもそも50個も80個もサイトにアカウントを持ってて全部違うパスワードを付けて覚えるのは不可能。
ヒント:Googleなら先頭にGO、Yahooなら先頭にYA、AmazonならAMをつける
マニアの間だけって、それいつの認識です?今時のスマホは、Webサイトで新たにパスワード設定しようとしたら、長いランダムなパスワードを自動生成して記憶させるかを聞いてくるのがデフォルトになってるでしょう。そしてスマホユーザー率・スマホのみでアクセスするユーザー率は上がってますし、よくわからないままに従うライトユーザーほどサイトごとにバラバラのパスワードになりますよ。
JPCERTがキャンペーンやって総務省も推奨している方法を「マニアの間だけ」って言い切っちゃうのは、あなたの周りの方々の常識の方を疑っちゃいますよねー
> そもそも50個も80個もサイトにアカウントを持ってて全部違うパスワードを付けて覚えるのは不可能。
パスワードマネージャを使うとか、手帳にメモっておくとかいくらでも方法あるでしょ
そもそも、サイトによってパスワードのルールが違う(記号使えというとこがあれば記号禁止のとこもあるし文字数制限もサイトによって違う)ので必ずいくつかのパスワードを使うことになるし、どのサイトにどれだか忘れちゃうからどっちにしろ書き留める必要が出てくるよね
サイトごとに
srad1ujaujasrad2ujaujasrad3ujaujasrad4ujaujasrad5ujauja
と使い分けていて、その一つが漏洩してしまうと、現時点では多分ないとは思っても他のパスワードは変えたくなるよね。
「あれsradの後の数字何番だっけ???」
パスワードマネージャなんてマスターパスワード抜かれたら芋づるに全部やられるから論外ですね。手帳にメモるなんて、なおさら非常識。盗まれたら全部アウトですよ。
で、君はどうやって管理してるのかな?
手帳にメモって自宅に置いてます。
え、盗まれたら、、そもそも手帳が盗まれるくらいなら、もっと大事な物が盗まれています。(さすがに AC)
別の者です。
Webサイトなら例えば、パスワードの接頭辞を123456、後ろにサイト名、github.comなら123456githubとすることにすると管理上のコストは低いよ。それが脆弱かどうかは私には何ともわからないけど、パスワードマネージャーを使うことで攻撃される要素を一つ増やすこととどっちが良いかは私にはもっとわからないな。
普通にパスワード3つくらい使い回しですが?あと末尾の数字つけて変えたり。だいたいみんなそうでしょ?
その程度の使いまわしは「パスワードの定期的な変更はかえって危険」と類似してて今の時代は通用しなくなってきている
普通にパスワードを3パターンほど使いまわしつつサイトごとに違う数字2桁くらい足して変えます。それで十分じゃないですか?
50個も常時サイト訪問することはないし、頻度が低いなら個人宅ならパスワード手帳作るのもひとつの手じゃないかな?手帳がない出先や会社で使うパスワードは5つぐらいなら常時使っていれば出鱈目な文字列のパスワードでも覚えていられる
>>パスワードはサイト毎に別のものを設定するのが当然となってしまった今日これって何処から導かれた結論なのか気になります知らないだけで流出したアカウント情報が元に同一所有者のパスワード被りが近年激減してるとかなんだろうか・・・それとも、パスワード設定時に「他のパスワードと同じ物を使用しないでください」って書かれることが当然になって、責任の所在がパスワードを使いまわしているユーザーに移動したから?
高木先生が言ってるのはたぶん、『セキュリティのために誰が何をやるべきか』みたいな話。
平文のパスワードが漏れると、それを使い回しているユーザに被害が出るので、サービス提供側が、ユーザのパスワードを暗号化するなどして守るべきだった。 ↓暗号解析が容易になって、ちょっと暗号化したくらいでは流出した際の被害は防げなくなってしまった。 ↓サービス側の暗号化では安全が確保できないので、ユーザ側で『パスワードを使い回さない』という対策をとるしかなくなった。 ↓ユーザ側で対策するしかないなら、サービス側は暗号化しない方がむしろ利便性高くていいんじゃないか?
みたいな感じ?
こんなこと言っても揚げ足取りにしかならないけれど、ハッシュ化によるセキュリティ上の恩恵はあるでしょう平文保存だったら即座に不正アクセス可能なんだからそもそもハッシュ化して保存する目的と意味はパスワード使いまわしするユーザーがいてもいなくても変わらない
saltが十分に長くてもGPUクラウドで解析可能なの?
そのsaltが漏洩しないと、どれだけ自信をもって言えるか。
saltは万一のハッシュ漏洩時に簡単にレインボーテーブルが作られない・使われないように、ハッシュ関数自体をユーザーごとにわずかに変える(塩を振って味付けする)ためものなので、平文で保存され、最悪漏洩しても構わないものです。あるsaltのハッシュからパスを推定できたとしても、同じパスの他のユーザはsaltが違うので特定できません。
saltは漏洩している前提。だって、ハッシュ値が漏洩しているんだから。
パスワードをハッシュ化する理由は、サーバー内部のファイルが見られた場合に、パスワードを保存していたら、そのパスワードを使って他のサイトの情報も盗めてしまうから。ハッシュ値が流出しても、それで他のサイトにはログインできない。ハッシュ値をパスワードに戻す必要がある。
パスワードを単純にハッシュ化した場合、すでにレインボーテーブル(あらかじめパスワードとハッシュ値の対応表)が出回っているから、単純なハッシュ化では元のパスワードを復元できてしまう。
そこで、パスワードごとにランダムに生成したsaltを、パスワードに付加してからハッシュ化することで、レインボーテーブルを事実上使えなくする方法がある。
と素人の俺は考えているのだが、間違っていたら突っ込み頼む。
GPUクラウド使えば計算できるんですよ、たぶん
多分想定している攻撃が違うんだと思う。
そこそこの数のアカウントの中から、できるだけ多くのハッシュを解読するという攻撃では、レインボーテーブルは有効だし、その対策として十分長いソルトを付けることも有効。
一方で特定のアカウントのハッシュを解読するという攻撃では、パスワードのバリエーションがsaltのそれより小さくなるところで、効果がほぼ頭打ちになる。
まぁ、被害者の視点に立つなら他人のパスワードがどれだけ漏洩したかは、あまり興味ないよね。
なるほど、ある個人のパスワードをハッシュ値から求める場合は、もうばれているsalt値は意味がないので、純粋な計算量となる。あとはsalt + 生成したパスワード候補 をひたすらGPUでハッシュ化して、入手したハッシュ値と一致するかを試行すればいい。
となるとsaltを使う意味はレインボーテーブルを使えなくして計算量を増やすメリットはあるにしても、もとパスワードが短ければ、GPUクラウドで計算量を大量に用意できれば、比較的短時間に一致させることができる。
つまり、パスワードが短ければ、saltがいくら長くてもランダムでも、無駄だと。とはいえ、ランダムで長いsaltが無駄というわけではないけど。長いパスワードを使っていても、レインボーテーブルに載っていたら、すぐに解かれてしまうから。
他人のパスワードがよくある奴「12345」~で、複数のハッシュが同じ値だとそこから推測できちゃうある意味ソーシャルハック
まあ一般人であれば、アカウントが大量に漏れた場合、セキュリティ対策してない人から狙われるから効果はあるわけですが。
社長だとか芸能人だとか、ピンポイントで狙われそうな人はご愁傷様。
だからソルトを使えって話では?
> 簡単なパスワード(人名+誕生日とか辞書に載っている単語+年号とか)と> 10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワード
の間に、結構な領域があるのでは。(つまり極論では?)
私の場合、英文フレーズの各単語から文字を抽出(=辞書にない)+数字を入れた、10文字程度のパスワード、などを使う。だが、別にセキュリティマニアではないので、
> でも、そういう強度の高いパスワードをつけるようなセキュリティマニアは、そもそもパスワードを使いまわししない
という想定は成り立たない。(主観的なセキュリティクラスごとに、何種類かを使いまわしする)そういう人も少なくないと思うのだが。
むしろ、情報が漏れた場合に「安易なパスワードユーザ」も「ある程度工夫したパスワードを使うユーザ」も、区別なしに瞬時に再利用できる生パスワード保存は、可能な防御もしていない点で、充分に非難されることだと思う。
つまり、今でも業者がハッシュ化の意味は十分あるし、すべきだと思う。
1件のパスワードを現実的な時間で解析できたとしても、480万件のパスワードを現実的な時間で解析できるの?大量のパスワードを得たとして、それを現実的に使えるものにするためには膨大な計算資源が必要となれば、得られた情報の価値が下がる。十分な抑止効果になると思うけど。
ある意味正しいけど、情報の価値はそんなことでは変わらないと思う。屁理屈いうなら1億件のパスワードが漏洩したら、480万件より解析に時間がかかるから抑止効果がより高いということになる。
勿論、ダミーデータを入れる等の対策に意味がないとは言わない。
パスワードを労力無しに取得できるのと、費用をかけて解析しないと解読できないのとでは意味合いが全く違うと思うのですが…
「解析できちゃう」って書いてるけど、そういう記事読んだだけで、やったこともないし、具体的な手順も知らないんだろ。
CHAP認証を提供しているISP(ほぼすべて)が全滅してネットが使えなくなりますね
良くない。パスワードを使い回してるユーザーが罰を受けるべき。コンピュータを利用するすべての人間が、送信したパスワード文字列は利用先サービスがそれを知ることができるのだという事実の意味を正しく認識するべき。
性善説的思想はある程度排除できないと思ってはいるが、パスワード使い回しに関しては安易な性善説に頼り過ぎ。
現実的じゃないもん、サービスごとにパスワード使い回すなんて。
パスワードを使い回してるユーザーが罰を受けるべき。
パスワードマネージャーの脆弱性・バックドアなり、パスワード記録した手帳が盗まれたりで漏洩したとき、「同じパスワードを使い回すな」という表記を免罪符にしてた側が責任とってくれるのかね?
# そもそも多くの国では「サービス事業者はセキュリティきちんとやれ」という法があるけどね# ユーザーには「パスワード使い回すな」なんて超人的なことを要求しながら、自分達は社会のルールすら守れないの?
パスワードを使い回さない人が超人なのではなく、それができない人が不器用で、使い回しちゃう人が愚かなだけだよ。何が超人的なんだか。多少苦労しても、鍵を委ねる事の意味を理解していれば使い回す選択肢は論外と思うのが当然。
Webサービスのパスワードの漏洩に比べてパスワードマネージャー経由の漏洩がどれだけある?手帳を落としたのならその手帳に書かれているサービスのパスワードは変更するべきだね。手帳に載ってる他の情報も相当心配だけど。
サービス事業者に責任取らせる考え方は別にいいけど、本来避けられたはずの被害を受けるのは自分でしかないってことはわかってるんだよね?
一般人はパスワード使いまわししてるよ。だから色々突破されたりしてるわけで。やっぱりパスワード使いまわさずにやれてる人は超人だよ。一般人には無理。
ブラウザの機能として、パスワードが重複していたら警告するとかやらないものなのだろうか。拡張とかではあるんだろうけど。
裁判所からネット犯罪者がインターネットに触れてはならない、投資詐欺師は金融業で仕事をしてはならないという判決を受けることはあっても、犯罪を犯したエンジニアやハッカーがコンピューター業界で働いてはならないという判決を受けたことはないのかな。あってもいいんじゃない。
ケビン・ミトニックですら、出所後はPC業界で働いてますからねぇ・・・
#どっちかって言うとソーシャルハッカーだけどね。
ありえない極論を吐いてせいせいしてるうちは無理でしょうね。
裁判する機会があれば、パスワードを平文で保存していたら、過失を指摘したいところだが、裁判費用が出るぐらい損害を受けて、それが俺にわかることはないだろうから、そんな機会はなさそう。
復元可能(暗号解除)でなかったら比較できないやん少し考えればわかることだが?
なぜ、生に戻して比較する必要があるの?
好意的に解釈すると本当は生パスワードが漏洩したけど、こっそり認証アルゴリズムを変えたら全パスワードが不一致になる(生パスワードではないことになる)ので取り締まれない、とか?
# passwordとかいう「ハッシュ値」が出てきた時点でバレバレだし# パスワードマネージャ等に残っていた記録を寄せ集めればバレるだろうけど# 状況証拠にしかならない
> 好意的に解釈すると
何を言っているのかわからない。
>>> 復元可能(暗号解除)でなかったら比較できないやん
これ、認証には「パスワードを復元して生パスワード同士の比較が必要」と勘違いしている風に読めるのだが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
いい加減に (スコア:0)
パスワードを復元可能な形式で運用していたら社長以下専務・常務クラスまで獄門晒し首、仕様を作ったエンジニアも二度とIT業界での仕事ができないようにする、ぐらいしても良いのではないか。
GPUクラウドの時代、ハッシュ化しても無駄です (スコア:3, 興味深い)
GPUクラウドの時代、一般人が付けるような簡単なパスワード(人名+誕生日とか辞書に載っている単語+年号とか)ならSHA-2等でハッシュ化しても現実的な時間で解析できちゃうので無駄です。
ソルトとストレッチングやっててもWebサーバで1秒以下で演算できるレベルならGPUクラウドで解析できちゃうし、強度の高いストレッチングやるためにパスワード認証するWebサーバのバックエンドにGPUクラウド使うわけでもないでしょ?
無論、10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワードとかはGPUクラウドで簡単に解析できないので、ハッシュ化の意味はあります。
でも、そういう強度の高いパスワードをつけるようなセキュリティマニアは、そもそもパスワードを使いまわししないので、ハッシュ化によるセキュリティ向上の恩恵は受けられないのです。
あと、WEBサーバに不正アクセスされたならパスワードをリアルタイムに悪意のあるサーバに投げるJavaScriptの注入とかもできます
。
ってことで、パスワードのハッシュ化なんてものは今の時代たいして役にたちません。
パスワードやそのハッシュが漏洩しないようにセキュリティを万全にすることが第一で、そこを破られたらもうどうしようもないのです。
高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:4, 興味深い)
高木浩光大先生も、パスワードを使いまわししないのが常識になったのだから、パスワード表示機能はあっても良いと言い出してるね。
高木浩光先生はパスワードの定期的変更不要派で、パスワードのハッシュが漏洩する可能性を考慮してしまうとパスワードの定期的変更が必要派に餌を与えてしまうってことも影響しているだろうけどね(生パスワードの場合漏洩したら解析時間必要なく即悪用される可能性があるので定期的変更しても無駄だが、パスワードハッシュは解析に時間がかかるので定期的変更で攻撃を防げる場合がある)。
2012年
https://twitter.com/HiromitsuTakagi/status/198005727317598208 [twitter.com]
> しかし、業界の中にはそういう常識を共有していない愚事業者もいるわけで、パスワードをハッシュ化せずに保管したり、(略)するアホが未だ絶えない。
↓
2018年
https://twitter.com/HiromitsuTakagi/status/986086337005547520 [twitter.com]
> ハッシュ化パスワードを流出させた場合(この場合オフライン攻撃される)を想定する必要がないのは、他のサイトで同じパスワードを使わないのが今日では鉄則だから。
2018年
https://twitter.com/HiromitsuTakagi/status/1029730665489547264 [twitter.com]
> パスワードはサイト毎に別のものを設定するのが当然となってしまった今日、一周回ってdocomoのパスワード表示機能は妥当な設計ではないか?という時代に突入してきた感ある。
いつまでも昔のセキュリティの常識を絶対だと考えていると、老害扱いされるから気を付けた方が良いよ。
昔常識だったパスワードの定期的変更や、入力時のパスワードのマスキング(アスタリスク化)が今では不要となってきているように、世の中は変化していっているから。
Re: (スコア:0)
パスワードをサイト毎に変えるのが常識と言ってもそれはマニアの間だけで全然末端に浸透してないし、
そもそも50個も80個もサイトにアカウントを持ってて全部違うパスワードを付けて覚えるのは不可能。
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
ヒント:Googleなら先頭にGO、Yahooなら先頭にYA、AmazonならAMをつける
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
マニアの間だけって、それいつの認識です?
今時のスマホは、Webサイトで新たにパスワード設定しようとしたら、長いランダムなパスワードを自動生成して記憶させるかを聞いてくるのがデフォルトになってるでしょう。
そしてスマホユーザー率・スマホのみでアクセスするユーザー率は上がってますし、よくわからないままに従うライトユーザーほどサイトごとにバラバラのパスワードになりますよ。
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
JPCERTがキャンペーンやって総務省も推奨している方法を
「マニアの間だけ」って言い切っちゃうのは、
あなたの周りの方々の常識の方を疑っちゃいますよねー
Re: (スコア:0)
> そもそも50個も80個もサイトにアカウントを持ってて全部違うパスワードを付けて覚えるのは不可能。
パスワードマネージャを使うとか、手帳にメモっておくとかいくらでも方法あるでしょ
そもそも、サイトによってパスワードのルールが違う(記号使えというとこがあれば記号禁止のとこもあるし文字数制限もサイトによって違う)ので必ずいくつかのパスワードを使うことになるし、どのサイトにどれだか忘れちゃうからどっちにしろ書き留める必要が出てくるよね
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
サイトごとに
srad1ujauja
srad2ujauja
srad3ujauja
srad4ujauja
srad5ujauja
と使い分けていて、その一つが漏洩してしまうと、現時点では多分ないとは思っても他のパスワードは変えたくなるよね。
Re: (スコア:0)
「あれsradの後の数字何番だっけ???」
Re: (スコア:0)
パスワードマネージャなんてマスターパスワード抜かれたら芋づるに全部やられるから論外ですね。
手帳にメモるなんて、なおさら非常識。盗まれたら全部アウトですよ。
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
で、君はどうやって管理してるのかな?
Re: (スコア:0)
手帳にメモって自宅に置いてます。
え、盗まれたら、、
そもそも手帳が盗まれるくらいなら、もっと大事な物が盗まれています。
(さすがに AC)
Re: (スコア:0)
別の者です。
Webサイトなら例えば、パスワードの接頭辞を123456、後ろにサイト名、github.comなら123456githubとすることにすると
管理上のコストは低いよ。
それが脆弱かどうかは私には何ともわからないけど、パスワードマネージャーを使うことで攻撃される要素を一つ増やすことと
どっちが良いかは私にはもっとわからないな。
Re: (スコア:0)
普通にパスワード3つくらい使い回しですが?
あと末尾の数字つけて変えたり。
だいたいみんなそうでしょ?
Re: (スコア:0)
その程度の使いまわしは
「パスワードの定期的な変更はかえって危険」
と類似してて今の時代は通用しなくなってきている
Re: (スコア:0)
普通にパスワードを3パターンほど使いまわしつつ
サイトごとに違う数字2桁くらい足して変えます。
それで十分じゃないですか?
Re: (スコア:0)
50個も常時サイト訪問することはないし、頻度が低いなら個人宅ならパスワード手帳作るのもひとつの手じゃないかな?
手帳がない出先や会社で使うパスワードは5つぐらいなら常時使っていれば出鱈目な文字列のパスワードでも覚えていられる
Re: (スコア:0)
>>パスワードはサイト毎に別のものを設定するのが当然となってしまった今日
これって何処から導かれた結論なのか気になります
知らないだけで流出したアカウント情報が元に同一所有者のパスワード被りが近年激減してるとかなんだろうか・・・
それとも、パスワード設定時に「他のパスワードと同じ物を使用しないでください」って書かれることが当然になって、
責任の所在がパスワードを使いまわしているユーザーに移動したから?
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
高木先生が言ってるのはたぶん、
『セキュリティのために誰が何をやるべきか』
みたいな話。
平文のパスワードが漏れると、それを使い回しているユーザに被害が出るので、
サービス提供側が、ユーザのパスワードを暗号化するなどして守るべきだった。
↓
暗号解析が容易になって、ちょっと暗号化したくらいでは流出した際の被害は防げなくなってしまった。
↓
サービス側の暗号化では安全が確保できないので、ユーザ側で『パスワードを使い回さない』という対策をとるしかなくなった。
↓
ユーザ側で対策するしかないなら、サービス側は暗号化しない方がむしろ利便性高くていいんじゃないか?
みたいな感じ?
Re: (スコア:0)
こんなこと言っても揚げ足取りにしかならないけれど、ハッシュ化によるセキュリティ上の恩恵はあるでしょう
平文保存だったら即座に不正アクセス可能なんだから
そもそもハッシュ化して保存する目的と意味はパスワード使いまわしするユーザーがいてもいなくても変わらない
Re: (スコア:0)
saltが十分に長くてもGPUクラウドで解析可能なの?
Re: (スコア:0)
そのsaltが漏洩しないと、どれだけ自信をもって言えるか。
Re:GPUクラウドの時代、ハッシュ化しても無駄です (スコア:2)
saltは万一のハッシュ漏洩時に簡単にレインボーテーブルが作られない・使われないように、ハッシュ関数自体をユーザーごとにわずかに変える(塩を振って味付けする)ためものなので、平文で保存され、最悪漏洩しても構わないものです。
あるsaltのハッシュからパスを推定できたとしても、同じパスの他のユーザはsaltが違うので特定できません。
Re: (スコア:0)
saltは漏洩している前提。
だって、ハッシュ値が漏洩しているんだから。
パスワードをハッシュ化する理由は、サーバー内部のファイルが見られた場合に、パスワードを保存していたら、そのパスワードを使って他のサイトの情報も盗めてしまうから。
ハッシュ値が流出しても、それで他のサイトにはログインできない。ハッシュ値をパスワードに戻す必要がある。
パスワードを単純にハッシュ化した場合、すでにレインボーテーブル(あらかじめパスワードとハッシュ値の対応表)が出回っているから、単純なハッシュ化では元のパスワードを復元できてしまう。
そこで、パスワードごとにランダムに生成したsaltを、パスワードに付加してからハッシュ化することで、レインボーテーブルを事実上使えなくする方法がある。
と素人の俺は考えているのだが、間違っていたら突っ込み頼む。
Re: (スコア:0)
GPUクラウド使えば計算できるんですよ、たぶん
Re: (スコア:0)
多分想定している攻撃が違うんだと思う。
そこそこの数のアカウントの中から、できるだけ多くのハッシュを解読するという攻撃では、レインボーテーブルは有効だし、その対策として十分長いソルトを付けることも有効。
一方で特定のアカウントのハッシュを解読するという攻撃では、パスワードのバリエーションがsaltのそれより小さくなるところで、効果がほぼ頭打ちになる。
まぁ、被害者の視点に立つなら他人のパスワードがどれだけ漏洩したかは、あまり興味ないよね。
Re: (スコア:0)
なるほど、ある個人のパスワードをハッシュ値から求める場合は、もうばれているsalt値は意味がないので、純粋な計算量となる。
あとはsalt + 生成したパスワード候補 をひたすらGPUでハッシュ化して、入手したハッシュ値と一致するかを試行すればいい。
となるとsaltを使う意味はレインボーテーブルを使えなくして計算量を増やすメリットはあるにしても、
もとパスワードが短ければ、GPUクラウドで計算量を大量に用意できれば、比較的短時間に一致させることができる。
つまり、パスワードが短ければ、saltがいくら長くてもランダムでも、無駄だと。
とはいえ、ランダムで長いsaltが無駄というわけではないけど。
長いパスワードを使っていても、レインボーテーブルに載っていたら、すぐに解かれてしまうから。
Re: (スコア:0)
他人のパスワードがよくある奴「12345」~で、
複数のハッシュが同じ値だとそこから推測できちゃう
ある意味ソーシャルハック
Re: (スコア:0)
まあ一般人であれば、アカウントが大量に漏れた場合、セキュリティ対策してない人から狙われるから効果はあるわけですが。
社長だとか芸能人だとか、ピンポイントで狙われそうな人はご愁傷様。
Re: (スコア:0)
だからソルトを使えって話では?
極論では (スコア:0)
> 簡単なパスワード(人名+誕生日とか辞書に載っている単語+年号とか)
と
> 10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワード
の間に、結構な領域があるのでは。(つまり極論では?)
私の場合、英文フレーズの各単語から文字を抽出(=辞書にない)+数字を入れた、10文字程度のパスワード、などを使う。
だが、別にセキュリティマニアではないので、
> でも、そういう強度の高いパスワードをつけるようなセキュリティマニアは、そもそもパスワードを使いまわししない
という想定は成り立たない。(主観的なセキュリティクラスごとに、何種類かを使いまわしする)
そういう人も少なくないと思うのだが。
むしろ、情報が漏れた場合に「安易なパスワードユーザ」も「ある程度工夫したパスワードを使うユーザ」も、区別なしに瞬時に再利用できる生パスワード保存は、可能な防御もしていない点で、充分に非難されることだと思う。
つまり、今でも業者がハッシュ化の意味は十分あるし、すべきだと思う。
Re: (スコア:0)
1件のパスワードを現実的な時間で解析できたとしても、480万件のパスワードを現実的な時間で解析できるの?
大量のパスワードを得たとして、それを現実的に使えるものにするためには膨大な計算資源が必要となれば、得られた情報の価値が下がる。
十分な抑止効果になると思うけど。
Re: (スコア:0)
ある意味正しいけど、情報の価値はそんなことでは変わらないと思う。
屁理屈いうなら1億件のパスワードが漏洩したら、480万件より解析に時間がかかるから抑止効果がより高いということになる。
勿論、ダミーデータを入れる等の対策に意味がないとは言わない。
Re: (スコア:0)
パスワードを労力無しに取得できるのと、費用をかけて解析しないと解読できないのとでは
意味合いが全く違うと思うのですが…
Re: (スコア:0)
「解析できちゃう」って書いてるけど、そういう記事読んだだけで、やったこともないし、具体的な手順も知らないんだろ。
Re:いい加減に (スコア:1)
CHAP認証を提供しているISP(ほぼすべて)が全滅してネットが使えなくなりますね
Re:いい加減に (スコア:1)
良くない。
パスワードを使い回してるユーザーが罰を受けるべき。
コンピュータを利用するすべての人間が、送信したパスワード文字列は
利用先サービスがそれを知ることができるのだという事実の意味を正しく認識するべき。
性善説的思想はある程度排除できないと思ってはいるが、パスワード使い回しに関しては安易な性善説に頼り過ぎ。
Re: (スコア:0)
現実的じゃないもん、サービスごとにパスワード使い回すなんて。
パスワードを使い回してるユーザーが罰を受けるべき。
パスワードマネージャーの脆弱性・バックドアなり、パスワード記録した手帳が盗まれたりで漏洩したとき、「同じパスワードを使い回すな」という表記を免罪符にしてた側が責任とってくれるのかね?
# そもそも多くの国では「サービス事業者はセキュリティきちんとやれ」という法があるけどね
# ユーザーには「パスワード使い回すな」なんて超人的なことを要求しながら、自分達は社会のルールすら守れないの?
Re: (スコア:0)
パスワードを使い回さない人が超人なのではなく、それができない人が不器用で、使い回しちゃう人が愚かなだけだよ。何が超人的なんだか。
多少苦労しても、鍵を委ねる事の意味を理解していれば使い回す選択肢は論外と思うのが当然。
Webサービスのパスワードの漏洩に比べてパスワードマネージャー経由の漏洩がどれだけある?
手帳を落としたのならその手帳に書かれているサービスのパスワードは変更するべきだね。手帳に載ってる他の情報も相当心配だけど。
サービス事業者に責任取らせる考え方は別にいいけど、本来避けられたはずの被害を受けるのは自分でしかないってことはわかってるんだよね?
Re: (スコア:0)
一般人はパスワード使いまわししてるよ。だから色々突破されたりしてるわけで。
やっぱりパスワード使いまわさずにやれてる人は超人だよ。一般人には無理。
Re:いい加減に (スコア:1)
ブラウザの機能として、パスワードが重複していたら警告するとかやらないものなのだろうか。拡張とかではあるんだろうけど。
Re: (スコア:0)
裁判所からネット犯罪者がインターネットに触れてはならない、投資詐欺師は金融業で仕事をしてはならないという判決を受けることはあっても、
犯罪を犯したエンジニアやハッカーがコンピューター業界で働いてはならないという判決を受けたことはないのかな。あってもいいんじゃない。
Re: (スコア:0)
ケビン・ミトニックですら、出所後はPC業界で働いてますからねぇ・・・
#どっちかって言うとソーシャルハッカーだけどね。
Re: (スコア:0)
ありえない極論を吐いてせいせいしてるうちは無理でしょうね。
Re: (スコア:0)
裁判する機会があれば、パスワードを平文で保存していたら、過失を指摘したいところだが、裁判費用が出るぐらい損害を受けて、それが俺にわかることはないだろうから、そんな機会はなさそう。
Re: (スコア:0)
復元可能(暗号解除)でなかったら比較できないやん
少し考えればわかることだが?
Re: (スコア:0)
なぜ、生に戻して比較する必要があるの?
Re: (スコア:0)
好意的に解釈すると
本当は生パスワードが漏洩したけど、こっそり認証アルゴリズムを変えたら全パスワードが不一致になる(生パスワードではないことになる)ので取り締まれない、
とか?
# passwordとかいう「ハッシュ値」が出てきた時点でバレバレだし
# パスワードマネージャ等に残っていた記録を寄せ集めればバレるだろうけど
# 状況証拠にしかならない
Re: (スコア:0)
> 好意的に解釈すると
何を言っているのかわからない。
>>> 復元可能(暗号解除)でなかったら比較できないやん
これ、認証には「パスワードを復元して生パスワード同士の比較が必要」と勘違いしている風に読めるのだが。