アカウント名:
パスワード:
当社サーバーへの不正なアクセスについてhttp://pr.yahoo.co.jp/release/2013/0404a.html [yahoo.co.jp]「当社サーバへの不正なアクセスについて」（5/17発表）の追加発表http://pr.yahoo.co.jp/release/2013/0523a.html [yahoo.co.jp]
1500万回トライしているし、任天堂が言うようにどこかで取得した情報を元にやっている可能性が高いですねあと同一のID、パスワード、メールアドレスで複数のサービスを利用している人はとても多いので、芋づる式にこういった不正ログインが多発しないよう利用者の意識を完全しないといけないですね
利用者もそうですけど、漏洩元システムにも非があると思います。漏洩元システムが判明したら、任天堂法務部には、今回対応費用を請求してほしいところ。
パスワードの平文保存を要求してくる客の説得材料にしたいという個人的理由で。
Facebookの大規模漏洩後に各所で大規模に不正侵入を試みてる話が続出してるからここ一連のやつの発端はFacebookのような気がする。
かくいう私も数種類のパスを使いまわしてたのでヤバイ状況に……メールアドレスも複数使ってたので完全に組み合わせはそう多くは無かったけど。
さすがにあのfacebookが生パスワードを保存してるとは思えないが？今世界で一番情報セキュリティを注目・監視されてる会社だよ。
むしろ生パスワードを持つのが最近の動向です。
ゼロ知識証明を使った認証プロトコル(CHAPとかダイジェスト認証とかね)の定義などをご覧になると分かりますが、 パスワード自体を転送しない認証方式は対向側に生パスワードを持っていないと実現できないのですよ。
ダイジェスト認証については、サーバ側はユーザ名・レルム・パスワードを連結した文字列のハッシュ値を持てばよさそうです。以下、 RFC 2617 [ietf.org] より引用します。
ダイジェスト認証において認証エージェント（通常はサーバ）は、レルムごとにユーザ名とパスワードから生成したデータを「パスワードファイル」に格納する必要があります。通常、このデータはユーザ名と H(A1) のペアからなります。 H(A1) は上述したとおり、ユーザ名、レルム、パスワードから生成したダイジェスト値です。※ 引用者註: H(A1) = MD5(ユーザ名 ":" レルム ":" パスワード)
ダイジェスト認証において認証エージェント（通常はサーバ）は、レルムごとにユーザ名とパスワードから生成したデータを「パスワードファイル」に格納する必要があります。通常、このデータはユーザ名と H(A1) のペアからなります。 H(A1) は上述したとおり、ユーザ名、レルム、パスワードから生成したダイジェスト値です。
※ 引用者註: H(A1) = MD5(ユーザ名 ":" レルム ":" パスワード)
なんで都合のいいところしか引用しないの? そのすぐ後に「もしパスワードファイルが漏洩したら、即座にそのレルムへのアクセス権を得られちゃうよ」って書かれてるじゃん。生パスワードそのものは確かに漏洩しないかもしれないが、ほとんど同じこと。せいぜいパスワードを使いまわされているかもしれない他サイトに迷惑をかけない、くらいの意味しかない。
なんで都合のいいところしか引用しないの?
「生パスワードを持つ」に脊髄反射して、直接関係ある所だけ読んだからです。確かに、ダイジェスト認証に使うのはユーザ名とダイジェスト値だけで、これをサーバとクライアントが共有しているので、バレたらそのサービスはおしまいですね。
せいぜいパスワードを使いまわされているかもしれない他サイトに迷惑をかけない、くらいの意味しかない。
RFC の方にも書かれていますが、ユーザ名、レルム、ダイジェスト値が既知となった時点で、オフラインでブルートフォースアタックが掛けられるので、結局パスワードが解析されて、他サイトにも迷惑を掛ける可能性が高いと思います。ハッシュ関数が MD5 よりもっと計算量が大きいものならマシだったんでしょうが。
結論、パスワードをハッシュ化して保存していたとしても、ハッシュ化された値が流出した時点で、
ってことで、大して事態は良くなりませんね。
パスワード自体もオフライン攻撃で破られる可能性が高い（特にハッシュ関数の計算量が小さい場合）
でも、オフラインブルートフォースで破られるまでの時間は、ユーザ側としては大きいですよ。
もし、本当に平文のまま流出した場合、流出の事実が分かったころには、既にそのアカウント情報で他のサービスに対してログイン試行が行われ、もし、パスワードの使い回しをしていたら、気がついた時にはあちこちで自分のアカウントが不正に使われている、という事態が考えられます。
しかし、オフライン・ブルートフォースでが必要で、生のパスワードが分かるまでの時間が稼げれば、その間にパスワードを変更することで、他サービスへの被害を回避できることになります。
自分が知っ
えっ、そうなの？ SSL/TLS 化したトンネルの中に、平文のパスワード、サーバ側はソルト付けた上でストレッチング、ではなくて。
まぁ、SSL/TLS 化できない場合に、盗聴とサーバからの漏洩のリスクを天秤にかけて、とか、SSL/TLS 化によるコスト増（証明書の金額だけじゃなくて、期限切れしないようにするための間接的なコストや、サーバサイドでの暗号化処理に伴うコストとか）との兼ね合い、という事はあると思うけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
ヤフージャパンの漏えいを思い出した (スコア:0)
当社サーバーへの不正なアクセスについて
http://pr.yahoo.co.jp/release/2013/0404a.html [yahoo.co.jp]
「当社サーバへの不正なアクセスについて」（5/17発表）の追加発表
http://pr.yahoo.co.jp/release/2013/0523a.html [yahoo.co.jp]
1500万回トライしているし、任天堂が言うようにどこかで取得した情報を元にやっている可能性が高いですね
あと同一のID、パスワード、メールアドレスで複数のサービスを利用している人はとても多いので、芋づる式にこういった不正ログインが多発しないよう利用者の意識を完全しないといけないですね
Re: (スコア:3)
利用者もそうですけど、漏洩元システムにも非があると思います。
漏洩元システムが判明したら、任天堂法務部には、
今回対応費用を請求してほしいところ。
パスワードの平文保存を要求してくる客の説得材料にしたいという個人的理由で。
Re:ヤフージャパンの漏えいを思い出した (スコア:0)
Facebookの大規模漏洩後に
各所で大規模に不正侵入を試みてる話が続出してるから
ここ一連のやつの発端はFacebookのような気がする。
かくいう私も数種類のパスを使いまわしてたのでヤバイ状況に……
メールアドレスも複数使ってたので完全に組み合わせはそう多くは無かったけど。
Re: (スコア:0)
さすがにあのfacebookが生パスワードを保存してるとは思えないが？
今世界で一番情報セキュリティを注目・監視されてる会社だよ。
Re:ヤフージャパンの漏えいを思い出した (スコア:2)
むしろ生パスワードを持つのが最近の動向です。
ゼロ知識証明を使った認証プロトコル(CHAPとかダイジェスト認証とかね)の定義などをご覧になると分かりますが、 パスワード自体を転送しない認証方式は対向側に生パスワードを持っていないと実現できないのですよ。
Re:ヤフージャパンの漏えいを思い出した (スコア:1)
ダイジェスト認証については、サーバ側はユーザ名・レルム・パスワードを連結した文字列のハッシュ値を持てばよさそうです。以下、 RFC 2617 [ietf.org] より引用します。
Re: (スコア:0)
なんで都合のいいところしか引用しないの? そのすぐ後に「もしパスワードファイルが漏洩したら、即座にそのレルムへのアクセス権を得られちゃうよ」って書かれてるじゃん。生パスワードそのものは確かに漏洩しないかもしれないが、ほとんど同じこと。せいぜいパスワードを使いまわされているかもしれない他サイトに迷惑をかけない、くらいの意味しかない。
Re:ヤフージャパンの漏えいを思い出した (スコア:1)
「生パスワードを持つ」に脊髄反射して、直接関係ある所だけ読んだからです。確かに、ダイジェスト認証に使うのはユーザ名とダイジェスト値だけで、これをサーバとクライアントが共有しているので、バレたらそのサービスはおしまいですね。
RFC の方にも書かれていますが、ユーザ名、レルム、ダイジェスト値が既知となった時点で、オフラインでブルートフォースアタックが掛けられるので、結局パスワードが解析されて、他サイトにも迷惑を掛ける可能性が高いと思います。ハッシュ関数が MD5 よりもっと計算量が大きいものならマシだったんでしょうが。
結論、パスワードをハッシュ化して保存していたとしても、ハッシュ化された値が流出した時点で、
ってことで、大して事態は良くなりませんね。
Re: (スコア:0)
パスワード自体もオフライン攻撃で破られる可能性が高い（特にハッシュ関数の計算量が小さい場合）
でも、オフラインブルートフォースで破られるまでの時間は、ユーザ側としては大きいですよ。
もし、本当に平文のまま流出した場合、流出の事実が分かったころには、既にそのアカウント情報で他のサービスに対してログイン試行が行われ、もし、パスワードの使い回しをしていたら、気がついた時にはあちこちで自分のアカウントが不正に使われている、という事態が考えられます。
しかし、オフライン・ブルートフォースでが必要で、生のパスワードが分かるまでの時間が稼げれば、その間にパスワードを変更することで、他サービスへの被害を回避できることになります。
自分が知っ
Re: (スコア:0)
むしろ生パスワードを持つのが最近の動向です。
えっ、そうなの？ SSL/TLS 化したトンネルの中に、平文のパスワード、サーバ側はソルト付けた上でストレッチング、ではなくて。
まぁ、SSL/TLS 化できない場合に、盗聴とサーバからの漏洩のリスクを天秤にかけて、とか、SSL/TLS 化によるコスト増（証明書の金額だけじゃなくて、期限切れしないようにするための間接的なコストや、サーバサイドでの暗号化処理に伴うコストとか）との兼ね合い、という事はあると思うけど。