ユーザーの電子メールアドレスと電子メールパスワードを要求するのは悪い考えですか?

私はネットワークセキュリティ機器を製造している会社でテスターとして働いています、私は機能について開発者といくつかの議論をしています。

機能は、アプライアンスによってユーザーに送信される通知電子メールが、ユーザーが使用するメールサーバー(gmail、ローカルメールサーバーなど)を使用して、ユーザー資格情報(電子メールと電子メールパスワード)を使用して送信されることです

これらの認証情報はプレーンテキストでマシン内にあり、正しいファイルへの猫と一緒に利用できます。開発者は、クレデンシャルをメールサーバに送信するときには常に暗号化を解除する必要があるため、暗号化を使用しても意味がないと主張しています。

今私は何を考えるべきかわからない、これを行うための正しい方法はありますか?または機能が安全ではないとそれを行うための安全な方法はありませんか?

5
@eckesネットワークセキュリティアプライアンスを購入する会社とGMailを使用する会社の交差点は非常に小さいです。
追加された 著者 Jon G - Megaphone Tech,
Googleなどのプロバイダに送信するときは、少なくともOAuthトークンを使用できます。ユーザーがメールサーバー(メールを送信するためのログインなしでアプライアンスを信頼する可能性があります)およびオプションの「送信専用」ユーザーを設定できることに加えて、ユーザーに価値の高いメールボックス資格情報の使用を推奨しません)パスワードを保存した場合、開発者はそれを保護することはできませんが、それを難読化することは、とにかく繰り返し機能を要求することからユーザーを保護するのに役立ちます。
追加された 著者 Panther,
私は反対しますが、セキュリティの問題とクラウドサービスはうまく混在しています。 :)
追加された 著者 Panther,
それはそのままにしておいてください、しかし、彼らはこのアプライアンスのためだけに特別なEメールアカウントを設定するべきであると顧客に言います。
追加された 著者 immibis,
それをバックアップするための技術的なデータなしで、提起された質問に対する簡単な答えとして:はい。そしてそのような情報をだれでもに提供してはいけません。
追加された 著者 baldPrussian,
それは本当にフィッシーで安全ではありません。私はまた記述されたメカニズムの中で何の意味も見ません、あなたは意図された使用法についてもう少し詳しく述べることができますか?
追加された 著者 user63845,
それで私が正しく理解すれば。ユーザーは自分のメールプロバイダを選択してログイン資格情報とサーバーの詳細(POP3サーバーやポートなど)を提供できます。それらの詳細はサーバーマシンにプレーンテキストで保存され、それらの詳細を使用して通知を送信するために使用されますか?
追加された 著者 user63845,
私はここでの唯一の実用的な解決策はあなたが通知を届ける方法を変えることになると思います。顧客提供のメールプロバイダの代わりにあなた自身のサービスの1つを使うことによって。そうでなければ、最終的には、ある時点でプレーンな資格情報を処理する以外に選択肢はありません(つまり、多数のメールプロバイダAPIを統合することができない場合)。
追加された 著者 Conundrum,
@KevinVoorn Yup
追加された 著者 NeoDarque,
@KevinVoornアプライアンスからユーザーに電子メールを送信するためのものです。そして、ユーザーが望む任意のEメールアドレスを使用する
追加された 著者 NeoDarque,

4 答え

This is entirely wrong.

電子メールを送信するために必要なのは、実行中のSMTPサーバー(少なくともエンドユーザーからの資格情報を必ずしも必要としない)と「to」アドレスです。適切なSMTPサーバーを提供または使用するのはアプライアンスの責任です。

ユーザーの資格情報を使用する必要はありません。事実、私は誰にも私の電子メールアカウントのパスワードを教えてはいけない。私以外はだめです。

あなたの開発者は、電子メールを送信するプロセスをまったく間違っていました。

3
追加された
あなた自身のSMTPサーバを動かしたくない 。あなたはそれにSMTP資格情報を持たせたいので、あなたの答えの "適切なSMTPサーバーを使う"セグメントの下でSMTPサーバーへの認証された接続をすることができます。
追加された 著者 Jon G - Megaphone Tech,
これは間違いです。電子メールが確実に受信箱に届くようにするには、あなたのメール転送エージェント( "smtp server")があなたのドメインのSPFレコードにリストされていること、ドメインに対するdomainkeys権限を持っていることなどを確かめなければなりません。そのため、あなたのサーバーはgmail.comのSPFに登録され、DKIM経由で認証されなければなりません。これはgmail.comというゾーンを完全に制御しないと行えません。
追加された 著者 netskink,

プレーンテキストでパスワードを保存することは、使用またはセキュリティ対策に関係なく、安全でないと広く考えられています。コメントセクションで説明したように、あなたの質問は、同じユーザーに通知を送信するために使用される、自分のログイン資格情報、サーバーの詳細、およびメールプロバイダーに関する情報を提供するユーザーについてです。

プレーンテキストでパスワードを保存することについて非常に明確にするために:これはパスワードを扱う安全な方法ではありません。もう少し詳しく説明すると、誰かがサーバーマシンに侵入する、欠陥を使う、またはアプリケーション自体にバグがあるか、または作成されたバックアップを盗みます。ログイン情報を漏らす方法はたくさんありますが、資格情報をプレーンテキストで保存する理由を見つけるのに苦労しています。

この記事をご覧ください。パスワードがプレーンテキストで保存されていたパスワード漏洩事件。この文書では、パスワードの概念とそれらを安全に保存する方法についても多くのことを説明しています。これは、開発者にとっては読む価値のあることです。

アプリケーションはメールサーバープロバイダーのAPIを使用して通知を送信する必要がありますが、そもそもパスワードを必要とすることなく、パスワードを復号化してメールプロバイダーに送信する必要があると彼が言うのは正しいです。

3
追加された
「アプリケーションはメールサーバープロバイダのAPIを使用する必要があります」それはAPIがあると仮定しています、そしてそのAPIが認証されている場合(スパムメールであることがあるはずです)
追加された 著者 Stu,
一言で言えば、それはAPIを使用しています。具体的には、認証された(そしてそれが本当にあなたが望むものである)接続を作るためにSMTP仕様はそれが使うことになっているアカウントのための資格情報を要求しようとしています。
追加された 著者 Jon G - Megaphone Tech,
暗号化されていないことは安全ではありませんが、それを暗号化する安全な方法もありません(信頼できるコンピューティングハードウェアを使用しない限り、さらに攻撃面が非常に大きい場合を除く)。
追加された 著者 Panther,

あなたの開発者は良いセキュリティプラクティスを議論するために座る必要があります。

基本的に、データをディスク上で暗号化したままにするということは、攻撃者がしなければならないのは、そのファイルの本文にアクセスすることだけです。あなたの開発者は、彼のソフトウェアがセキュリティの脆弱性がないこと、システム上の他のソフトウェアが脆弱性がないこと、そしてオペレーティングシステムが脆弱性がないことを保証できません。彼はまた、システムがシングルユーザーモードで動作すること、またはシステムに適切なファイルシステムレベルのセキュリティが適用されることを保証できません。彼はまた、ハードディスクが別のオペレーティングシステムにマウントされて、システムレベルのセキュリティに何も関係がないことを保証することはできません。

基本的に、彼は彼がそのユーザーのデータをそのオペレーティングシステムにアクセスできる他の人と共有していることを保証しています(合法であるかどうか)。彼はエンドユーザーの知らないうちにこれを行っています。

しかし、あなたはまた、ユーザーのデータを暗号化するという考えに半分しか近づいていません。実際には、ユーザーのパスワードをまったく保存しないでください。GmailのOAuth2統合など、問題のメールクライアントのAPIを使用してください。 https://developers.google.com/gmail/api/auth/web-server からメールアカウントに接続します。これは正しい方法であり、暗号化されているかどうかに関わらず、身分証明書があることを避けます。同じことが、ほとんどすべてのメールクライアントにも当てはまります。それらのAPIと統合します。たぶん、最初の握手以外では、ユーザーのパスワードを知る必要はありません。

2
追加された
正しい。それは常にトレードオフです。これは、その性質上、ユーザーの操作を必要としない、サードパーティの認証に最適なセキュリティモデルです。さらに、サードパーティ製アプリケーションをいくつサポートする必要があるかを決定し、それぞれを処理するためのメソッドを作成する必要があります。 Gmailを安全にサポートすることは、すべてのEメールクライアントをサポートすることより優れていますが、安全ではありません。
追加された 著者 Sarah Jean,
いいえ、違います。開発者は、合理的な電子メールプロバイダのセットを判断し、それらにAPIがあるかどうかを判断する責任があります。
追加された 著者 Sarah Jean,
それから彼はより人気のあるEメールプロバイダーに代わることができます。
追加された 著者 Sarah Jean,
「ユーザーのパスワードをまったく保存しないでください」と言っても問題ありませんが、機能を実装していないことを除いて、他に何ができますか?電子メールプロバイダの中には、アプリケーションのパスワード(APIトークンまたはそれを呼び出すために選択したもの)を配布できるものがあり、ユーザーのマスターパスワードよりも望ましいものですが、電子メールの送信時にアプリケーションが保持する必要があります1組のSMTP認証情報を付与するだけのEメールプロバイダーにとってはそれは選択の余地はありません。
追加された 著者 Stu,
@Adonalsiumエンタープライズネットワークセキュリティアプライアンスの「妥当な電子メールプロバイダ」は、「SMTP」です。話の終わり、ほとんど。
追加された 著者 Jon G - Megaphone Tech,
@Gillesこれが、認証を実行する他のWebサイトがユーザーが自分のgmailアカウントと同じものを使用することを期待していない理由です。それらはすべて独立して認証情報を格納します。あなたの会社は、すべてのユーザーのセキュリティの侵害に対して責任を負いたくありません(弁護士を雇うために何人もの法律上の免責条項を結ぶと、あなたはどちらの方法でも失礼になります)。可能な限り、そのような機密情報を保管しないように十分に責任を負うべきです。それがここの一番下の行です。この答えはその場であり、もっと広く受け入れられるべきです。
追加された 著者 netskink,
あなたが正しい。しかし、OPの所在地によっては、GMailは使用されているプロバイダのほんの一部しかカバーしていない可能性があります。
追加された 著者 Conundrum,
あなたはそれらすべてがAPIを持っていると仮定しています。
追加された 著者 Conundrum,
しかし、結局のところ、あなたは常に機密データをマシンに持っているでしょう。パスワードではない場合でも、プライベートAPIトークンはどこかに保存されています(ただし、それをお勧めします)。また、メールプロバイダのAPIを統合することは、顧客が使用するプロバイダを制御しないため、OPにとって実用的ではないかもしれません。
追加された 著者 Conundrum,

あなたの脅威モデルは何ですか?誰がパスワードを盗もうとしますか?

アプリケーションを自分のユーザーとして実行していて、そのユーザーだけがそのパスワードファイルにアクセスでき、しかもあなたがrootを信頼しているのであれば大丈夫です。

理想的には、アプリケーションは独自の電子メールアカウントから送信するので、妥協があっても影響は最小限で済みます(または、このアプリケーション専用の新しいフリーメールアカウントを常にユーザーが作成できます)。

あなたがrootを信頼していないのであれば(あなたがAWSなどで実行しているので)、あなたは大丈夫ではありません。

しかし、私たちはあなたが私たちにあなたの脅威モデルを言うまで知ることができません

2
追加された
中小企業や政府で使用されているネットワーク機器があります。たとえば、ネットワークが危険にさらされ、ハッカーがさらに制御権を取得するために資格情報を取得しようとしている場合、パスワードが盗まれる可能性があります。
追加された 著者 NeoDarque,