題:
遠程發送密碼給某人
user36976
2014-05-22 17:06:50 UTC
view on stackexchange narkive permalink

作為通常與其他國家/地區的人一起工作的人，向彼此發送登錄信息一直是一個問題。

對於開發登錄詳細信息（例如調試數據庫等），請確保我可以通過明文電子郵件或其他方式將其發送出去，但是當涉及到實際生產信息（例如SSH密鑰）時，當面對時如何安全地將其發送給某人不能面對面。

您是否考慮過使用GPG？
您可以使用LastPass與他人安全共享密碼
我遇到了這個確切的問題，因此決定使用Javascript建立一次性的RSA加密。常見問題解答解釋了為什麼這樣做安全（例如，您的密碼從不發送到服務器），您可以在這裡嘗試：http://tanin.nanakorn.com/labs/secureMessage
十二 答案:
paj28
2014-05-22 18:50:36 UTC
view on stackexchange narkive permalink

我通常使用短信。雖然不是完全安全，但它比電子郵件更安全，而且通常足夠。它的主要優點是不需要進行任何設置，例如交換PGP密鑰。

通過電子郵件發送一半密碼和SMS發送一半密碼，可以使其更加安全。或者（按照Michael Kropat的建議），通過電子郵件發送帶有對稱加密密碼的文件，然後通過短信將解密密碼發送給SMS。

對於SSH密鑰，您應該只傳輸公共密鑰。如果您授予用戶訪問服務器的權限，則他們應該向您發送其公共密鑰，而不是向他們發送私鑰。您仍然需要確認收到的密鑰是真實的，但不需要對其保密。

為此+1。我還使用短信進行“安全”密碼傳輸，同時通過其他渠道（電子郵件或IRC）發送其他信息。僅截獲該消息的人將沒有足夠的信息來找出其密碼。僅當密碼為一次性使用通行證，並且用戶被迫在登錄時更改密碼時，這才是有效的安全措施。
我不會只拆分密碼。使用“ openssl aes-256-cbc -out FILE”之類的簡單密碼對密碼文本進行加密，將加密後的文件通過電子郵件發送給他們，然後通過SMS發送解密密碼。
@MichaelKropat好主意；我已經編輯了答案以包括此內容。與所有其他內容一樣，在安全性和便利性之間需要權衡取捨。
當您使用諸如[TextSecure]（https://whispersystems.org/）之類的東西時，SMS甚至更好。
@GregHewgill-更好...也許，如果TextSecure實際上像其網站所聲稱的那樣安全，但這是以要求收件人安裝該應用程序為代價的。
如何通過常規電話發送密碼？如果那還不夠好，該如何使用[Cellcrypt]（http://www.cellcrypt.com/）之類的東西？
如果您都擁有iPhone，則可以通過iMessage的端到端加密安全地使用SMS。
為什麼SMS比電子郵件更安全？
@Bergi-很好的問題，並且可能值得提出一個問題。傳統上，因為SMS具有傳輸加密和可信賴的運營商。如今，電子郵件往往也具有這些屬性，因此差異有所減少。在這種情況下。關鍵好處是SMS是一個獨立的頻道，可以將密碼分成兩部分。
@paj28:單獨的通道，是的；但是值得信賴的運營商我會提出質疑：-)不要忘記[Dishfire]（https://zh.wikipedia.org/wiki/Dishfire）和Co.
@Bergi-如果您想擊敗NSA監視，那麼是的，您不僅需要SMS，還需要更高的安全性！
+1用於請求SSH公鑰。獲取公共密鑰還有一個額外的優勢，即您現在可以共享服務器中包含機密數據的文件。只要確保您適當地限制對該服務器上文件的訪問即可。
我知道這很舊，但是給人的印像是電話公司記錄了所有SMS和NSA。
@jbo5112-正確。如果您想防止NSA監視您，此方法將不合適。不幸的是，任何更安全的機制也將更加難以使用，並且對於典型的商業數據而言也沒有用。
user47079
2014-05-22 19:11:31 UTC
view on stackexchange narkive permalink

當我需要一次發送某封郵件時，我使用了一次性秘密。這是一個開放源代碼的Web應用程序，允許您輸入只能查看一次的信息。收件人打開頁面後，信息將被刪除，並且聊天日誌或電子郵件中唯一剩下的就是錯誤的鏈接。

它不如使用PGP的整個團隊那麼強大，但是易於設置或解釋。我已經能夠使用它來向非技術人員發送登錄信息，他們發現它易於使用。

如果您不介意別人獲取密碼，那麼這是一個極好的解決方案。
-1
-1
@Sumurai8但是，當確實存在安全的信息發送方式時，為什麼還要為這樣的方案而煩惱呢？
@Keavon re:“沒有人會猜到像...這樣的鏈接。”我不願意相信這種安全性，尤其是這意味著我必須相信服務器的管理員。回复：“它也可以讓您密碼保護信息。”好吧，如果我有一種安全的方式來傳輸用於保護信息的密碼，那麼這首先意味著什麼？
由於@IstvanChung已發布源，因此您也可以自己託管此服務的實例。
我在企業環境中運行OTS。這很棒。我們已經對其進行了重新設計，並將其鎖定在最小的VM上。
Fleche
2014-05-22 17:38:04 UTC
view on stackexchange narkive permalink

正如評論中已經提到的那樣，這是GPG / PGP的經典用例。每個人都創建一個密鑰，以任意方式交換它們，然後通過電話，視頻聊天或任何其他渠道驗證指紋，並提供合理的保護以防止數據被篡改。

您還可以互相簽名'鍵以建立小型信任網絡。例如，如果您已經驗證並簽署了開發人員A和開發人員B的密鑰，則A和B可以彼此信任，而不必再次驗證密鑰。

由於使用我的某些人使用的服務（例如hotmail）沒有內置的GPG / PGP功能，因此使用起來並不容易，您必須使用郵件客戶端來執行此操作。同樣，與我一起工作的一些人也不是懂技術的人，他們不知道如何使用GPG / PGP（這對開發人員來說是一個很好的解決方案）。
使用術語“模擬密鑰”代替GPG / PGP。 SSH p2p連接或cr竊聊天或類似功能可以完成此任務
這不僅是任何形式的非對稱加密。如上所述，GPG的功能之一是用戶可以簽署密鑰並建立信任網絡。這無疑在團隊合作中很有幫助。領先的開發人員可以一次驗證並簽名所有密鑰，然後每個人都可以與每個人進行交流，而不必先親自驗證密鑰。並非所有協議都適用。
@Nick不必在郵件客戶端中內置GPG / PGP。您可以使用獨立工具進行加密和解密，然後通過郵件發送ASCII裝甲文本。
@IstvanChung我知道，但是對於甚至不知道什麼是PGP / GPG的人來說……他們將無法找出答案。
我已經訓練客戶使用PGP / GPG；任何一位稱職的人員（足以使人信任密碼）都可以很容易地將其取走。但是令大多數人震驚的一點是他們忘記了密碼。然後，我不得不解釋沒有辦法將其找回來，而他們必須重新開始。
Simon Richter
2014-05-22 20:20:03 UTC
view on stackexchange narkive permalink

對於SSH密鑰，我讓它們生成密鑰並將其發送給我，然後我們可以通過電話簡單地比較指紋。

munkeyoto
2014-05-22 17:17:23 UTC
view on stackexchange narkive permalink

您可以使用慢速方法將密鑰郵寄（郵寄）到USB密鑰上，但是在當今時代這是不切實際的。在這種情況下，我要做的是，有一個專用的NOC操作Web服務器，用於將密鑰存儲在目錄中，該目錄將為我需要向其發送密鑰的任何人創建。我用mod_security和.htaccess規則鎖定了Web服務器，以僅允許我想通過IP查看該目錄的個人。

我的結構類似於以下內容。假設我需要在中國創建一個開發人員組的密鑰，我將根據其名稱/組的校驗和創建一個目錄，等等：

  [myoto @ mymachine〜]＃mkdir `md5 -s devchina | awk'{print $ 4}'`[myoto @ mymachine〜]＃cd`md5 -s devchina | awk'{print $ 4}'`[myoto @ mymachine〜/ 4b4dda9422c2de29f9a0364f1bd8494d]＃cp / path / to / ssh_keys / what_I_want_2_copy。

這可確保沒有人會偶然使用類似Nikto / Wikto等。.htaccess和mod_security規則使我能夠控制誰進入該目錄，並且在通過日誌查看密鑰已復制後，我可以對其進行清理。

特別是如果僅用於臨時用途，為什麼要使用哈希？只需製作一個GUID（`mkdir -v $ {uuidgen）`），或在此任意時間點取秒數即可。（mkdir -v $（date +％N）`）。如果您隨後清理它們，那麼很難在短時間內“偶然發現”這兩者。
@MichaelKjörling，您是對的，但如果您有很多未完成的文件夾，則擴展性不好
Samuel Edwin Ward
2014-05-22 22:53:21 UTC
view on stackexchange narkive permalink

您可能不需要發送ssh秘密密鑰。

遠程個人應該在其末端生成密鑰對，保留秘密密鑰，然後向您發送公共密鑰。

p>

公鑰不是秘密，因此以明文形式發送公鑰不是問題。

然後，您只需將其公共密鑰添加到授權密鑰列表中即可。

您可能唯一的問題是確定收到的公鑰確實來自您要授予訪問權限的人。

如果您還有其他需要共享的秘密信息，那麼，現在兩者都可以具有對共享服務器的安全訪問權限，因此您可以使用它。

Josh
2014-05-22 22:13:58 UTC
view on stackexchange narkive permalink

如果您都使用 LastPass設置了帳戶，則該服務可讓您與其他方共享密碼（和其他安全信息）。

是的，如果您願意為運行LastPass的任何人提供信息。除非您信任並認識運行該網站的人，否則第三方軟件就不是一個很好的解決方案，即使這樣數據庫也可能被分解為
AJ Henderson
2014-05-22 18:37:09 UTC
view on stackexchange narkive permalink

如果他們每個人都可以使用安全的文件共享站點設置帳戶，則可以將文件共享給每個人。如果您想自己做，則可以設置啟用了加密的OwnCloud之類的東西，並將其用作與多個人進行安全文件交換的方式，只要您對OwnCloud實例使用SSL，並且可以帶外進行一個安全的憑據分發

peterh - Reinstate Monica
2014-05-23 14:52:40 UTC
view on stackexchange narkive permalink

主要問題是我們通常向簡單的用戶發送密碼，這些用戶無法打開由gpg簽名的郵件。

我們的工作/工資/項目使問題真正惡化了取決於他們的判斷，他們與我們合作的快樂程度。同樣，我們的首要任務是使他們的密碼盡可能簡單。遺憾的是，但是實際上，將下個月發生突破的可能性從0.1％降低到0.01％更為重要。

通常，我會執行以下操作：

  • 我將所有內容（用戶名，其他登錄信息）通過簡單的未加密郵件發送，除了實際密碼，
  • 我將實際密碼稱為“我以短信的形式發送給您”
  • ，同時以短信的形式同時發送了SMS和 only ，沒有任何評論。
Echsecutor
2014-05-23 14:14:11 UTC
view on stackexchange narkive permalink

使用PGP / GPG（以及大多數其他建議的答案），您必須解決身份驗證問題，以防止中間人受到攻擊。 SMS不應被視為已保存，因為GSM加​​密早已被黑客入侵。

我會使用OTR（無法發布更多鏈接，只能使用Google）。

使用某些聊天客戶端，例如 pidgin。然後，您甚至可以使用某些不安全的渠道，例如Facebook，Google聊天，ICQ等，建立加密連接，通過 SMP中的版本進行身份驗證，然後交換機密信息。

如何將OTR密鑰建立為受信任的？
-1
Matthew Peters
2014-05-22 19:02:47 UTC
view on stackexchange narkive permalink

我會使用某種安全的在線門戶，您的遠程用戶可以從中訪問/下載敏感信息。為了使他們能夠訪問門戶，我建議使用臨時密碼（安全密碼）進行兩次身份驗證，使用該密碼必須在使用一次後進行更改（但是，兩次身份驗證可確保即使使用臨時密碼的電子郵件也受到了威脅，仍然是短信別針。）​​

Anti-weakpasswords
2016-02-21 09:04:22 UTC
view on stackexchange narkive permalink

首先，我希望您已經設置了憑據，以便用戶必須在首次登錄時更改它們，以便那些設置它們的人不再知道它們。

如果遠程辦公室有一個受信任的管理員，請向該管理員發送一次加密密鑰集，以使用密鑰/密碼與其他用戶共享，因此您可以要求他們使用密碼＃12進行首次登錄。

取決於您的威脅模型（您是否擔心國家/地區級演員，例如，您是否正在第4國/地區的外國辦事處工作，可能會代表您所在國家/地區的本地競爭對手從事商業間諜活動），這實際上是一個經典案例，其中有人稱呼某人為座機是一個很好的解決方案。

只需在座機上呼叫某人並通過電話告訴他們初始登錄憑據就可以很好地工作。

除此之外，GPG始終是經典的正如許多人回答的那樣。我在Superuser.com上的此答案中有公共密鑰用法以及比默認對稱用法更安全的示例。

取決於您的法規要求， OTR是一種加密通信的方法，特別是IM的通信（例如，請參見 Pidgin），該方法還允許“共享機密”身份驗證；您可以在使用IM時在電話上共享一個易於輸入的密碼，以驗證IM會話中沒有中間人，或者使用他們正在做的某些工作，而這對於其他人來說很難

。如果您已經有了一種發送電子郵件的方式，並且您僅信任收件人並且您自己的網絡/電子郵件管理員可以訪問，並且可以信任某些其他產品/公司，則可以使用“安全電子郵件”服務，例如 Cisco註冊信封服務或備用服務。

尤其是對於SSH密鑰或極長且困難的密碼，可以將它們組合使用；您可以使用安全密碼進行加密（也許使用GPG對稱模式（請參見上面的鏈接）），然後通過電話或其他方法提供該密碼，以便他們可以解密實際的身份驗證令牌/ SSH密鑰/證書/等。 >



ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 3.0許可。
Loading...