アカウント名:
パスワード:
パスワードを保管しているファイルが盗まれなければ。
たとえば、どこかの企業が物凄くセキュリティレベルが低くて、そこに侵入したらユーザー名とパスワードの一覧表を盗むことができた、としましょう。ただし、パスワードはハッシュ化されているので、そのままでは使えません。
今回の実験から、GPUを使うとこのファイルからパスワードを推測することが可能だ、ということが判ります。もし、同じユーザーが別の所でも同じユーザー名とパスワードを使っていたら、きっと侵入できるでしょう。そのテストを行うのには、1サイト1ユーザー名あたり1回のテストで済みます。
100万人のユーザー情報があって、10%が同じパスワードを違う場所でも使っているとするなら、10万人分の情報が手に入ったわけです。
> たとえば、どこかの企業が物凄くセキュリティレベルが低くて、そこに侵入したらユーザー名とパスワードの一覧表を盗むことができた、としましょう。ただし、パスワードはハッシュ化されているので、そのままでは使えません。なぜだかちっともたとえ話という気がしない。
そのあそこはパスワード入力ミスっても何回でも入力できるんだよな一定回数ミスったらあとは翌日ねみたいなのがないという…
こういうネタと一緒に見ると恐ろしい仕様だ
今利用している埼玉りそなが文字数制限短くてちょっと不安なんですよねえ。制限する意味が分からない。DBに平文固定長で保存しているんじゃないかと疑いたくなります。
>銀行は数字4桁の暗唱番号破られたら客の責任
三回ミスると銀行にお電話というパターンがあったのだけど、それは今はなくなったのかな?
ATMで別のカードの暗証番号入力してロックされた俺をお呼びかね?
窓口出頭→キャッシュカード再発行(勿論手数料発生)となりました。
# 給与振込口座で、普段遠地にいるのでダメージ甚大でした(泣)# キャッシュカード発行も一週間かかるといわれたので、当座の現金を印鑑で下ろしましたよ
>窓口出頭→キャッシュカード再発行(勿論手数料発生)となりました。
銀行によってはそうなるんだ。わたしの場合、三井住友でやっちまって、電話でオケ、次からはちゃんとしてね..で済んだけど、金融機関によっては再発行もあるんだね。
昔書いたコメント [srad.jp]ですが
2回間違えると、ものすごく緊張しますね。あるカードの暗証番号を、覚えやすい4桁ってことで「1024」「2048」「4096」「8192」のどれかにしてたのですがめったに使わない口座なのでそのどれだったかをすぐ忘れてしまいます。候補が4つでチャンスが3回なのでものすごい博打です。#3回間違えたことが1回、3回目で成功したことが数度…
2回間違えると、ものすごく緊張しますね。
あるカードの暗証番号を、覚えやすい4桁ってことで「1024」「2048」「4096」「8192」のどれかにしてたのですがめったに使わない口座なのでそのどれだったかをすぐ忘れてしまいます。候補が4つでチャンスが3回なのでものすごい博打です。
#3回間違えたことが1回、3回目で成功したことが数度…
というわけで3回間違えたことが何度かあるの
昔はカードの磁気ストライプ部に暗証番号が入ってましたからね。窓口にライターがなければ再発行するしかなかったのでしょう。今はカード側には記録されておらず、サーバー側での管理なので再発行は必要ないのかと。
親コメのAC [srad.jp]ですが、そのコメントのリンク [bk.mufg.jp]で示したとおり、三菱東京UFJ銀行が、暗証番号3回ミスってロックした場合、「磁気カードの場合はカード再発行」「ICカードの場合は窓口で対応可能」になるのは昔話ではなく今現在の話です。
#そもそも、三菱東京UFJ銀行で、って書いてる時点でそれほどの昔話じゃないわけですが…
> 昔はカードの磁気ストライプ部に暗証番号が入ってましたからね。
1987年以前 [google.co.jp]の話をしているのだと思いますが、その時問題になったのは「カードに暗証番号が記録されていて」「ATMはカードに記録
三菱(ry は今でも再発行なんですか。再発行すると何が変わるんでしょうね。口座番号以外に何か記録されているのだろうか…再発行フラグか何かあるのかな。
昔は磁気データの先頭部分に暗証番号が入っていて、それが問題になって0フィルされた後も別の位置に暗号化されて入ってたりしましたけど、それがまだ尾を引いているのかな…
ユーザーのこういう間抜けな行動も厳しく責めるべきではないでしょうか。
1) どうやって、「ユーザーが間抜けな行動をとっているかどうか」を確認するか?
2) ただでさえ、たくさんのパスワード設定/変更が嫌で「シングル・サイン・オン」を求めているユーザーにそのようなポリシーをお願いすることが可能か?
3) 仮に押し付けることができたとすると、ユーザーは簡単にあちらこちらの都合が良いサービスを選択・組み合わせる事がしにくくなりますよね? それってITビジネスに参入障壁を設けているだけにならない??
4) 現実問題としては、ユーザー名とパスワードをどこか1箇所で盗まれた場合、自分の使っているITサービスの他のものにも問題が波及する、というリスクはユーザーが被ってるんだから、文句を言われる筋合いはない、という反論にどう対処するか? (公害問題とかと同じ種類の問題になります)
とパッと考えても4つ問題が出ますね。
「弱いパスワードを使うことで破られるリスクがある」
⇒ ピコーン! ログインIDを変えさせればいいんじゃね?
ということで,わざわざ社内システムのアカウント名に「社員ID以外のIDを使うように」という意味の分からないお達しが来たうちはどうすれば…
>⇒ ピコーン! ログインIDを変えさせればいいんじゃね?ちなみに自分は幾つかのサイトで複雑なIDを取得してます。#たとえばこんな感じの→ zdj9EyW2clyrDq7hQK2Zq
>>> もし、同じユーザーが別の所でも同じユーザー名とパスワードを使っていたら>>企業にちゃんとしたセキュリティを望むのと同様にこれは全く同感。
>>たくさんのパスワード設定/変更が嫌で「シングル・サイン・オン」を求めているユーザーにそのようなポリシーをお願いすることが可能か?
無理でしょう。バカに付ける薬は無いから。暗証番号に生年月日や1234を使うことさえ強制は難しい。
実害を被るのは当人ですから、特に責める必要はないんじゃないですかね。その責を管理側に求めるのは流石にお門違いですし。
警告はしてあげるのが親切でしょうが。
「元記事を読め」ということではないでしょうか
アカウントハックが日常的に頻発してる某ネトゲですが支払い時のアカウントとゲームアカウントが別になってるタイプで支払いアカウントは携帯認証あるのに消費する方のゲームアカウントには携帯認証が無いという素敵仕様やられる奴が悪いといえばそれまでなんだけどここまで運営会社が無対応だともう内部犯行なんじゃないかと
大企業の機密情報なんか盗んでもそうそう捌けないけどネトゲのRMTならちょっと調べれば誰でもできるここが犯罪の主戦場なんだからどこか公的機関でなんとかしてくれないもんですかね…
>> 大企業の機密情報なんか盗んでもそうそう捌けないけど>> ネトゲのRMTならちょっと調べれば誰でもできる>> ここが犯罪の主戦場なんだからどこか公的機関でなんとかしてくれないもんですかね…
社団法人リアルマネートレーディング対策協議会(仮)、とかいう団体を作って警察やら経済産業省やらの天下りを受け入れてあげれば一発じゃないかと。
♯ついでに、RMTを取り締まる法的根拠も必要ですけどね。
マビノギですね、わかりますorz
上記が正解の前提で書きますが、ワンタイムパスワードを利用するためのアプリがガラケーのみ対応というさらなる素敵仕様で泣きが入ってます。
早くスマホ対応してくれないと困ります……。
さすがに3回でロックアウトするだけでは・・・・パスワードを固定して、IDの方をぶん回すという方法もあるわけですから。
会員数でロックアウトするのと同じだから、会員数が相当多くないと有効でない。
同意。
復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、ネットワーク越しの話なら、律速になるのはクラッカー側の演算能力ではないと思います。 ロックアウトでもいいし、1秒に1回しかログインできないとかにしてしまえばCPUでもGPUでも一緒です
>>復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、>>ネットワーク越しの話なら、律速になるのはクラッカー側の演算能力ではないと思います。
そんなことはない。通信をキャプチャされれば暗号化された通信が復号される可能性はある。
ログインされることだけが損害ではない。
SSLの暗号に使われている鍵は人間様が覚えておける長さという制約のあるパスワードよりずっと長いから、破るのもはるかに困難。今のところGPUを使う程度のことではとても現実的な時間では解けない。まあ>>復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、これも対策はすでに考えられてて、ストレッチングと呼ばれているけど。
1024bit RSA が危ないとか言われるようになったのは、現実的な時間では解けないとされていたのがそうでもなくなったからなんだけどね。
それに現在収集されてるパケットは10年以内には解読されるだろうしね。
>通信内容を傍受するなら、共通鍵暗号方式で暗号化されたデータストリームに対する総当たりで済む。
その共通鍵は使い捨てだから、セッションが有効なうちに解読に成功しなきゃいけない。よほど共通鍵の暗号強度が低くないかぎり、有効期限10年があたりまえなルート証明書の解析を頑張った方がマシだね。
それってディクショナリ式じゃないの?総当たりって文字通り総当たりだと思うんだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
総当たりチェックなど・・・・ (スコア:3, 興味深い)
パスワードの総当たりなど、3回試行して失敗したら30分ロックアウトするだけで、この手の物は簡単に防げるという認識は甘いでしょうか。
Re:総当たりチェックなど・・・・ (スコア:4, 興味深い)
パスワードを保管しているファイルが盗まれなければ。
たとえば、どこかの企業が物凄くセキュリティレベルが低くて、そこに侵入したらユーザー名とパスワードの一覧表を盗むことができた、としましょう。ただし、パスワードはハッシュ化されているので、そのままでは使えません。
今回の実験から、GPUを使うとこのファイルからパスワードを推測することが可能だ、ということが判ります。もし、同じユーザーが別の所でも同じユーザー名とパスワードを使っていたら、きっと侵入できるでしょう。そのテストを行うのには、1サイト1ユーザー名あたり1回のテストで済みます。
100万人のユーザー情報があって、10%が同じパスワードを違う場所でも使っているとするなら、10万人分の情報が手に入ったわけです。
fjの教祖様
Re:総当たりチェックなど・・・・ (スコア:1, おもしろおかしい)
> たとえば、どこかの企業が物凄くセキュリティレベルが低くて、そこに侵入したらユーザー名とパスワードの一覧表を盗むことができた、としましょう。ただし、パスワードはハッシュ化されているので、そのままでは使えません。
なぜだかちっともたとえ話という気がしない。
Re:総当たりチェックなど・・・・ (スコア:5, おもしろおかしい)
いや、たとえ話だろう。
だって、あそこのパスワードは平文だったんだから...
そういえば (スコア:0)
そのあそこはパスワード入力ミスっても何回でも入力できるんだよな
一定回数ミスったらあとは翌日ねみたいなのがないという…
こういうネタと一緒に見ると恐ろしい仕様だ
Re: (スコア:0)
今利用している埼玉りそなが文字数制限短くてちょっと不安なんですよねえ。
制限する意味が分からない。
DBに平文固定長で保存しているんじゃないかと疑いたくなります。
Re: (スコア:0)
Re:総当たりチェックなど・・・・ (スコア:1)
>銀行は数字4桁の暗唱番号破られたら客の責任
三回ミスると銀行にお電話というパターンがあったのだけど、
それは今はなくなったのかな?
Re: (スコア:0)
ATMで別のカードの暗証番号入力してロックされた俺をお呼びかね?
窓口出頭→キャッシュカード再発行(勿論手数料発生)となりました。
# 給与振込口座で、普段遠地にいるのでダメージ甚大でした(泣)
# キャッシュカード発行も一週間かかるといわれたので、当座の現金を印鑑で下ろしましたよ
Re:総当たりチェックなど・・・・ (スコア:1)
>窓口出頭→キャッシュカード再発行(勿論手数料発生)となりました。
銀行によってはそうなるんだ。
わたしの場合、三井住友でやっちまって、電話でオケ、次からはちゃんとしてね..で済んだけど、金融機関によっては再発行もあるんだね。
Re: (スコア:0)
昔書いたコメント [srad.jp]ですが
というわけで3回間違えたことが何度かあるの
Re: (スコア:0)
昔はカードの磁気ストライプ部に暗証番号が入ってましたからね。
窓口にライターがなければ再発行するしかなかったのでしょう。
今はカード側には記録されておらず、サーバー側での管理なので再発行は必要ないのかと。
Re: (スコア:0)
親コメのAC [srad.jp]ですが、そのコメントのリンク [bk.mufg.jp]で示したとおり、三菱東京UFJ銀行が、暗証番号3回ミスってロックした場合、「磁気カードの場合はカード再発行」「ICカードの場合は窓口で対応可能」になるのは昔話ではなく今現在の話です。
#そもそも、三菱東京UFJ銀行で、って書いてる時点でそれほどの昔話じゃないわけですが…
> 昔はカードの磁気ストライプ部に暗証番号が入ってましたからね。
1987年以前 [google.co.jp]の話をしているのだと思いますが、その時問題になったのは「カードに暗証番号が記録されていて」「ATMはカードに記録
Re: (スコア:0)
三菱(ry は今でも再発行なんですか。
再発行すると何が変わるんでしょうね。
口座番号以外に何か記録されているのだろうか…
再発行フラグか何かあるのかな。
昔は磁気データの先頭部分に暗証番号が入っていて、それが問題になって0フィルされた後も
別の位置に暗号化されて入ってたりしましたけど、それがまだ尾を引いているのかな…
Re: (スコア:0)
Re: (スコア:0)
企業にちゃんとしたセキュリティを望むのと同様に
ユーザーのこういう間抜けな行動も厳しく責めるべきではないでしょうか。
Re:総当たりチェックなど・・・・ (スコア:5, 興味深い)
1) どうやって、「ユーザーが間抜けな行動をとっているかどうか」を確認するか?
2) ただでさえ、たくさんのパスワード設定/変更が嫌で「シングル・サイン・オン」を求めているユーザーにそのようなポリシーをお願いすることが可能か?
3) 仮に押し付けることができたとすると、ユーザーは簡単にあちらこちらの都合が良いサービスを選択・組み合わせる事がしにくくなりますよね? それってITビジネスに参入障壁を設けているだけにならない??
4) 現実問題としては、ユーザー名とパスワードをどこか1箇所で盗まれた場合、自分の使っているITサービスの他のものにも問題が波及する、というリスクはユーザーが被ってるんだから、文句を言われる筋合いはない、という反論にどう対処するか? (公害問題とかと同じ種類の問題になります)
とパッと考えても4つ問題が出ますね。
fjの教祖様
Re: (スコア:0)
提供側はユーザーが間抜けな行動をすると思ってシステムを構築する。
ユーザー側も相手が間抜けな行動をすると思って自衛するべきだということです。
分かっててアカウントとパスワードを統一してるなら
ユーザーの自己責任でいいんじゃないでしょうか。
Re: (スコア:0)
Re:総当たりチェックなど・・・・ (スコア:2, 興味深い)
「弱いパスワードを使うことで破られるリスクがある」
⇒ ピコーン! ログインIDを変えさせればいいんじゃね?
ということで,わざわざ社内システムのアカウント名に
「社員ID以外のIDを使うように」という意味の分からない
お達しが来たうちはどうすれば…
Re:総当たりチェックなど・・・・ (スコア:2, おもしろおかしい)
巫女さんになってシステムを落とせとか、転職しろとかみたいな意見が出ると予想。
Re: (スコア:0)
>⇒ ピコーン! ログインIDを変えさせればいいんじゃね?
ちなみに自分は幾つかのサイトで複雑なIDを取得してます。
#たとえばこんな感じの→ zdj9EyW2clyrDq7hQK2Zq
>>> もし、同じユーザーが別の所でも同じユーザー名とパスワードを使っていたら
>>企業にちゃんとしたセキュリティを望むのと同様に
これは全く同感。
>>たくさんのパスワード設定/変更が嫌で「シングル・サイン・オン」を求めているユーザーにそのようなポリシーをお願いすることが可能か?
無理でしょう。バカに付ける薬は無いから。
暗証番号に生年月日や1234を使うことさえ強制は難しい。
Re: (スコア:0)
実害を被るのは当人ですから、特に責める必要はないんじゃないですかね。
その責を管理側に求めるのは流石にお門違いですし。
警告はしてあげるのが親切でしょうが。
Re: (スコア:0)
そのあたりのことは書かないのが粋なの?
ハッシュ化時のアルゴリズムなども含めて何がわかっている状態なら解析できるのか。
ssh通信を盗聴してGPUを使うと鍵を取り出せるのか。zipやTrueCryptはどうなのか。
Re:総当たりチェックなど・・・・ (スコア:1)
「元記事を読め」ということではないでしょうか
fjの教祖様
Re:総当たりチェックなど・・・・ (スコア:1)
Re: (スコア:0)
Re:総当たりチェックなど・・・・ (スコア:2, 参考になる)
から直接パスワードを割り出すツールの事だから。
saltはレインボーテーブル [wikipedia.org]対策。
Re:総当たりチェックなど・・・・ (スコア:1)
次画面のリトライ回数を3回くらいにしておけば総当たり攻撃も使えないでしょうし、最初のパスワードが第三者に突破されたこともメールが来ることですぐ分かりますし。
二要素認証くらいの強度はあるかと。
Re: (スコア:0)
アカウントハックが日常的に頻発してる某ネトゲですが
支払い時のアカウントとゲームアカウントが別になってるタイプで
支払いアカウントは携帯認証あるのに
消費する方のゲームアカウントには携帯認証が無いという素敵仕様
やられる奴が悪いといえばそれまでなんだけど
ここまで運営会社が無対応だともう内部犯行なんじゃないかと
大企業の機密情報なんか盗んでもそうそう捌けないけど
ネトゲのRMTならちょっと調べれば誰でもできる
ここが犯罪の主戦場なんだからどこか公的機関でなんとかしてくれないもんですかね…
Re:総当たりチェックなど・・・・ (スコア:1)
>> 大企業の機密情報なんか盗んでもそうそう捌けないけど
>> ネトゲのRMTならちょっと調べれば誰でもできる
>> ここが犯罪の主戦場なんだからどこか公的機関でなんとかしてくれないもんですかね…
社団法人リアルマネートレーディング対策協議会(仮)、とかいう団体を作って
警察やら経済産業省やらの天下りを受け入れてあげれば一発じゃないかと。
♯ついでに、RMTを取り締まる法的根拠も必要ですけどね。
Re:総当たりチェックなど・・・・ (スコア:1)
為替とか株とか先物とかFXとか何かその手の商売を規制しようというんですね、分かります。
Re: (スコア:0)
マビノギですね、わかりますorz
上記が正解の前提で書きますが、ワンタイムパスワードを利用するためのアプリがガラケーのみ対応という
さらなる素敵仕様で泣きが入ってます。
早くスマホ対応してくれないと困ります……。
Re:総当たりチェックなど・・・・ (スコア:1)
さすがに3回でロックアウトするだけでは・・・・
パスワードを固定して、IDの方をぶん回すという方法もあるわけですから。
Re:総当たりチェックなど・・・・ (スコア:1)
会員数でロックアウトするのと同じだから、会員数が相当多くないと有効でない。
the.ACount
Re: (スコア:0)
同意。
復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、ネットワーク越しの話なら、律速になるのはクラッカー側の演算能力ではないと思います。 ロックアウトでもいいし、1秒に1回しかログインできないとかにしてしまえばCPUでもGPUでも一緒です
Re:総当たりチェックなど・・・・ (スコア:3, 興味深い)
>>復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、
>>ネットワーク越しの話なら、律速になるのはクラッカー側の演算能力ではないと思います。
そんなことはない。通信をキャプチャされれば
暗号化された通信が復号される可能性はある。
ログインされることだけが損害ではない。
Re: (スコア:0)
SSLの暗号に使われている鍵は人間様が覚えておける長さという制約のあるパスワードよりずっと長いから、破るのもはるかに困難。今のところGPUを使う程度のことではとても現実的な時間では解けない。
まあ
>>復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、
これも対策はすでに考えられてて、ストレッチングと呼ばれているけど。
Re: (スコア:0)
1024bit RSA が危ないとか言われるようになったのは、
現実的な時間では解けないとされていたのがそうでもなくなったからなんだけどね。
Re: (スコア:0)
SSLで鍵が長い公開鍵暗号方式が使われるのは、鍵が短い共通鍵暗号方式の鍵の授受だよ。
通信内容を傍受するなら、共通鍵暗号方式で暗号化されたデータストリームに対する総当たりで済む。
Re: (スコア:0)
それに現在収集されてるパケットは10年以内には解読されるだろうしね。
Re: (スコア:0)
Re: (スコア:0)
>通信内容を傍受するなら、共通鍵暗号方式で暗号化されたデータストリームに対する総当たりで済む。
その共通鍵は使い捨てだから、セッションが有効なうちに解読に成功しなきゃいけない。
よほど共通鍵の暗号強度が低くないかぎり、有効期限10年があたりまえなルート証明書の解析を頑張った方がマシだね。
Re: (スコア:0)
データストリームを記録しておき、あとでゆっくり解読すりゃいいじゃん。
Re: (スコア:0)
Re:総当たりチェックなど・・・・ (スコア:1)
それってディクショナリ式じゃないの?
総当たりって文字通り総当たりだと思うんだけど。
Re: (スコア:0)
あ~あ、言っちゃった。
Re: (スコア:0)
3回試行でロックしておけば、問題ないでしょう。何兆回やろうがロック状態ですからね。
(その前に偽計業務妨害とかで警察に通報されるな・・・。海外なら国境関係なしに
捜索してしまうFBIの出番か。国内に来るよう”誘惑”して即逮捕とかよくやるし)