アカウント名:
パスワード:
パスワードを保管しているファイルが盗まれなければ。
たとえば、どこかの企業が物凄くセキュリティレベルが低くて、そこに侵入したらユーザー名とパスワードの一覧表を盗むことができた、としましょう。ただし、パスワードはハッシュ化されているので、そのままでは使えません。
今回の実験から、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を変えさせればいいんじゃね?ちなみに自分は幾つかのサイトで複雑なＩＤを取得してます。＃たとえばこんな感じの→ zdj9EyW2clyrDq7hQK2Zq
＞＞> もし、同じユーザーが別の所でも同じユーザー名とパスワードを使っていたら＞＞企業にちゃんとしたセキュリティを望むのと同様にこれは全く同感。
＞＞たくさんのパスワード設定/変更が嫌で「シングル・サイン・オン」を求めているユーザーにそのようなポリシーをお願いすることが可能か?
無理でしょう。バカに付ける薬は無いから。暗証番号に生年月日や１２３４を使うことさえ強制は難しい。
実害を被るのは当人ですから、特に責める必要はないんじゃないですかね。その責を管理側に求めるのは流石にお門違いですし。
警告はしてあげるのが親切でしょうが。
「元記事を読め」ということではないでしょうか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
総当たりチェックなど・・・・ (スコア: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を変えさせればいいんじゃね?
ちなみに自分は幾つかのサイトで複雑なＩＤを取得してます。
＃たとえばこんな感じの→ zdj9EyW2clyrDq7hQK2Zq
＞＞> もし、同じユーザーが別の所でも同じユーザー名とパスワードを使っていたら
＞＞企業にちゃんとしたセキュリティを望むのと同様に
これは全く同感。
＞＞たくさんのパスワード設定/変更が嫌で「シングル・サイン・オン」を求めているユーザーにそのようなポリシーをお願いすることが可能か?
無理でしょう。バカに付ける薬は無いから。
暗証番号に生年月日や１２３４を使うことさえ強制は難しい。
Re: (スコア:0)
実害を被るのは当人ですから、特に責める必要はないんじゃないですかね。
その責を管理側に求めるのは流石にお門違いですし。
警告はしてあげるのが親切でしょうが。
Re: (スコア:0)
そのあたりのことは書かないのが粋なの？
ハッシュ化時のアルゴリズムなども含めて何がわかっている状態なら解析できるのか。
ssh通信を盗聴してGPUを使うと鍵を取り出せるのか。zipやTrueCryptはどうなのか。
Re:総当たりチェックなど・・・・ (スコア:1)
「元記事を読め」ということではないでしょうか
fjの教祖様
Re:総当たりチェックなど・・・・ (スコア:1)
Re: (スコア:0)
Re:総当たりチェックなど・・・・ (スコア:2, 参考になる)
から直接パスワードを割り出すツールの事だから。
saltはレインボーテーブル [wikipedia.org]対策。