アカウント名:
パスワード:
どうせ遅かれ早かれこんなことになるだろうと、クロネコメンバーズが便利そうなのは知っていたがあえて利用せずに不在の確認やなんかだけをWebで行い、再配達の予約や集荷の受付なんかは電話でしていた。今騒ぎになっていないだけで、西濃やペリカン、佐川なんかも似たりよったりだろう。
どうして再配達の予約如きのことで、わけのわからんサービスへの加入を強要するのか？どうして日本郵便のように、わけわからんサービスへの加入無くしてもその程度の受付はできるように何故作れない？存在しない情報が盗まれることは絶対にないと、そろそろ理解するべき。
その程度のことも理解できないまま、無駄に情報を集めまくってるクソ企業が日本には多すぎる。管理できないなら、初めから集めるな。
クロネコメンバーズはポイントサービスや流通に乗った時点でのお届け前お知らせなどがメインで割と適切な量の個人情報収集だけどねぇ。他に書かれてる通り再配達そのものは登録いらないし。
*最近パスワードリスト攻撃が多く見られますが、原因そのものはパスワード使い回しが原因であるとはいえID部分がメールアドレスのサイトが多すぎる。メールアドレスだとヒモヅル状にほかサイト回れちゃってなんともねぇ。自由に設定できるようにしてほしいものだわ。
原因そのものはパスワード使い回しが原因であるとはいえID部分がメールアドレスのサイトが多すぎる。
違う、そうじゃない。パスワードを平文or元に戻せるデータで保存してるサイトが多すぎるほうが問題。
国外のサービスには無効だとしても、いっそ平文・可逆の暗号としてパスワードを保存することを禁止する法律とかあってもいい気がする。
いやいや、ID 使いまわしの方がダメ。ID、パスワードの組み合わせは、別に平文データが流出しなくても、ブルートフォースや辞書攻撃で突破きたものをリスト化できるから。
あと、認証の仕組みによっては平文保管が必須なものもあるから。(DIGEST-MD5 みたいなやつね。)
＞認証の仕組みによっては今時、WebサービスでDIGESTとか使ってる時点でアウトだろ
＞ブルートフォースや辞書攻撃で突破きたものをリスト化できるから。ブルートフォースを許したなら、それは平文で保存してるのと同レベルかもっと駄目な仕様だ辞書攻撃で突破できたとしたら、単にパスワードの強度の問題で、認証の仕組みや保存方法とは別の問題
＞今時、WebサービスでDIGESTとか使ってる時点でアウトだろ
何故でしょうか？DIGEST 認証自体は Basic 認証なんかよりマシだと思いますけど。あと、Web サービスと書いてありますが、SMTP や POP3/IMAP でも使われます。
通信路を暗号化して平文パスワードを流すのと、通信路もパスワードも暗号化して流すなら、後者の方が良いと普通は考えますね。
＞ブルートフォースを許したなら、それは平文で保存してるのと同レベルかもっと駄目な仕様だ＞辞書攻撃で突破できたとしたら、単にパスワードの強度の問題で、認証の仕組みや保存方法とは別の問題
あのですね、暗号化orハッシュ化されたパスワードリストでも、入手すれば容易に辞書攻撃可能ですよ。サーバ側のパスワードリストが暗号化されてれば漏れても今回のような事態にならないとでも思ってるんですか？
＞DIGEST 認証自体は Basic 認証なんかよりマシだと思いますけど。なんでBasic認証と比べるんだよｗｗｗ「家の扉に鍵をつけないのは、扉そのものをつけないことよりはマシだと思います」ってレベルの比較じゃん。
真面目に言うなら、HTTPの仕様そのものを使った認証は全般的に危険と思ったほうがいいよ。それこそブルートフォースかけるのが容易なだけじゃん。認証はプロトコル側に極力依存しないよう設計すべき。
＞Web サービスと書いてありますが、SMTP や POP3/IMAP でも使われますだからそっちのパスワードが漏れても大丈夫なようにWebサービス側で何とかしろって話でryそもそもSMTPやPOP3、IMAPを提供するのがWebサービスだと思ってるなら出直してきたほうがいいよ。
＞あのですね、暗号化orハッシュ化されたパスワードリストでも、入手すれば容易に辞書攻撃可能ですよ。それは適切に暗号化orハッシュ化されてないだけじゃん。そうじゃないと言うなら具体的な方法書いてみろよ。
Webサービスと書いてあったので、HTTP 周り以外も上げただけです。
今一番おすすめな Salt した hash でも、パスワードDBがもれた場合、Salt はダダ漏れなのであとは辞書に従って攻撃するだけです。事前に暗号化文字列を用意できないだけです。
自宅の鍵に、名前や住所を書いておく人はいません。 - 既知の情報を ログインID にする - ログインIDを積極的に公開するのは、あなたの言う「駄目な仕様」そのものです。
＞Webサービスと書いてあったので、HTTP 周り以外も上げただけです。WebサービスというのはWorld Wide Webの規格に則ったもので、HTML等をベースとしたWebブラウザ上で動くサービスのことを言う。SMTPやPOP3、SMTPのような電子メールサービスは、インターネット上のサービスではあるけどWebサービスではないんだよ。そういう根本的なところから理解してないから出直して来いって書いたんだが。
＞今一番おすすめな Salt した hash でも、パスワードDBがもれた場合、＞Salt はダダ漏れなのであとは辞書に従って攻撃するだけです。それはSaltの実装が悪いか、君がSaltの意味を正しく理解してないだけ。きちんとストレ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
どうせこんなことだろうと思ってた (スコア:-1)
どうせ遅かれ早かれこんなことになるだろうと、クロネコメンバーズが便利そうなのは知っていたが
あえて利用せずに不在の確認やなんかだけをWebで行い、再配達の予約や集荷の受付なんかは電話でしていた。
今騒ぎになっていないだけで、西濃やペリカン、佐川なんかも似たりよったりだろう。
どうして再配達の予約如きのことで、わけのわからんサービスへの加入を強要するのか？
どうして日本郵便のように、わけわからんサービスへの加入無くしてもその程度の受付はできるように何故作れない？
存在しない情報が盗まれることは絶対にないと、そろそろ理解するべき。
その程度のことも理解できないまま、無駄に情報を集めまくってるクソ企業が日本には多すぎる。
管理できないなら、初めから集めるな。
Re: (スコア:0)
クロネコメンバーズはポイントサービスや
流通に乗った時点でのお届け前お知らせなどがメインで
割と適切な量の個人情報収集だけどねぇ。
他に書かれてる通り再配達そのものは登録いらないし。
*最近パスワードリスト攻撃が多く見られますが、
原因そのものはパスワード使い回しが原因であるとはいえ
ID部分がメールアドレスのサイトが多すぎる。
メールアドレスだとヒモヅル状にほかサイト回れちゃってなんともねぇ。
自由に設定できるようにしてほしいものだわ。
Re: (スコア:0)
違う、そうじゃない。
パスワードを平文or元に戻せるデータで保存してるサイトが多すぎるほうが問題。
国外のサービスには無効だとしても、いっそ平文・可逆の暗号としてパスワードを保存することを禁止する法律とかあってもいい気がする。
Re: (スコア:1)
いやいや、ID 使いまわしの方がダメ。
ID、パスワードの組み合わせは、別に平文データが流出しなくても、
ブルートフォースや辞書攻撃で突破きたものをリスト化できるから。
あと、認証の仕組みによっては平文保管が必須なものもあるから。
(DIGEST-MD5 みたいなやつね。)
[Q][W][E][R][T][Y]
Re: (スコア:0)
＞認証の仕組みによっては
今時、WebサービスでDIGESTとか使ってる時点でアウトだろ
＞ブルートフォースや辞書攻撃で突破きたものをリスト化できるから。
ブルートフォースを許したなら、それは平文で保存してるのと同レベルかもっと駄目な仕様だ
辞書攻撃で突破できたとしたら、単にパスワードの強度の問題で、認証の仕組みや保存方法とは別の問題
Re:どうせこんなことだろうと思ってた (スコア:1)
＞今時、WebサービスでDIGESTとか使ってる時点でアウトだろ
何故でしょうか？
DIGEST 認証自体は Basic 認証なんかよりマシだと思いますけど。
あと、Web サービスと書いてありますが、SMTP や POP3/IMAP でも使われます。
通信路を暗号化して平文パスワードを流すのと、
通信路もパスワードも暗号化して流すなら、後者の方が良いと普通は考えますね。
＞ブルートフォースを許したなら、それは平文で保存してるのと同レベルかもっと駄目な仕様だ
＞辞書攻撃で突破できたとしたら、単にパスワードの強度の問題で、認証の仕組みや保存方法とは別の問題
あのですね、暗号化orハッシュ化されたパスワードリストでも、入手すれば
容易に辞書攻撃可能ですよ。サーバ側のパスワードリストが暗号化されてれば
漏れても今回のような事態にならないとでも思ってるんですか？
[Q][W][E][R][T][Y]
Re: (スコア:0)
＞DIGEST 認証自体は Basic 認証なんかよりマシだと思いますけど。
なんでBasic認証と比べるんだよｗｗｗ
「家の扉に鍵をつけないのは、扉そのものをつけないことよりはマシだと思います」ってレベルの比較じゃん。
真面目に言うなら、HTTPの仕様そのものを使った認証は全般的に危険と思ったほうがいいよ。
それこそブルートフォースかけるのが容易なだけじゃん。
認証はプロトコル側に極力依存しないよう設計すべき。
＞Web サービスと書いてありますが、SMTP や POP3/IMAP でも使われます
だからそっちのパスワードが漏れても大丈夫なようにWebサービス側で何とかしろって話でry
そもそもSMTPやPOP3、IMAPを提供するのがWebサービスだと思ってるなら出直してきたほうがいいよ。
＞あのですね、暗号化orハッシュ化されたパスワードリストでも、入手すれば容易に辞書攻撃可能ですよ。
それは適切に暗号化orハッシュ化されてないだけじゃん。
そうじゃないと言うなら具体的な方法書いてみろよ。
Re:どうせこんなことだろうと思ってた (スコア:1)
Webサービスと書いてあったので、HTTP 周り以外も上げただけです。
今一番おすすめな Salt した hash でも、パスワードDBがもれた場合、
Salt はダダ漏れなのであとは辞書に従って攻撃するだけです。
事前に暗号化文字列を用意できないだけです。
自宅の鍵に、名前や住所を書いておく人はいません。
- 既知の情報を ログインID にする
- ログインIDを積極的に公開する
のは、あなたの言う「駄目な仕様」そのものです。
[Q][W][E][R][T][Y]
Re: (スコア:0)
＞Webサービスと書いてあったので、HTTP 周り以外も上げただけです。
WebサービスというのはWorld Wide Webの規格に則ったもので、HTML等をベースとしたWebブラウザ上で動くサービスのことを言う。
SMTPやPOP3、SMTPのような電子メールサービスは、インターネット上のサービスではあるけどWebサービスではないんだよ。
そういう根本的なところから理解してないから出直して来いって書いたんだが。
＞今一番おすすめな Salt した hash でも、パスワードDBがもれた場合、
＞Salt はダダ漏れなのであとは辞書に従って攻撃するだけです。
それはSaltの実装が悪いか、君がSaltの意味を正しく理解してないだけ。きちんとストレ