メールでパスワードを送信する代わりに？
最近、会社の請負業者として働き始めました。そのため、さまざまなb2bサービスに頻繁にログインする必要があります。
ログインデータを受信する方法は、通常はプレーンテキストの電子メールです。機密データをプレーンテキストで送信するのは良い考えではないと私は直感しますが、別の方法があるかどうか、またはおそらくメールサービス（この場合はgmail）によってすでに保護されているかどうかわかりません。
メールアカウントをログインしたままにしておくと、おそらく最も明白な危険が発生することは承知していますが、中間の攻撃や他の危険にさらされているある種の男性に関心があります。
私の質問の核心は：
電子メールでパスワードを送信する代替手段はありますか？これに電子メールを使用する最大の危険は何ですか？
一般的な方法は、電子メールを介してユーザーに初期パスワードを送信することです。このパスワードは非常に短い間のみ有効であり、最初のログイン時にすぐに変更する必要があります。
これも完璧ではありません。ユーザーの電子メールへの読み取りアクセス権を持つ攻撃者は、ユーザーの前にその初期パスワードを傍受し、ユーザーに代わってそれを使用する可能性があります。ユーザーは、初期パスワードを使用しようとするとすぐに気づきます。彼らはパスワードが間違っていることを管理者に通知し、管理者は不正なアクセスを調査して通知します。しかし、攻撃者は既にアカウントにアクセスするための時間を確保していたため、すでに被害が発生している可能性があります。ただし、永続的に有効なパスワードを送信するよりも優れています。
また、システムがこれをサポートしている必要もあります。したがって、これは普遍的に適用可能な慣行ではありません。
メールプロバイダーがメールの機密を保持することを信頼していない場合（ gmail を使用しています）。オプション。古き良き [〜＃〜] pgp [〜＃〜] 、より現代的な [〜＃〜] pep [〜＃〜] 、IETF標準- S/MIME だけでなく、いくつかの非標準化された独自のソリューション。これが標準のいいところです。選択できるものはたくさんあります。しかし、それらすべてに共通することが1つあります。あなたが理解しているスキームであなたのビジネスパートナーに彼らの電子メールを暗号化させることは厄介な困難な戦いであるかもしれません。
私は通常、パスワードマネージャーを使用してパスワードを保存および共有します。この機能を持つパスワードマネージャーは多数あります。
パスワードは1つのアカウントから別のアカウントに共有され、共有の通知は、共有を受け入れるか、拒否するか、単に無視するかを選択できる他のユーザーに電子メールで送信されます。パスワードの通信は安全ですが、共有の通知は電子メールのような安全性の低いチャネルを経由するため、セキュリティを損なうことなく、それぞれの方法の強みを活用できます。一部の製品では、パスワードを受信者に開示せずにパスワードを共有できます。その場合、パスワードの取り消しが可能になります。
すべてのパスワードにパスワードマネージャを使用することを強くお勧めします。一部の商用のものは、LastPass、1Password、またはDashlaneですが、誰かを信頼したくない場合は、自分でホストする可能性もあります。 「パスワードマネージャー」をグーグルですばやく検索すれば、正しい道に進むはずです。
2つの要因
おそらくそれはあなたの状況に文字通り適切ではありませんが、完全に安全ではないチャネルを介して機密データを送信するための1つの合理的な方法は、そのデータにアクセスするために2つの別々の要素が必要であり、それらが異なるチャネルを介して送信されるようにすることです。たとえば、データが暗号化されたZipファイルで電子メールで送信され、そのデータへのパスワードがSMSで送信されるアプローチを見てきました。この方法では、その電子メールを持っている人も、あなたの電話にアクセスできる人も、機密情報にアクセスすることはできません。
同様に、接続情報をメールで送信し、パスワードを電話で伝えることができる場合（特に、パスフレーズのような場合）は、より適切な方法になる可能性があります。ただし、その選択はほとんど組織次第です送信データ（機密情報を保持する必要のある利害関係者と思われる人）であり、受信しているだけの人には送信しません。
信頼できる場合は、この正確な目的のために onetimesecret （これは オープンソース ）が存在します。
パスワードやプライベートリンクなどの機密情報をメールやチャットで送信すると、その情報のコピーがさまざまな場所に保存されます。代わりに1回限りのリンクを使用する場合、情報は1回の表示の間保持されます。つまり、後で他の人が読むことはできません。これにより、機密情報を1人だけが見ていることを知っている安全な方法で送信できます。それは自己破壊的なメッセージのようなものだと考えてください。
電子メールは、本来暗号化されていないという性質上、プレーンテキストのパスワードを共有するための優れたメカニズムではありません。
この方法でパスワードを共有する場合、サービスは、最初のログイン時にパスワードが変更されて露出を減らし（盗まれたパスワードを誰かが使用したかどうかを検出できるようにする）ことを確認する必要があります。サイトにアクセスする機会のウィンドウの利点ですが、誰かがパスワードを持っていることを知らないよりはましです。
これはシュローダーのコメントへの返信を与えられたあなたにとって選択肢ではないように思われるので、私はあなたの顧客とあなた自身の間のすべての方法でパスワードの暗号化を保証するメカニズムを検討することをお勧めします-エンドツーエンドの暗号化を通して電子メールの内容、またはプレーンテキストのパスワードを暗号化できる認証および暗号化された共有サイトを使用する。また、アクセスしているアプリケーションのセキュリティ要件に応じて、パスワードを知っている他の人（顧客、他のチームメンバー）に本当に満足している場合も考えてください。
ここでの主なリスクは、自分とは別に、誰がパスワードを知っているかです。あなたの場合、これは少なくとも：
- パスワードを生成し、それを電子メールで送信した顧客組織の担当者
- 顧客と自分の間の電子メールインフラストラクチャを管理している人
- 顧客と自分の間の任意の電子メールパスでネットワークにアクセスできる人
- 同じアカウントとパスワードで作業している他のチームメンバー（シュローダーのコメントへの返信から推測）
- メールボックスにアクセスできる可能性のある人（たとえば、電子メールクライアントを無人にすることについてのコメント）
パスワードの唯一の目的がB2Bサービスへの不正アクセスを回避することであり、パスワードを知っている他の人に慣れている場合は、パスワード配布の暗号化を確認できます。多くのSMTPサーバーはメールサーバーホップ間でデータを転送するための暗号化を実装していますが、暗号化の保証はありません。さらに、本質的に電子メールは暗号化されていないため、少なくとも各メール転送（SMTP）ホップでの処理中にパスワードがプレーンテキストで存在します。
つまり、エンドツーエンドの暗号化を調べて、PGP、S/MIME、その他の非対称暗号化独自のテクノロジーなど、スヌーピングするユーザーがパスワードを使用できないようにする必要があります。これらは、転送中のパスワードの機密性を保証し、配布のために電子メールを使用できます-難しいセットアップと運用コストのトレードオフがあります。
安全なチャネル（電話など）を介して共有される事前定義された暗号化パスワードを使用して、暗号化されたZipファイルやOfficeドキュメントなどを侵害し、使用することができます。これにより、操作のオーバーヘッドとパスワードの保護の両方が削減されます。同様に、パスワードが含まれ、安全に共有されたシークレットで保護されたクラウドでホストされたファイルには、同じ利点と欠点があります。
パスワードを送信する理由がわかりません。
クライアントは好みのパスワードを設定し、ハッシュし、ハッシュを保存します。クライアント/彼のパスワードマネージャープログラム以外は誰もオリジナルのパスワードを知らないため、パスワードを忘れると、リセットリンクを送信します。
ただし、本当にパスワードを送信する必要がある場合は、パスワードを表示する動的に生成されたWebページへのリンクを送信することをお勧めします（1回のみ）。
このようなものをデータベースに一時的に保存する必要があります
emailTocken char(32)
password varchar
+----------------------------------+------------------+
| emailTocken | password |
+----------------------------------+------------------+
| 202CB962AC59075B964B07152D234B70 | jhds7ytht_id |
| CF297E613A7F7892A3BF348EE526ABAD | hdhdbdue874# |
| 8F14E45FCEEA167A5A36DEDD4BEA2543 | yeheb8cvddt5) |
| 2510C39011C5BE704182423E3A695E91 | 6#hdyd98_jee |
| 8F14E45FCEEA167A5A36DEDD4BEA2543 | yhrtxbxv48_e |
+----------------------------------+------------------+
そして、パスワードではなく、emailTockenのみを公開するメールを彼に送信します。
Hello, client
Follow this link to see your password
https://example.com/showPassword?emailTocken=8F14E45FCEEA167A5A36DEDD4BEA2543
ウェブサーバー上で誰かがこのリンクをリクエストすると、次のようになります
- emailTockenが提供されているパスワードを選択します
- データベースからそのレコードを削除する
これで、このリンクを要求する最初の人は次のようになります
Hello, client
your password is yeheb8cvddt5)
NOTE: WE WILL DELETE THIS PASSWORD FROM OUR SERVERS, SO YOU HAVE TO REMEMBER/SAVE IT
後で誰かが同じリンクを要求した場合、彼は次のようなものを見るでしょう
Sorry, this password is not exist or has been viewed before!
電子メールでパスワードを送信することに対するこのアプローチの利点：
- パスワードは最初の閲覧者に1回だけ公開され、後で電子メールを見る人には公開されません。
- 他の誰かが最初にパスワードを表示した場合（中間者）、正当なユーザーはそれを見ることができず、助けを求めます。これにより、他の誰かよりも問題が発生したことがわかります。それを見てください、そして私達も知りません。 私はあなたのメールエージェントプログラムが何らかの理由でこれを自動的に要求しないことを望みます：（。
電子メールでパスワードを送信することに対するこのアプローチの欠点：
- webサーバーが必要
- メールで簡単にパスワードを送信するよりも多くの作業
前に言ったように、クライアント以外は誰もパスワードを知らないはずであり、私はこのアプローチを試したことはありませんが、少なくとも、常駐できる電子メールでプレーンテキストでパスワードを公開するよりはましです。しばらくの間、多くのコンピュータ/サーバーで
私が作成した小さなプロジェクトがあります "Secure Messaging Service" を呼び出すと、メッセージを入力して、そのメッセージを表示するためのリンクを生成できます。メッセージが表示されると、データベースから削除されます。メッセージを読んだときにメールを送信することもできます！
メッセージを入力して「送信」を押すと、サーバーがGUID、passwordwolf.comに基づくランダムな8文字のパスフレーズ（データベースに保存されていない）を生成します） 、AES-256-CBCを使用してメッセージを暗号化します。その後、GUIDとメッセージを表示するためのパスフレーズ（または誰かに送信してメッセージを表示するためのパスフレーズ）を含むリンクが届きます）、リンクが使用されるとすぐに、メッセージはデータベースに存在しなくなります。
これで、受信者がメッセージを読んだときに電子メールでサービスを送信できるようになりました。メールを入力すると、データベースに挿入する前に、同じパスフレーズを含む秘密のメッセージと同じ暗号化方法を使用してメールを暗号化します。このパスフレーズはサーバーに保存されておらず、メッセージを表示するためのリンクの一部として提供されています。
サーバーに送信されるものはすべてAES-256-CBCで暗号化されており、パスフレーズは提供されたリンクにのみ存在するため、リンクを送信したユーザーと誰でもメッセージを表示できます。他の誰かがそれを表示したい場合、彼らはそれを総当たりする必要があります。毎秒10億（1018）のAESキーをチェックできる50台のスーパーコンピューター（理論上、このようなデバイスが作成された場合）は、理論上、256ビットのキースペースを使い果たすのに約3x1051年かかります。リンクを知っている人がデータベースにアクセスできる場合でも、これらのメッセージが誰にも表示されないようにするために最善を尽くしましたが、保証はなく、このサービスの使用によって生じたいかなる損害についても責任を負いません。
Secure Messaging ServiceにはAPIサポートもあります。つまり、パスワードを表示するためのリンクを登録しているユーザーに、電子メールを自動的に生成して送信する可能性があります。
これは、データベース内のデータの格納方法です。ご覧のとおり、指定されたリンクにのみ追加される特別なパスフレーズが必要なため、表の情報を使用してメッセージの内容を復元する方法はありません。メッセージを作成するときにあなたに送信され、データベースには保存されません。
まず、これはちょっと悪い状況です。ユーザーアカウントを共有しているようです。これに代わる優れた方法がない場合もありますが、同じ名前でログインしている複数のユーザーがいる場合、リソースの使用を監査するのが非常に難しくなるため、特に機密性の高いものと一緒に使用しないでください。
複数のユーザーが同じアカウントを使用することが本当に必要な場合は、資格情報を直接提供する必要があります。
それはおそらく実用的ではないので、次善の策は固定電話を介して送ることです。 （少なくともほとんどの国では）固定電話は傍受することが比較的難しく、ほとんどの国では電話会社は裁判所の命令なしに傍聴することが禁止されています。政府のスパイ機関が耳を傾けているかもしれませんが、彼らがあなたのパスワードを望んでいるなら、あなたがとにかくそれらを渡すまで彼らはあなたを打ち負かすでしょう。
ほぼ同じレベルのセキュリティは、GPGまたは同様の方法で暗号化された電子メールです。第三者がデータを傍受して保存するのは簡単ですが、鍵を解読するのに十分な時間があるまで、第三者がデータを読み取るのは困難です。数年ごとにパスワードを変更し、毎回同じフォームレターを使用しないようにしてください。これにより、解読が容易になります。
あなたがそれでそれらを船に乗せることができないならば、本のコードはあなたの次の最善の策です。とにかくみんなが持っていて、いつも使っている本である必要があるので、それは少し難しいかもしれません。典型的なフォーマットは、ページ番号-段落番号-ワード番号のようなものです。パスワードを4または5語にすると、うまく機能します。または、必要に応じて、指定された各単語の最初の文字を使用してスペルアウトします。
本のコードが機能しない場合、パスワードに単語や単語のような構造が含まれていない限り、新聞の暗号文に使用されているような単純な置換または転置暗号で、最も決定的な攻撃者以外のすべてを防ぐことができます。 。ただし、パスワードはランダムな文字である必要があります。そうしないと、統計分析によって短時間で機能し、安全なチャネルを介して暗号化キーを配信する必要があります。この方法では明らかに、パスワードのみを暗号化して攻撃対象を制限し、残りの電子メールでパスワードをスクランブルしたという事実については何も触れないでください。パスワードが暗号化されているという事実と、どのように安全なチャネルを経由する必要があるかについてのすべての議論。
distributed開発チームには、SysOpsとTeamMembersがリソース（データベース、サービス、サーバー）への認証情報を作成し、それを通信する必要がある典型的な使用例がありますチーム。チームに新しいメンバーを追加する場合：
- パスワードをハッシュ化することはできません。
- パスワードをリセットすることはできません。そうしないと、チームの他のメンバーのパスワードが機能しなくなります。
分散パスワードマネージャーを使用します。これにより、新しいパスワードを追加して、個人またはグループと共有できます。 「BOFH-1がパスワード「JenkinAdmin」を共有しました」のような電子メールを受け取ります。 httpsを通過する実際のパスワードを確認するには、ログインする必要があります。
一元化されたツールは、いくつかのインストールと構成を強制するため、シナリオによってはやり過ぎになる場合があります。すべての部門がそれを使用して更新することは素晴らしいことです。パスワードマネージャーで資格情報を更新する必要があるのは1人だけです。私たちはオープンソースツールを使用していますが、特定のプログラムについては ソフトウェアの推奨事項 で詳しく説明しています
パスワードの送受信には Signal を使用することをお勧めします。エンドツーエンドの暗号化チャットアプリです。
信号メッセージと通話は常にエンドツーエンドで暗号化され、通信を安全に保つために綿密に設計されています。私たちはあなたのメッセージを読んだり、あなたの電話を見たりすることはできません。
メールサーバーでSSLを使用している場合でも、サーバーのディスクにメッセージの記録があり、管理者が読み取ることができるため、電子メールは安全ではありません。安全なのは、PGP/GPGまたはSMIMEで暗号化された電子メールだけです。
誰かが私の答えに以下を追加しました。聞いたことがないのでお勧めできません。
シグナルの上に-リンクをクリックしたり電子メールを提供したりしてIDを確認する必要のない、メッセージ交換の別の暗号化オプションを使用できます。これも非常に重要なマルチプラットフォームです。です
- android：会話アプリ
- linuxおよびWindowsの場合：Gajimアプリ
PGPまたはOMEMO暗号化を使用できます。プラグインを個別にインストールする必要がある場合があります。
別の方法もありますが、おそらくあなたの状況に最適です。
SSLを使用するWebサイトと、Webサイトおよび埋め込みボックスが必要です。誰かがそのボックスにメッセージを書き込むことができ、送信時に、メッセージはPCの電子メールでのみ自動復号化できるPGP公開鍵で暗号化されている必要があります。
代わりに電話をかけて電話をかけるように依頼します。帯域外通信を使用すると、盗聴者があなたの情報にアクセスする可能性が大幅に減少します。これは、攻撃者が電子メールシステムまたは電話システムを危険にさらす可能性は低いとは言えないが、両方が危険にさらされる可能性は低いためです。重要な情報（メールのユーザー名、電話でのパスワードなど）を分割できる場合、攻撃者にとっては、必要な作業の増加に比べて難しくなります。
電子メールが会社によって事前設定されている場合、解決策はパスワードをまったく持たないことです（パスワードには、誰も知らない長くて複雑な文字列がシードされています）。
次に、新しいパスワードを要求します（「パスワードを忘れた」機能を使用します）。これにより、電子メールへのリセットリンクが送信されます。
メールでパスワードを送信するのは危険です。
安全な初期アカウントプロトコルは次のとおりです。
ユーザーに1回限りの使用で期限切れのハイパーリンクを送信し、ユーザーがそのリンクから初期パスワードを設定できるようにします。次に、オプションで、ユーザーが2番目の要素を設定したことを確認します。次に、オプションでユーザーのIDを別の方法で確認します（ビデオ通話ですか？）最後に、ユーザーのアカウントに必要なアクセス権をプロビジョニングします。
古き良き電話は、実証済みの真の方法です。
これとは別に、SSHハンドシェイクは良い方法です...
あなたと受信者の両方がSSHキーを生成します。パスワードを生成し、キーを使用してパスワードを暗号化します。暗号化されたパスワードをクライアントに送信します。彼らは彼らのキーを使用してあなたのメッセージに追加の暗号化を追加します。その後、彼らはあなたに二重暗号化メッセージを送り返します。このメッセージを復号化し、受信者のキーで暗号化されたパスワードのみを残します。あなたはこのメッセージを送り返します。彼らはパスワードを取得するために自分のパスワードを使用してそれを解読します。このようにして、暗号化されていないデータがWebに触れることはありません。
最初に頭に浮かぶのは、非対称暗号化（例：GPG）です。これは、物事を過度に複雑にすることなく特に役立ちます。
公開鍵サーバーを見つけてセットアップし、公開鍵を誰もが共有できるようにします。そうすれば、特定の受信者に対して機密性の高い何かを共有する必要があるときはいつでも、彼の鍵を取得してコンテンツを暗号化できます。受信者以外は誰もオリジナルのコンテンツを知ることができません。
電子メールの例は次のようになります。
IBug様
Information Security Stack Exchangeへのログイン認証情報です。企業の鍵サーバーで見つかったあなたの鍵
DEADBEEFで暗号化されています。< GPG Encrypted Message >
SendPass（ https://sendpass.app ）を使用できます
私の意見では、プレーンテキストのパスワードを送信することの2つの最大のリスクは、それらがアーカイブ、ログ、またはユーザーのメールボックスに存在する可能性があることです。管理者に通知しない）。
これらのリスクに対処するために、受信者がパスワードを取得するために使用できるワンタイムコードを送信するために使用できる無料のアプリケーションを作成しました。 SendPassを公開して、他の人、特に技術者でない人を支援しましたが、あなたにも役立つかもしれません。
SendPassは、パスワードを共有するための無料で簡単かつ安全な方法を提供します。 SendPassは、受信者に送信できる一意の1回限りのコードを生成することによって機能します。コードは1回しか使用できません。その後、パスワードは即座に削除されます。
OAuthは、サードパーティシステムにアクセスするための代替手段であり、システムにパスワード認証をセットアップする必要がなく、パスワードを交換する必要がありません。もちろん、そのためにはシステムがOAuthをサポートする必要がありますが、常にそうであるとは限りません。