アカウント名:
パスワード:
二段階認証でもなきゃ簡単にログインされてしまう。二段階認証でも突破する方法が有るみたいですし。ログイン機能を開発するコストが跳ね上がりますな。
SSLにすら対応していない、ここ/.Jの立場は…。
いらない対応だからね。
SSLがいる理由を無理やり考えろといわれたらいくらでも出せるけど、よくよく検討すれば穴があったりSSLとか関係なかったりする。
うん、君がセキュリティのド素人だというのがよくわかったよ。
では、/.Jがコストをかけてまで新しいログイン機能を開発する理由を挙げてみてくれ。当然、無理やりなものなど穴の有る理由はダメだよ。
別人だけど、
* 成りすましによる議論の混乱を避ける* メールアドレスなど、公開していない個人情報の流出を防ぐ
いくらでもあるだろう。私はIDの時はメールアドレスを公開しているので、どうでもいいが、一般的にみて、これはわりと脆弱なシステムだ。上の主張は、ちょっと何を言っているのか良くわからないな。
コストをかけてまで新しいログイン機能を開発する理由について
> 成りすましによる議論の混乱を避ける> メールアドレスなど、公開していない個人情報の流出を防ぐ
それって理由になっている?私はなっていないと判断します。
あなたの挙げた理由はID/PWの漏洩があった場合の話です、SSLの話はあまり関係ないでしょう。今回のmixiの件もアカウント数に対する攻撃件数から見て他の理由と見るのが正しいと判断します。アカウントの使い回しとかの。つまり、SSLが有ろうが無かろうが発生する事象です。SSLを使えば有意に差が出るというデータでもあれば話は別です。
> いくらでもあるだろう
> あと攻撃者側の立場も忘れずに考えてください。SSLの有無が有効なのは盗聴など回線の途中に対する攻撃です。/.Jってそこまでして攻撃する対象ですか?
セキュリティは一番低レベルのところから崩れていきます。スラドへの通信でパケットを盗聴が発生した場合,そこそこのアカウントとパスワード,メールアドレスを入手。それを使って金銭が絡む複数サービスへアタック,ひとり(ひとつ)でも成功したら儲けもん。
外部サービス提供サーバはセキュリティ高いけど,会社や教育機関内部、あるいは市中でのサービスでのパケットログ等の管理は・・・
> セキュリティは一番低レベルのところから崩れていきます。
だから、それはSSLの話とは違う問題でしょう。それはID/PWの使い回しとかメールアドレスの管理不徹底のほうで発生する問題。
私が最初にいった「SSLがいる理由を無理やり考えろといわれたらいくらでも出せるけど」ですよ。
> ひとり(ひとつ)でも成功したら儲けもん。
だからそれは被害者側の問題でしょ。何度言っても理解できないようだけどサービス側が新しい機能を追加するコストなので、ユーザー側の問題なんて関係ないのですよ。当然ユーザー側の被害が直接経営危機につながる銀行などは問題ですよ。
でも/.Jにはそんな条件関係ない。
たとえ、/.Jとの通信パケットでID/PW MailAdressがもれてそれで銀行のお金を取られても、それはその個人と、銀行のセキュリティレベルが低いとの問題で/.J は(ポーズとして)謝罪する程度。
SSLは数多ある手段の一つ。自分のサービスレベルに合わせてチョイスするもの。妄信的に何でも必要という考えはコスト的な破綻を招くだけ。
> 外部サービス提供サーバはセキュリティ高いけど
だからさあ、漏洩は、特にサービス提供側の被害になる漏洩はどこで起きているか考えた?SSLの先、つま復号化された後の場所だよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
ログイン機能の開発コスト (スコア:2)
二段階認証でもなきゃ簡単にログインされてしまう。
二段階認証でも突破する方法が有るみたいですし。
ログイン機能を開発するコストが跳ね上がりますな。
Re: (スコア:-1)
SSLにすら対応していない、ここ/.Jの立場は…。
Re: (スコア:3)
いらない対応だからね。
SSLがいる理由を無理やり考えろといわれたらいくらでも出せるけど、よくよく検討すれば穴があったりSSLとか関係なかったりする。
Re: (スコア:-1)
うん、君がセキュリティのド素人だというのがよくわかったよ。
Re: (スコア:2)
では、/.Jがコストをかけてまで新しいログイン機能を開発する理由を挙げてみてくれ。
当然、無理やりなものなど穴の有る理由はダメだよ。
Re: (スコア:0)
別人だけど、
* 成りすましによる議論の混乱を避ける
* メールアドレスなど、公開していない個人情報の流出を防ぐ
いくらでもあるだろう。私はIDの時はメールアドレスを公開しているので、どうでもいいが、一般的にみて、これはわりと脆弱なシステムだ。上の主張は、ちょっと何を言っているのか良くわからないな。
Re: (スコア:4, 参考になる)
コストをかけてまで新しいログイン機能を開発する理由について
> 成りすましによる議論の混乱を避ける
> メールアドレスなど、公開していない個人情報の流出を防ぐ
それって理由になっている?
私はなっていないと判断します。
あなたの挙げた理由はID/PWの漏洩があった場合の話です、SSLの話はあまり関係ないでしょう。
今回のmixiの件もアカウント数に対する攻撃件数から見て他の理由と見るのが正しいと判断します。アカウントの使い回しとかの。
つまり、SSLが有ろうが無かろうが発生する事象です。SSLを使えば有意に差が出るというデータでもあれば話は別です。
> いくらでもあるだろう
Re: (スコア:0)
> あと攻撃者側の立場も忘れずに考えてください。SSLの有無が有効なのは盗聴など回線の途中に対する攻撃です。/.Jってそこまでして攻撃する対象ですか?
セキュリティは一番低レベルのところから崩れていきます。
スラドへの通信でパケットを盗聴が発生した場合,そこそこのアカウントとパスワード,メールアドレスを入手。
それを使って金銭が絡む複数サービスへアタック,ひとり(ひとつ)でも成功したら儲けもん。
外部サービス提供サーバはセキュリティ高いけど,会社や教育機関内部、あるいは市中でのサービスでのパケットログ等の管理は・・・
Re:ログイン機能の開発コスト (スコア:1)
> セキュリティは一番低レベルのところから崩れていきます。
だから、それはSSLの話とは違う問題でしょう。
それはID/PWの使い回しとかメールアドレスの管理不徹底のほうで発生する問題。
私が最初にいった「SSLがいる理由を無理やり考えろといわれたらいくらでも出せるけど」ですよ。
> ひとり(ひとつ)でも成功したら儲けもん。
だからそれは被害者側の問題でしょ。
何度言っても理解できないようだけどサービス側が新しい機能を追加するコストなので、ユーザー側の問題なんて関係ないのですよ。
当然ユーザー側の被害が直接経営危機につながる銀行などは問題ですよ。
でも/.Jにはそんな条件関係ない。
たとえ、/.Jとの通信パケットでID/PW MailAdressがもれてそれで銀行のお金を取られても、
それはその個人と、銀行のセキュリティレベルが低いとの問題で/.J は(ポーズとして)謝罪する程度。
SSLは数多ある手段の一つ。自分のサービスレベルに合わせてチョイスするもの。
妄信的に何でも必要という考えはコスト的な破綻を招くだけ。
> 外部サービス提供サーバはセキュリティ高いけど
だからさあ、漏洩は、特にサービス提供側の被害になる漏洩はどこで起きているか考えた?
SSLの先、つま復号化された後の場所だよ。