アカウント名:
パスワード:
以前、ランダムなID(変更不可)を割り当てれば解決 [srad.jp] でも書きましたが、リスト型の攻撃はサービス提供者がランダムで変更不可なユーザーIDを割り当てて認証に用いれば完全に防ぐことができるのです。
ちなみに、Yahoo! Japan ID のような公開IDを認証に使うのも望ましくありません。そのため、Yahoo! Japan は 認証用のIDを Yahoo! Japan ID とは別にするサービス [yahoo.co.jp]を提供しています。
昔は、サービス提供者がユーザーIDを割り当てる方式が主流でしたが、最近になってメールアドレスをIDとするWebサービスが増えてきたのが、リスト型の攻撃が増えた本当の原因です。
サービス提供者が割り当てたランダムで変更不可なユーザーIDは、利用者にとって暗記しにくいという問題点もありますが、利用登録時にメールや郵送などで受け渡して、紛失しないように手帳・ノートなどに書き留めれることを要求すれば良いだけです。ID はブラウザに Cookie で記録するような設計にすれば、毎回入力するというユーザーの手間も省けます。ID がしっかりといった強度を保っていれば、ユーザーがパスワードを使いまわしたとしても、問題は生じません。
専門家の高木浩光さんも、次のように述べています [twitter.com]。
おいおい、いつからパスワードを使い回さないのが利用者の責任になったんだ? 利用者にはパスワードを使い回す自由があると昔から言っているだろうが。
> サービス提供者が割り当てたランダムで変更不可なユーザーIDは、利用者にとって暗記しにくいという問題点もありますが、利用登録時にメールや郵送などで受け渡して、紛失しないように手帳・ノートなどに書き留めれることを要求すれば良いだけです。
それってもしかしたらランダムに生成したパスワードをメモに書いておくのと似たようなもん?ランダムじゃないけど割り当てられたユーザ名でloginするのはパソ通では普通だったっけ。
>ID はブラウザに Cookie で記録するような設計にすれば、毎回入力するというユーザーの手間も省けます。I
そうしておくと、ユーザ/パスワードを盗む手間も割と省けるんじゃなかったっけ。#javascriptを使ってCookieを盗み取るデモとかどこかで見た気がする。
それってもしかしたらランダムに生成したパスワードをメモに書いておくのと似たようなもん?
そんなもんですね。ただ、IDはIDであってパスワードではない、と言う点には留意したいものです。パスワードはパスワードでランダム生成してメモなりなんなりに保存しましょう。
#javascriptを使ってCookieを盗み取るデモとかどこかで見た気がする。
そういう穴もあるかもしれません。でも、それはそれとして穴を塞ぐことを考えましょう。IDとパスワードをどのようにしたところで、穴が開けばどうしようもないのはどうしようもない事ですから。
>#javascriptを使ってCookieを盗み取るデモとかどこかで見た気がする。クロスサイトスクリプティング関係のデモだった気がします。
ブラウザーに記録するのはまずいかとトラブルシューティングでクッキーなどの情報を消す必要があるので
ブラウザーに記録するのはまずいかと トラブルシューティングでクッキーなどの情報を消す必要があるので
そういったケースのために、「利用登録時にメールや郵送などで受け渡して、紛失しないように手帳・ノートなどに書き留めれることを要求」しておきます。
最近は、Gmail のような大容量・SPAMフィルター付きのWebメールが主流なので、多くのユーザーは、IDなどの重要な情報が書かれたメールを削除したり、メールアドレスを頻繁に変更したりしません。従って、書き留めたユーザーIDを紛失したとしても、受信メールから検索をかければ見つかるケースが多いと思います。
たまにランダムな英数字でIDを出すサービスがありますけど、間違いなく、そのサービスのIDは覚えません。
パスワードもそうですが、IDやパスワードを忘れた時に使われる手段が、「秘密の質問」や「登録メールアドレスへのリマインダ送信」です。
秘密の質問が、ソーシャルハックによってパスワードよりも脆弱であることはAppleのiCloudがやられた件ではっきりしました。登録メールアドレスにWebmailのようなものを使っている場合、そのWebmailが破られると複数のサービスへのアクセスがごっそり取られるという問題もあります。
「パスワードを使いまわすな」ということも、それが原
秘密の質問といいつつ、質問がリストから選ぶ形式なので、事実上の共通パスワードになってます。どのサイトでも「母親の旧姓」「出身の小学校」「初めて飼ったペット」とかですもん。これじゃあ「公開の質問」だと思う次第。しかも本人のこと知ってれば答えがわかってしまう。質問から入力させてくれよ、って思うのです。
#「好きな電車」とかいう質問はもっとあっていいと思うの
> 「hogehoge_a」「hogehoge_b」というように、簡単なものにされるでしょう。
リスト型攻撃への対策であれば、それでも十分だとは思いますけどね。願わくば、hogehogeの部分を十分に複雑にしてくれればというぐらいで。
十分ではないけど、マシな程度ですね。hogehogeが複雑でも簡単でも関係なく、むしろ_aと_bの部分が複雑じゃないとダメです。
パスワードリストの中に、hogehoge_ahogehoge_bなんてあったら、漏れていない他のパスワードを予想するのも簡単で、かえって危ない。
となると、結局、「共通パスワード」+「複雑なパスワード」にするしかなく、そうすると「複雑なパスワード」なだけでもいいじゃないかという。
呼びかけがあっても、使いまわしの自由はあるし使い回さない責任もないが、リスト型攻撃からの自衛として有効な手段であるというのもまた事実。
おいおい、いつから ID を使い回さないのが利用者の責任になったんだ?利用者には ID を使い回す自由があると昔から言っているだろうが。
以前のコメントでも指摘されてるけどこれな
おまえの言っているIDな、それみんながパスワードと呼んでるやつだから [srad.jp]
「ID」だというのなら、利用者がそれを紙に書いてデスクトップに貼ったり、他のユーザーに伝えることも許容しろよ?「ID」なんだから当然問題ないよな?
問題ないよただしパスワードは他人には絶対教えてはいけないので、そんなことする意味がありません
idをランダムに振るようなことができるのは登録に個人を識別しうる情報を要求して、id紛失をリカバリできるサイトだけだな。銀行とかクレジットなんかはすでにそういう方向性になっている。
そういう情報を預かっていない、預けたくないサイトは多くの場合idとは別にニックネームとかペルソナとかいう公開名を登録することになってるよね。
ランダムなidなんて面倒なだけだ。
> 昔は、サービス提供者がユーザーIDを割り当てる方式が主流でしたが、> 最近になってメールアドレスをIDとするWebサービスが増えてきたのが、> リスト型の攻撃が増えた本当の原因です。
これはどうかな?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
ID を使いまわさないよう事業者に呼びかけるべき (スコア:5, 参考になる)
以前、ランダムなID(変更不可)を割り当てれば解決 [srad.jp] でも書きましたが、リスト型の攻撃はサービス提供者がランダムで変更不可なユーザーIDを割り当てて認証に用いれば完全に防ぐことができるのです。
ちなみに、Yahoo! Japan ID のような公開IDを認証に使うのも望ましくありません。そのため、Yahoo! Japan は 認証用のIDを Yahoo! Japan ID とは別にするサービス [yahoo.co.jp]を提供しています。
昔は、サービス提供者がユーザーIDを割り当てる方式が主流でしたが、最近になってメールアドレスをIDとするWebサービスが増えてきたのが、リスト型の攻撃が増えた本当の原因です。
サービス提供者が割り当てたランダムで変更不可なユーザーIDは、利用者にとって暗記しにくいという問題点もありますが、利用登録時にメールや郵送などで受け渡して、紛失しないように手帳・ノートなどに書き留めれることを要求すれば良いだけです。ID はブラウザに Cookie で記録するような設計にすれば、毎回入力するというユーザーの手間も省けます。ID がしっかりといった強度を保っていれば、ユーザーがパスワードを使いまわしたとしても、問題は生じません。
専門家の高木浩光さんも、次のように述べています [twitter.com]。
Re:ID を使いまわさないよう事業者に呼びかけるべき (スコア:1)
> サービス提供者が割り当てたランダムで変更不可なユーザーIDは、利用者にとって暗記しにくいという問題点もありますが、利用登録時にメールや郵送などで受け渡して、紛失しないように手帳・ノートなどに書き留めれることを要求すれば良いだけです。
それってもしかしたらランダムに生成したパスワードをメモに書いておくのと似たようなもん?
ランダムじゃないけど割り当てられたユーザ名でloginするのはパソ通では普通だったっけ。
>ID はブラウザに Cookie で記録するような設計にすれば、毎回入力するというユーザーの手間も省けます。I
そうしておくと、ユーザ/パスワードを盗む手間も割と省けるんじゃなかったっけ。
#javascriptを使ってCookieを盗み取るデモとかどこかで見た気がする。
Re: (スコア:0)
それってもしかしたらランダムに生成したパスワードをメモに書いておくのと似たようなもん?
そんなもんですね。ただ、IDはIDであってパスワードではない、と言う点には留意したいものです。パスワードはパスワードでランダム生成してメモなりなんなりに保存しましょう。
#javascriptを使ってCookieを盗み取るデモとかどこかで見た気がする。
そういう穴もあるかもしれません。でも、それはそれとして穴を塞ぐことを考えましょう。IDとパスワードをどのようにしたところで、穴が開けばどうしようもないのはどうしようもない事ですから。
Re: (スコア:0)
>#javascriptを使ってCookieを盗み取るデモとかどこかで見た気がする。
クロスサイトスクリプティング関係のデモだった気がします。
Re: (スコア:0)
ブラウザーに記録するのはまずいかと
トラブルシューティングでクッキーなどの情報を消す必要があるので
Re:ID を使いまわさないよう事業者に呼びかけるべき (スコア:2)
そういったケースのために、「利用登録時にメールや郵送などで受け渡して、紛失しないように手帳・ノートなどに書き留めれることを要求」しておきます。
最近は、Gmail のような大容量・SPAMフィルター付きのWebメールが主流なので、多くのユーザーは、IDなどの重要な情報が書かれたメールを削除したり、メールアドレスを頻繁に変更したりしません。従って、書き留めたユーザーIDを紛失したとしても、受信メールから検索をかければ見つかるケースが多いと思います。
Re: (スコア:0)
たまにランダムな英数字でIDを出すサービスがありますけど、間違いなく、そのサービスのIDは覚えません。
パスワードもそうですが、IDやパスワードを忘れた時に使われる手段が、「秘密の質問」や「登録メールアドレスへのリマインダ送信」です。
秘密の質問が、ソーシャルハックによってパスワードよりも脆弱であることはAppleのiCloudがやられた件ではっきりしました。
登録メールアドレスにWebmailのようなものを使っている場合、そのWebmailが破られると複数のサービスへのアクセスがごっそり取られるという問題もあります。
「パスワードを使いまわすな」ということも、それが原
Re:ID を使いまわさないよう事業者に呼びかけるべき (スコア:1)
秘密の質問といいつつ、質問がリストから選ぶ形式なので、事実上の共通パスワードになってます。
どのサイトでも「母親の旧姓」「出身の小学校」「初めて飼ったペット」とかですもん。
これじゃあ「公開の質問」だと思う次第。しかも本人のこと知ってれば答えがわかってしまう。
質問から入力させてくれよ、って思うのです。
#「好きな電車」とかいう質問はもっとあっていいと思うの
Re: (スコア:0)
> 「hogehoge_a」「hogehoge_b」というように、簡単なものにされるでしょう。
リスト型攻撃への対策であれば、それでも十分だとは思いますけどね。
願わくば、hogehogeの部分を十分に複雑にしてくれればというぐらいで。
Re: (スコア:0)
十分ではないけど、マシな程度ですね。
hogehogeが複雑でも簡単でも関係なく、むしろ_aと_bの部分が複雑じゃないとダメです。
パスワードリストの中に、
hogehoge_a
hogehoge_b
なんてあったら、漏れていない他のパスワードを予想するのも簡単で、かえって危ない。
となると、結局、「共通パスワード」+「複雑なパスワード」にするしかなく、そうすると「複雑なパスワード」なだけでもいいじゃないかという。
Re: (スコア:0)
呼びかけがあっても、使いまわしの自由はあるし使い回さない責任もないが、
リスト型攻撃からの自衛として有効な手段であるというのもまた事実。
Re: (スコア:0)
おいおい、いつから ID を使い回さないのが利用者の責任になったんだ?利用者には ID を使い回す自由があると昔から言っているだろうが。
Re: (スコア:0)
以前のコメントでも指摘されてるけどこれな
「ID」だというのなら、利用者がそれを紙に書いてデスクトップに貼ったり、他のユーザーに伝えることも許容しろよ?「ID」なんだから当然問題ないよな?
Re: (スコア:0)
単純な個人狙いのパスハックの強度を著しく下げる/ユーザーへの負担を増やす(複雑なIDと複雑なパス)のどっちかしかない道なんだよなー。
Re: (スコア:0)
問題ないよ
ただしパスワードは他人には絶対教えてはいけないので、そんなことする意味がありません
Re: (スコア:0)
Re: (スコア:0)
idをランダムに振るようなことができるのは登録に個人を識別しうる情報を要求して、id紛失をリカバリできるサイトだけだな。
銀行とかクレジットなんかはすでにそういう方向性になっている。
そういう情報を預かっていない、預けたくないサイトは多くの場合idとは別にニックネームとかペルソナとかいう公開名を登録する
ことになってるよね。
ランダムなidなんて面倒なだけだ。
Re: (スコア:0)
> 昔は、サービス提供者がユーザーIDを割り当てる方式が主流でしたが、
> 最近になってメールアドレスをIDとするWebサービスが増えてきたのが、
> リスト型の攻撃が増えた本当の原因です。
これはどうかな?
Re: (スコア:0)
IDを教えても構わないのにパス4桁で使いまわしてもいいって…単純な個人狙いのパスハックに対する強度を著しく落としているのに。
完全にサービス提供側のことしか見てないな。
当人にとっては身近な悪意を持った誰かにパスを抜かれる方が、見知らぬ誰かに抜かれるよりよっぽど痛いのに。