アカウント名:
パスワード:
ユーザー→SSL→Webサーバー→SMTP over SSL→メールサーバー→POP over SSL→担当者ならSMTPやPOPでも問題なし。
「セキュアでなければいけない経路」を検討した結果ならば、
ユーザー → SSL → [ Webサーバー → SMTP → メールサーバー → POP → 担当者 ] ↑ ↑ セキュアでなければいけない経路
日本最大の某モールは決済代理がウリの一つのはずなのに店舗側に必要ないはずのカード情報を漏らしたことで最終的に店舗側の退職者によるデータ持ち逃げで漏洩した事例もあり、怖いのはカード会社だけじゃないんですよね。。。
そうだな俺もいつ、酔っぱらって、自分のカード情報を公共の場で公開してしまうかもしれない人間の行動が一番重要だよな、気をつけねば
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
とんだ抜け穴だ (スコア:1)
社外取引企業とのやり取りには暗号化していなかったでOK?
ユーザー→SSL→販売業者→非暗号→カード会社
間抜けすぎますな。
日本のカード会社では同様のことがない事を願いたい。
Re:とんだ抜け穴だ (スコア:1)
カード会社(取次業者)との接続は、通常は専用線(INS64)ですから。(専用線を引かない場合はダイアルアップ)
# 通常は、取次業者の提供する接続用のコンポーネントを使います。
# この通信用コンポーネントで暗号化されている筈です。(されているといいな‥)
# システムの内側に専用線経由の通信を盗聴するような仕組みを仕込むような侵入者なら取次業者の通信用コンポーネントくらい解析しているかもしれませんが…
notice : I ignore an anonymous contribution.
Re: (スコア:0)
よくあるWebからの問い合わせなんかで
ユーザー→SSL→Webサーバー→SMTP→メールサーバー→POP→担当者
なんてのは良くある。SMTPもPOPも平文のまま。
そういう小さいレベルでの
「セキュアでなければいけない経路が終端までセキュアでない」
というのは結構見るよ。
Re: (スコア:0)
ユーザー→SSL→Webサーバー→SMTP over SSL→メールサーバー→POP over SSL→担当者
ならSMTPやPOPでも問題なし。
Re: (スコア:0)
「セキュアでなければいけない経路」を検討した結果ならば、
Re: (スコア:0)
担当者がエロサイトとかアングラサイトみて感染、漏洩ケースもありえますな。
Re: (スコア:0)
ISPに届くまでの経路が安全ではない(平文でSMTPで送られてくる)のだから、その先を保護しても無駄ってことでしょうか。
Re: (スコア:0)
日本最大の某モールは決済代理がウリの一つのはずなのに店舗側に必要ないはずのカード情報を漏らしたことで
最終的に店舗側の退職者によるデータ持ち逃げで漏洩した事例もあり、
怖いのはカード会社だけじゃないんですよね。。。
Re:怖いのはカード会社だけじゃない (スコア:0)
そうだな
俺もいつ、酔っぱらって、自分のカード情報を公共の場で公開してしまうかもしれない
人間の行動が一番重要だよな、気をつけねば