web-dev-qa-db-ja.com

メールホスティングプロバイダーがパスワードを見ることができると気付いたらどうしますか?

昨年、ホスティングプロバイダーから、私たちのアカウントの1つに関する電子メールを受信しました。この電子メールは侵害されており、スパムをかなり寛大に支援するために使用されていました。

どうやら、ユーザーはパスワードを自分の名前のバリエーションにリセットした(姓はおそらく最初に推測できるものである)。彼女は1週間以内に即座にハッキングされました-彼女のアカウントは270,000のスパムメールを大量に送信しました-そして非常に迅速でしたブロックされました。

これまでのところ、特別なことは何もありません。発生します。パスワードをより安全なものに変更し、ユーザーを教育して次に進みます。

しかし、何かが気になりましたさらに私たちのアカウントの1つが侵害されたという事実よりも。

私たちのホスティングプロバイダーは、役立つように、実際には次のメールでパスワードを引用で私たちに送っています:

enter image description here

びっくりしました。間もなく契約を更新する予定ですが、これは契約違反のようです。

ホスティングプロバイダーがアカウントで使用されている実際のパスワードを確認できるのはどのくらい一般的ですか?

ほとんどのホスティングプロバイダーは、最前線の担当者よりも多くのアクセス権を持つ(そして必要に応じてパスワードを検索できる)アカウント乱用部門を持っていますか、またはanyを可能にするためのベストプラクティスに従っていない人ですか? =ユーザーのパスワードにアクセスするスタッフの?パスワードはハッシュ化され、取得できないことになっていると思いましたか?これは、全員のパスワードをプレーンテキストで保存することを意味しますか?

ホスティングプロバイダーがこの方法でアカウントパスワードを発見できるのはlegalですか?それは私にとってとても信じられないようです。

プロバイダーの変更を検討する前に、これは一般的な慣習ではないことと、次のホスティングプロバイダーも同じように設定されていない可能性があることを確認してください。

これについてあなたの意見を聞くのを楽しみにしています。

はい。ISPおよび電子メールサービスプロバイダーは、パスワードをプレーンテキスト、またはプレーンテキストに簡単に回復できる形式で保存するのが一般的です。

これの理由は 認証プロトコル PPP(dialup and DSL)、RADIUS(dialup、802.1 xなど)、POP(メール)など。

ここでのトレードオフは、パスワードがISPのデータベースで一方向にハッシュされている場合、使用できる認証プロトコルは、パスワードをプレーンテキストでネットワーク経由で送信するプロトコルのみであることです。ただし、ISPが実際のパスワードを保存している場合は、より安全な認証プロトコルを使用できます。

たとえば、PPPまたはRADIUS認証では、CHAPを使用する場合があります。CHAPは、転送中の認証データを保護しますが、ISPがプレーンテキストのパスワードを保存する必要があります。同様にPOP3へのAPOP拡張機能付き。

また、ISPが提供するさまざまなサービスはすべて異なるプロトコルを使用し、それらすべてを同じデータベースに対して認証させる唯一のクリーンな方法は、パスワードをプレーンテキストで保持することです。

これは、ISPのスタッフの中でデータベースにアクセスできるの問題の問題に対処していませんただし、セキュリティで保護されています。あなたはまだそれらについて難しい質問をする必要があります。

ただし、おそらくこれまでに学んだように、ISPのデータベースが危険にさらされることはほとんど前例がありませんが、個々のユーザーが危険にさらされることはあまりにも一般的です。どちらにしてもリスクがあります。

参照 姉妹サイトでパスワードを回復できないようにする必要があると誤解している(一方向ハッシュ)?IT Security

33
Michael Hampton

パスワードをプレーンテキストで保存するか、なんらかの可逆暗号化を使用している可能性があります。

あなたが推測したように、これは非常に悪いです。

従業員の悪意や過失、または外部の当事者によるシステムの侵害が原因で、プレーンテキストのパスワードが悪用されると、システムだけでなく他のシステムでも同じパスワードが使用される可能性があるため、重大なリスクが生じます。

パスワードの責任ある保存とは、リバーシブル暗号化の代わりに一方向ハッシュ関数を使用することを意味し、ユーザーの入力に salt (ランダムデータ)を追加して Rainbowテーブル の使用を防ぎます=。

私があなたの立場にいるなら、プロバイダーにどのように正確にパスワードを保存するか、そしてどのように正確にサポート担当者がパスワードを取得できたかについて、プロバイダーに難しい質問をします。これは、パスワードをプレーンテキストで保存することを意味するわけではありませんが、変更されたときにどこかにログを記録している可能性があります。これも大きなリスクです。

7
Shane Madden

他のすべての答えは素晴らしく、非常に良い歴史的ポイントを持っています。

しかし、私たちはパスワードをプレーンテキストで保存することで大きな財政問題を引き起こし、ビジネスを完全に破壊する可能性がある時代に生きています。安全でない電子メールを介してプレーンテキストでパスワードを送信することも、NSAの時代にばかばかしいように聞こえ、すべての通過データを吸い込んでいます。

一部の古いプロトコルではプレーンテキストのパスワードが必要であるという事実を受け入れる必要はありません。もし私たち全員がそのようなサービスを受け入れるのをやめたら、おそらくサービスプロバイダーはそれについて何かをして、最後に古代の技術を廃止するでしょう。

一部の国では、飛行機に乗って別の国に飛行機で行きたいとき、路上駐車場から文字通り飛行機に乗るだけだったことを覚えています。これまでにないセキュリティ。今日、人々は適切なセキュリティ対策が必要であり、すべての空港がそれらを配備していることに気づきました。

別のメールプロバイダに切り替えます。 「安全なメールプロバイダー」で検索すると、多くの結果が得られます。

コメントにはいくつか良い点がありました。すべての電子メールプロバイダーが安全であることを自慢しているので、「安全な電子メールプロバイダー」を検索することはおそらく意味があります。しかし、私は特定の会社を推薦することはできず、おそらくそれを行うこともお勧めできません。特定の企業がセキュリティについて厳しい質問をすることを最初に特定した場合、それを行うことをお勧めします。

5
oleksii

私の推薦は、去って、彼らの方針が最初であるものを次の人に尋ねることです!
あなたがいいと感じているなら、あなたが去る理由を古いプロバイダーに伝えることができます。


また、別の回答のステートメントに対処するために、レインボーテーブルの時代が過ぎました。それらは高性能のGPUに取って代わられており、ストレージ領域が多すぎます(バイナリハッシュは明らかにうまく圧縮されません。そして、とにかくそれらをASCIIに保存しません)。それは(ディスクから読み取るよりも、GPUでハッシュを再計算します。

使用されているハッシュアルゴリズムとGPUに応じて、最新のパスワードクラッキングコンピューターは、1秒間に約1億から10億のハッシュをチャーンすることが予想されます。 this によると(これは、コンピューター/スーパーコンピューターが実行できると考えていることについて少し日付が記載されています)、これは、6文字のパスワードが数秒で解読される可能性があることを意味します。すべてのさまざまなアルゴリズム(MD5、SHA-1、SHA-256、SHA-512、Blowfishな​​ど)の7および8文字のハッシュのテーブルは、過度のディスク領域を消費します(SSDに格納する必要があることに注意してください)。 、アクセス速度の観点から、磁気プラッターではありません)、GPUを使用した辞書ベースの攻撃がパスワードをより迅速に生成する理由がわかります。

シーンに入ってきた人のための素晴らしい記事は、Ars Technicaの (私がパスワードクラッカーになった方法 )です。

3
Nicholas Shanks

これは私に起こった!

数年前、私のホスティングプロバイダー(当時は私の電子メールプロバイダーでもあった)がセキュリティ違反を起こしたときに、身元が侵害されました。パスワードがリセットされたため、メールを確認できなくなった。私のメールを制御して、AmazonとPaypalで私のパスワードをリセットしようとしました。あなたは次に何が起こったのか推測できますよね?クレジットカード詐欺!

幸い、私は比較的迅速に何が起こっているのかを把握し、ホスティングプロバイダーに電話をかけ、アカウント情報とセキュリティの質問が変更されていても(すべて数時間で)自分のIDを入念に検証できました。 この会話の間に、カスタマーサービス担当者は私のパスワード履歴をいつ変更されたか、そして何に変更したかを教えてくれました。それが私がする必要があるすべてでしたプロバイダーを変更する必要があることを知って聞いてください。

私たちの会社であるあなたに起こるはずの理由はありません!

セキュリティに関しては、この会社の完全性、何年にもわたってそれらに対処していたことに気づいたことについて、私は疑いを持っていました。しかし、それは大した問題ではないか、多分私は確信していました間違えました。私も間違えたのではなく、あなたも間違っていません!

私が最初に彼らが安全を真剣に考えていなかったと私が最初に疑ったときに行動したならば、全体のミニ悪夢は決して起こらなかっただろう。貴重な企業アカウントが侵害された場合に何が起こる可能性があると考えるか?彼らがスパムを送っただけなら、あなたは簡単に降りるでしょう。当時働いていた会社もこのプロバイダーを利用していたので、できるだけ早く移行することを最優先しました。

本能を信頼してください!怠惰からの移行、または既存の設定が「正常に動作する」ために見返りを渡さないでください。パスワードをクリアテキストで保存する、サーバーを不適切に構成するなど、セキュリティに関する見落としがちな見落としの最も深刻な部分は、技術文化における一般的な無能さや怠惰さについて話していることです。これは、会社のミッションクリティカルを望まない文化です。近くのどこでもサービス契約。

1
Matt Surabian

私はあなたのパスワードがあなたのプロバイダーのサーバーで実際にハッシュされるという別の説明を見ることができます。

プロバイダーが翌日にあなたに連絡したとき、おそらく彼は(そしてこれは推測ですが)パスワード変更スクリプトがGETメソッドを介してデータを送信しているため、サーバーログからそれを引き出しました。

それはあなたのプロバイダーが彼のパスワードをいつ、誰が、どのように変更したかという記録でいっぱいのデータベースを持っているよりも簡単に聞こえます。あなたは知っています オッカムのかみそり ...;)

0
Peta Sittek