題:
替代通過郵件發送密碼?
aMJay
2019-04-03 15:10:38 UTC
view on stackexchange narkive permalink

最近,我開始作為一家公司的承包商工作,這要求我經常登錄不同的B2B服務。

我接收登錄數據的方式通常是通過電子郵件發送純文本格式。我的直覺告訴我,以純文本格式發送敏感數據不是一個好主意,但是我不確定是否有替代方法,或者它已經受到郵件服務的保護(在這種情況下為gmail)?

我知道最明顯的危險可能是使我的電子郵件帳戶登錄並無人值守,但是我對某種中級攻擊或其他危險的人更感興趣。

我的問題的核心是:

除了通過電子郵件發送密碼外,還有其他選擇嗎?為此使用電子郵件的最大危險是什麼?

您可以更改密碼嗎?
從技術上講,@schroeder我可以,但是將來還有其他人可能必須使用這些帳戶,所以我必須將新的帳戶寄回去,所以我想那會錯了
@aMJay用戶帳戶應盡可能個性化。當其他人需要訪問系統時,該人應該擁有自己的帳戶。
他們能否為您提供訪問密碼管理器的權限,並通過密碼管理器與您共享這些憑據?
-1
@aMJay如果需要,我可以將其添加為答案。使用pw mgr的好處是,他們可以控制憑據並可以撤消您的訪問權限。如果憑據僅用於Web應用程序,則LastPass(可能還有其他憑據)可以允許它們與您共享密碼,而您卻無法讀取密碼的純文本版本
保險櫃提供一次性鏈接。您可以通過電子郵件發送該鏈接,如果任何人單擊它,您都會注意到。當然,這只有在快速識別並且密碼是任務唯一的情況下才有效。建立Vault的登錄名後,您還可以使用它來共享密碼。它沒有舒適的密碼共享GUI或PAM / PQ管理器功能,但是如果您只需要安全的密碼下載,就可以了。
分割密碼。通過電子郵件發送其中的一部分,並通過文本發送另一部分。
這是人們在沒有必要知識的情況下設置要求或滾動實施的結果。或者,他們知道問題所在並選擇接受風險。您應該閱讀Peter Gutmann的* [Engineering Security](http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf)*。
這就是密鑰交換的目的。您可以通過電話使用Diffie Hellman(以防止激活MITM)。
標題將更清楚地顯示為“通過電子郵件發送密碼”,而不是“通過郵件發送密碼”
十七 答案:
Kent
2019-04-03 17:04:19 UTC
view on stackexchange narkive permalink

我通常使用密碼管理器來存儲和共享密碼。有許多具有此功能的密碼管理器。

密碼是從一個帳戶共享到另一個帳戶,並通過電子郵件將共享通知發送給另一個人,另一個人可以選擇接受,拒絕,或忽略共享。密碼的通信是安全的,而共享的通知則通過不太安全的渠道(如電子郵件)傳播,因此可以利用每種方法的優勢而不會損害安全性。某些產品將允許共享密碼而不將密碼透露給接收器。在這種情況下,可以撤消密碼。

我強烈建議您為所有密碼使用密碼管理器。一些商用的商品包括LastPass,1Password或Dashlane,但如果您不希望信任任何人,也可以自己託管一個。在Google上快速搜索“密碼管理器”應該可以使您走上正確的軌道。

肯特,歡迎您訪問該網站!有時添加內容可能會很棘手:您嘗試幫助您使用自己的體驗,但隨後人們抱怨說這聽起來像是廣告。感謝您堅持使用它,並根據評論更新您的答案!我希望你留在網站上:)
為了完整起見,我看到[Dashlane](https://www.dashlane.com)也廣泛用於帶有或不帶有密碼洩露(可能會撤消訪問)的訪問共享。
是的,這是“正確”的答案。在我的雇主處,我們使用帶有Web前端的內部託管企業管理解決方案,當我們需要共享密碼時,我們會發送一封電子郵件,其中包含指向該秘密的鏈接。(基本上-https:// [ourpasswordmanagentserver.ourdomain.com] /SecretView.aspx?secretid= [######])
您不能共享密碼而不公開密碼。當然,您可以共享它而不顯示它,但是共享它的人仍然可以在其他地方看到該密碼,無論是在將密碼字段更改為文本字段還是從網絡上將其抬起的頁面上,都可以看到該密碼。發送登錄請求後,登錄他們的瀏覽器。任何聲稱否則不被信任的密碼管理器。
Philipp
2019-04-03 16:13:57 UTC
view on stackexchange narkive permalink

一種常見的做法是通過電子郵件向用戶發送初始密碼,該密碼僅在很短的時間內有效,並且在首次登錄時需要立即進行更改。

這也不完美。具有對用戶電子郵件的讀取權限的攻擊者可以在用戶之前攔截該初始密碼,並代表他們使用該初始密碼。用戶在嘗試使用其初始密碼時會立即註意到。他們將通知管理員密碼錯誤,管理員將進行調查並註意到非法訪問。但是攻擊者已經有一些時間訪問該帳戶,因此可能已經受到了損害。但這比發送永久有效的密碼更好。

它還需要係統支持。因此,這不是普遍適用的做法。

當您不信任電子郵件提供商來保密電子郵件時(您使用的是 gmail,這是一種由數據挖掘提供資金的郵件服務)電子郵件的內容並通過結果獲利),則可以選擇電子郵件加密。有很好的舊版 PGP,更現代的 PEP,IETF標準 S / MIME以及一些非標準化的專有解決方案。關於標準的好處是:有太多選擇!但是它們都有一個共同點:它們只是不流行。讓您的業務合作夥伴以您了解的方案對他們的電子郵件進行加密可能是一場煩人的艱鉅戰鬥。

幾乎每個人都可以訪問的一個“標準”是加密的zip文件。不是最強的保護,而是比純文本更好的保護。通過我們以前在大學裡知道的那個醉漢的不同頻道,文本,語音郵件,姓氏發送密碼。
或發送帶有密碼的廢紙圖片。顯然,如果您明確地成為目標,那麼這無關緊要,但是,如果您擔心被動挖礦,那麼它將為處理增加足夠的延遲,以便您的限時密碼在洩露之前會過期。
您可能要注意,OpenPGP也是IETF標準([RFC4880](https://tools.ietf.org/html/rfc4880))
可能需要補充一點的是,啟用兩因素/多因素身份驗證(如果可用)可以減輕某些初始或最近重置的密碼被攔截的風險。
如果可以控制/更改系統,則在初始OTP上添加“僅允許來自受信任IP的此操作”策略,可以對系統進行很大的改進(將攻擊範圍限制在本地網絡中)。無論如何,完全同意PGP等人的用法。
加密電子郵件是您可能遇到的最糟糕的經歷之一。整個過程仍然讓人感覺不上90年代(特別有趣,因為其中一些標準是較新的)。
@Voo取決於。在我的工作中,我們有一個Microsoft Outlook插件,該插件可以加密電子郵件,而無需用戶執行任何操作。但這當然需要接收器也安裝了插件。
@Philipp並確保有適當的基礎設施來確保接收器已經擁有您的鑰匙。有趣的地方始於此。哦,您顯然仍然必須能夠向大多數其他人發送未加密的電子郵件,因此必須有一些白名單。到目前為止,一切都很好,但是如果您發送電子郵件給“已加密”列表中的人,而不發給其他人,該怎麼辦呢?等等等等。不好玩,但請確保用戶只有在它不起作用時才會注意到它。
@Neil_UK或KeepassDB,您可以通過電話或其他方式將密碼提供給數據庫。
您是否曾經嘗試通過Gmail附加加密的.zip文件?它不會被接受;IOW,*這是不可能*。我試過一次,IIRC發送一個.exe文件,Gmail不允許。
@MikeWaters有時您可以通過_removing_文件擴展名來誘騙過濾器,然後在電子郵件的正文中要求用戶在下載文件後重新添加正確的擴展名(這是您在電子郵件正文中指定的)。
Peteris
2019-04-03 16:20:28 UTC
view on stackexchange narkive permalink

兩個因素

也許這從字面上看並不適合您的情況,但是通過不完全安全的通道發送敏感數據的一種合理方法是確保需要兩個單獨的因素來訪問該數據並且它們通過不同的渠道發送。例如,我已經看到了通過加密的zip文件通過電子郵件發送數據,並通過SMS發送數據密碼的方法。這樣,無論是擁有該電子郵件的人還是可以訪問您手機的人都無法獲取敏感信息。

以類似的方式,如果您通過電子郵件發送連接信息,則可能是更好的做法。可以通過電話說出密碼(尤其是密碼的話)-但這種選擇主要取決於組織發送的數據(據推測,利益相關者需要對數據進行保密),而不是剛剛收到它的人。

此IMO是發送數據進行身份驗證的正確方法:使用兩個單獨的通道。但是,我想添加一個重要說明:發送者和接收者都應盡快刪除數據,方法是刪除電子郵件,SMS或whatsapp消息等。此外,我認為whatsapp消息可能比SMS更好。您(和另一方)只需要記住在密碼安全地存儲在其他地方後刪除該消息。
@reed如果通過兩個通道接收的密鑰是一次性的,並且在使用它們後提示用戶立即輸入用戶生成的密碼,則無需刪除消息。
這是我通常這樣做的方式。而且我確保不要在承載密碼的文本中提及主機或登錄。請注意,這也是鼓勵人們使用信號的好時機,因此文本本身已加密
假設雙方都安裝了Signal,Signal可能是向某人的手機發送消息的最安全的方法。
user137369
2019-04-03 19:32:27 UTC
view on stackexchange narkive permalink

如果您信任它,則會存在 onetimesecret是開放源代碼)來實現此目的。

當您發送敏感郵件時諸如密碼和通過電子郵件或聊天的私人鏈接之類的信息,這些信息的副本存儲在許多地方。如果您改為使用一次性鏈接,則該信息將保留一次查看,這意味著以後其他人將無法讀取它。這樣一來,您就可以安全地發送敏感信息,知道只有一個人可以看到它。可以將其視為自我毀滅的消息。

創建自己的onetimesecret系統非常簡單。幾年前,我在大約十二行perl中編寫了PoC。存儲秘密(文本)會生成可以安全郵寄的URL。 該URL只能被打開一次,此後該機密將被覆蓋然後刪除。如果您嘗試再次打開它,則會導致出現類似404的錯誤消息,該錯誤消息還會通知訪問者,如果他是第一次訪問該URL,則表示其他人之前也曾看到過該消息,最像是通過截獲鏈接。
llmora
2019-04-03 16:20:02 UTC
view on stackexchange narkive permalink

鑑於其固有的未加密性質,電子郵件不是共享純文本密碼的好方法。

如果以這種方式共享密碼,則服務應確保首次登錄時更改密碼,以減少暴露(並讓您檢測是否有人使用了被盜的密碼),這不是一個完美的選擇,因為它仍然允許某人利用機會訪問該網站,但總比不知道別人擁有該密碼要好

考慮到您對schroeder的評論的答复,這似乎不是您的選擇,所以我建議您考慮一種機制,該機制可確保客戶和您自己之間的密碼一直加密-電子郵件內容的端到端加密,或者使用經過身份驗證和加密的共享站點,在該站點中可以加密明文密碼。還要考慮一下,如果您真的對知道您密碼的其他人(您的客戶,您的其他團隊成員)感到滿意,那麼這將取決於您所訪問的應用程序的安全要求。

這裡的主要風險是除了您自己之外,還知道密碼的人。在您的情況下,至少是:

  • 您的客戶組織中生成密碼並將其通過電子郵件發送給您的人
  • 任何管理電子郵件的人客戶和您自己之間的基礎結構
  • 在您和您自己之間的任何電子郵件路徑中具有網絡訪問權限的任何人
  • 其他使用相同帳戶和密碼的團隊成員(從您對schroeder的評論的回復中推斷出)
  • 任何可能訪問您的郵箱的人(例如,您對不留意電子郵件客戶端的評論)

如果密碼的唯一目的是避免對B2B服務的未經授權的訪問,並且讓其他知道您密碼的人感到滿意,那麼您可以查看密碼分發的加密方式。儘管許多SMTP服務器實現了用於在郵件服務器躍點之間傳輸數據的加密,但是並不能保證加密,並且固有地電子郵件也沒有被加密,因此密碼至少在每個郵件傳輸(SMTP)躍點的處理期間都將以明文形式存在。

這意味著您需要查看端到端加密,以確保該密碼對於任何監聽的人均不可用,例如PGP,S / MIME或某些其他不對稱加密專有技術。這些將保證密碼在傳輸過程中的機密性,並且您仍然可以使用電子郵件進行分發-付出艱難的設置和運營成本的代價。

您可能會妥協並使用諸如加密的密碼通過安全通道(例如電話)共享的具有預定義加密密碼的ZIP文件或Office文檔,這將減少操作開銷和密碼保護。同樣,帶有密碼並受安全共享秘密保護的雲託管文件也將具有相同的優點/缺點。

AccountantM
2019-04-03 20:40:10 UTC
view on stackexchange narkive permalink

我不明白您為什麼要向他們發送密碼?

客戶端設置了他們的首選密碼,您對其進行了哈希處理,存儲了哈希,除了客戶端/他的密碼管理器程序之外,沒有人知道原始密碼(甚至不是您自己的密碼),當他們忘記密碼時,您會向他們發送一個重置鏈接。

但是,如果您真的必須向他發送密碼,我建議您向他發送一個動態生成的鏈接顯示密碼的網頁(僅限1次)。

您需要在數據庫中臨時存儲類似的內容

  emailTocken char(32)密碼varchar +- -------------------------------- + ----------------- -+ | emailTocken |密碼| + ---------------------------------- + -------------- ---- + | 202CB962AC59075B964B07152D234B70 | jhds7ytht_id | | CF297E613A7F7892A3BF348EE526ABAD | hdhdbdue874#| | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yeheb8cvddt5)| | 2510C39011C5BE704182423E3A695E91 | 6#hdyd98_jee | | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yhrtxbxv48_e | + ---------------------------------- + -------------- ---- +  

並向他發送一封電子郵件,您隻公開emailTocken而不顯示密碼

 您好,客戶請點擊此鏈接查看您的當有人請求此鏈接時,在Web服務器上輸入密碼https://example.com/showPassword?emailTocken=8F14E45FCEEA167A5A36DEDD4BEA2543  

,您可以執行以下操作

  1. 選擇密碼提供了emailTocken的電子郵件
  2. 從數據庫中刪除它的記錄
  3. ol>

    現在,第一個請求此鏈接的人將看到類似

     您好,客戶您的密碼是yeheb8cvddt5)注意:我們將從我們的服務器上刪除此密碼,因此您必須記住/保存它。 

    如果以後有人請求相同的鏈接,他將看到一些信息。像

     抱歉,此密碼不存在或之前已被瀏覽過! 

    此方法的優點是可以通過電子郵件發送密碼:

    1. 第一個查看者僅可以看到一次密碼,以後查看該電子郵件的人則只能看到一次
    2. 如果其他人首先查看了該密碼(中間人),則合法用戶將無法看到該密碼並尋求幫助,這將使我們知道存在發生了一些錯誤,比別人看到的要好,我們甚至都不知道。 我希望您的電子郵件代理程序出於任何原因都不會自動請求此請求:(
    3. ol>

      這種​​方法的缺點在於,它無法通過電子郵件發送密碼:

      1. 需要Web服務器
      2. 需要更多的工作,而不僅僅是輕鬆地通過電子郵件發送密碼
      3. ol>

        之前曾告訴過您,除了客戶端外,沒有人會知道密碼,我從未嘗試過這種方法,但至少比將密碼以純文本格式公開在可以駐留許多計算機/服務器的EMAIL中更好。

我之前曾考慮過這種解決方案,但是眾所周知,我(即普通程序員)在99.91%的情況下建議不要定制與安全性相關的工具。因此,我總是問自己:**如果這真的是一個好主意,那麼經過驗證的,經過驗證的開源工具到底在哪裡呢?**
-1
@s1lv3r檢查[this answer](https://security.stackexchange.com/a/206724/149722),他實際上是這樣做的。還有[this](https://security.stackexchange.com/a/206709/149722)
這是在自定義系統中實現密碼的合理方法,但我的印像是,OP詢問與他們合作的公司正在為其使用的各種第三方軟件和服務生成密碼的情況。
@XiongChiamiov是的,我明白。與其生成密碼並通過電子郵件將其發送給所有者,不如生成密碼並將其保存在數據庫中並發送鏈接。
GrumpyCrouton
2019-04-03 21:08:14 UTC
view on stackexchange narkive permalink

我創建了一個小項目,稱為“安全消息服務”,該項目可讓您鍵入消息並生成鏈接以查看該消息。查看該消息後,將從數據庫中刪除該消息。它甚至支持在閱讀消息時發送電子郵件!

鍵入消息並按“發送”,我們的服務器將基於uuidgenerator.net生成GUID,這是基於8個字符的隨機密碼在passwordwolf.com(未存儲在我們的數據庫中)上,並將使用AES-256-CBC加密您的消息。然後,您將收到一個包含GUID和密碼的鏈接,以查看消息(或發送給某人以查看消息),一旦使用該鏈接,消息將不再存在於我們的數據庫中。

您現在可以選擇使用我們的服務,以便在收件人閱讀您的消息時向您發送電子郵件。當您提供電子郵件時,我們會使用與您的秘密消息相同的加密方法(包括相同的密碼)將其插入數據庫之前,先對其進行加密。該密碼短語未存儲在我們的服務器中,而是作為查看消息的鏈接的一部分提供的。

由於發送到我們服務器的所有內容均使用AES-256-CBC加密,並且該密碼短語僅存在於提供的鏈接,這意味著只有您和您發送鏈接的任何人都可以查看消息。如果其他人想查看它,則必須對其進行暴力破解。從理論上講,五十台超級計算機每秒可檢查10億個(1018)AES密鑰(如果可以製造這樣的設備),則理論上將需要3×1051年的時間來耗盡256位密鑰空間。我們已盡最大努力使只有鏈接的人才能看到這些消息,即使該人具有數據庫訪問權限,但我們不做任何保證,也不對使用此服務造成的任何損害負責。

Secure Messaging Service還具有API支持,這意味著您可能會自動生成電子郵件並將其發送給通過鏈接註冊以查看其密碼的用戶。


這是數據的方式如您所見,存儲在數據庫中的消息無法使用表中的信息來恢復消息的內容,因為它需要特殊的口令短語,該口令短語僅附加在創建時提供給您的鏈接上消息,並且不存儲在數據庫中。

enter image description here

美觀,簡單且友好的UI,這就是我的答案,我會在需要時為您的服務添加書籤以供使用,謝謝。
@Accountant讓我知道,您是否可以想到其他功能或發現任何錯誤。很高興你喜歡!:)(由於您名字中的符號,它不會讓我直接@您)
我建議您獲取實際的秘密消息,並在用戶將鼠標懸停/單擊此框時(通過AJAX請求)將其刪除,以防止密碼被電子郵件代理或WhatsApp,Facebook機器人發出的自動請求刪除*將鏈接發送給我在whatsapp或facebook中的朋友,這些程序bot會自動發出請求,這將導致機密被刪除)*。除此之外,這非常好
@Accountant好主意,我一定會考慮添加的。
對於某些人來說這可能是有用的服務,但是為什麼我們應該信任您?
@aCVn確實令人擔憂,但是為什麼我們應該信任我們的操作系統製造商,網絡託管公司,日常計劃?**法**。除此之外,僅需一點用戶協議就足夠了,我們在技術上是否信任甚至知道我們每天使用的每一行代碼?我信任他的另一個原因是,這是一項不需要註冊的簡便服務,這使他不知道我是誰或向誰發送密碼的人,甚至也不知道該密碼是什麼,在哪裡可以用?**他只是為用戶看到秘密,除了對IP /瀏覽器用戶代理的了解之外,他對他們一無所知。**
@aCVn很簡單,如果您不信任該服務,請不要使用它。還有其他一些服務可以執行類似的操作。我已經在About頁面中詳細說明了它的工作方式,存儲的內容,這就是我真正要做的,就是試圖向可以信任該服務的人們證明。考慮到該服務是匿名的,我也看不出通過撒謊可以得到什麼。
@aCVn我添加了一個圖像,該圖像顯示瞭如何將所有內容存儲在數據庫中。如果有一天我不再懶惰,我什至可以考慮將代碼上傳到github
@AccountantM不知道您是否仍然對該項目感興趣,或者甚至還記得它(即使我仍在託管它,我也忘記了它),但是有人在這裡贊成我的回答,使我想起了這個項目。事實證明,在最近幾個月中它已經有了一些用途,而我什至不知道。今天花了一些時間完全重寫它。查看我所做的更改!
@GrumpyCrouton您好,是的,我還記得您的項目,它仍然保存在我的書籤站點中,但是我還沒有使用它。恭喜外觀有了新的變化(看起來更好),我還沒有檢查網絡流量,但是今晚我將對其進行更深入的介紹。
@AccountantM太棒了。我正在考慮實現某種方式以使人們“回复”他們發送的消息(如果發件人輸入了電子郵件,但沒有實際向發件人顯示發件人的電子郵件),類似於“聯繫我們”頁面的工作方式。我的另一個想法是允許發件人設置一個額外的密碼,收件人必須在透露密碼之前手動輸入該密碼。讓我知道你的想法!
Perkins
2019-04-04 00:07:15 UTC
view on stackexchange narkive permalink

首先,這是一種糟糕的情況。聽起來您正在共享用戶帳戶。有時候,沒有別的選擇,但是不應將其與任何特別敏感的東西一起使用,因為當有多個人以相同的名稱登錄時,審核資源的使用會變得更加困難。

如果確實有必要讓多個人使用相同的帳戶,然後應親自提供憑據。

這可能不切實際,因此,您的下一個最佳選擇是通過固定電話發送。 (至少在大多數國家/地區。)固定電話相對較難攔截,並且在大多數國家/地區,電話公司被禁止在沒有法院命令的情況下收聽。政府間諜機構可能正在偵聽,但是如果他們想要您的密碼,它們只會擊敗您,直到您將它們交給為止。第三方更容易攔截和存儲數據,但在他們有足夠的時間破解密鑰之前,他們很難讀取數據。請確保每隔幾年更改一次密碼,並確保每次都不使用相同的套用信函,因為這樣會使破解更加容易。書籍代碼是您的下一個最佳選擇。需要成為每個人都擁有並始終使用的書,所以這可能有些棘手。典型的格式類似於pagenumber-paragraphnumber-wordnumber。將密碼設置為四個或五個單詞,即可正常使用。或根據需要使用每個指定單詞的首字母將其拼寫出來。

如果書籍代碼無法正常工作,那麼只要密碼中不包含任何單詞或類似單詞的結構,則將簡單的替換或換位密碼(例如報紙上的密碼)用於除密碼之外的所有內容即可最堅定的攻擊者。但是密碼必須是隨機字符,否則統計分析將使密碼工作變短,並且您仍然必須通過安全通道來傳遞加密密鑰。顯然,通過這種方法,您僅加密密碼以限制攻擊面,並且最好不要在電子郵件的其餘部分中加擾。關於密碼已加密以及必須通過安全通道進行加密的所有討論。

borjab
2019-04-04 01:13:19 UTC
view on stackexchange narkive permalink

分佈式開發團隊有一個典型的用例,其中SysOps和TeamMembers為資源(數據庫,服務,服務器)創建憑據,並需要將其與團隊進行通信。如果您將新成員添加到團隊中:

  • 您不能僅對密碼進行哈希處理。
  • 您不能只重置密碼,否則它將在團隊的其餘部分停止工作。

我們使用分佈式密碼管理器。這使我們可以添加新密碼並與個人或團體共享。您將收到類似“ BOFH-1共享密碼'JenkinAdmin'”的電子郵件。您需要登錄以查看將通過https傳遞的真實密碼。

在某些情況下,集中式工具可能會過大,因為它會迫使您進行某些安裝和配置。如果您所有部門都使用它來更新它,那就太好了。只有一個人需要更新密碼管理器中的憑證。我們使用開源工具,但是軟件建議

中對特定程序進行了更好的討論
更通用的密碼管理器答案已經涵蓋了這一點。請不要發布特定產品的廣告。
@schroeder我已經刪除了對解決方案的引用,即使它是開源的。
Douglas Held
2019-04-04 02:03:47 UTC
view on stackexchange narkive permalink

正確無誤,在電子郵件中發送密碼是不安全的。

安全的初始帳戶協議是:

向用戶發送一次使用權限,使超鏈接到期並允許該用戶通過該鏈接設置其初始密碼。然後,可選地驗證用戶已設置第二個因素。然後,可選地以其他方式檢查用戶的身份(視頻通話?)最後,為用戶帳戶提供所需的訪問權限。

Chloe
2019-04-04 02:20:27 UTC
view on stackexchange narkive permalink

我建議使用信號來發送和接收密碼。這是一個端到端的加密聊天應用程序。

信號消息和呼叫始終是端到端加密的,並且經過精心設計,以確保您的通信安全。我們無法閱讀您的消息或看到您的呼叫,其他任何人也無法。

沒有電子郵件是不安全的,因為即使您在郵件服務器上使用SSL,也會有記錄服務器磁盤上的消息,管理員可以讀取。只有PGP / GPG或SMIME加密的電子郵件才是安全的。


有人在我的回答中添加了以下內容。我還沒有聽說過,所以不建議使用。


在Signal之上-可以使用另一種加密的消息交換選項,不需要通過單擊鏈接或提供來確認您的ID電子郵件等。這也是非常重要的多平台。對於Android:對話應用

  1. 對於Linux和Windows:Gajim應用
  2. ol>

    它可以使用PGP或OMEMO加密-插件可能需要單獨安裝。

    還有另一種方法,可能是您所遇到的最佳方法。

    它要求您擁有一個具有SSL的網站以及一個網站和嵌入式盒。有人可以在該框中寫郵件,並且在發送後,應使用[即] PGP公鑰加密郵件,該公鑰只能在您的PC電子郵件上自動解密。

@Over-heads您是否由於答案被刪減/刪除而被禁止回答?如果是,您還記得嗎?1)您寫了多少個答案?2)您看到其中有多少人被否決了(左上角的數字為負)?|順便說一句,也許您可以在2週內再次發布。
@Over-heads在這裡,您將看到已刪除答案的列表。那裡有多少個答案,其中有多少個分數為負?https://security.stackexchange.com/users/recently-deleted-answers/203877
Monica Apologists Get Out
2019-04-04 17:54:07 UTC
view on stackexchange narkive permalink

請他們改接電話並給您打電話。使用帶外通信可以大大降低竊聽者訪問您的信息的可能性。部分原因是,攻擊者不太可能入侵您的電子郵件系統或電話系統,但是攻擊者同時入侵這兩個系統的可能性很小。如果您可以拆分重要信息(例如電子郵件中的用戶名,電話中的密碼等),那麼相對於您所需的工作量而言,攻擊者就更難了。

是的,當與另一方技術上不太熟練的人無法像GPG這樣的事情打交道時,我已經多次使用“通過電話讀取臨時密碼”。煩人,但實用。
WoJ
2019-04-03 20:33:38 UTC
view on stackexchange narkive permalink

如果您的電子郵件是公司預先設置的,那麼解決方案是根本不用密碼(密碼中包含一個沒人知道的長而復雜的字符串)。

然後您要求一項新功能(儘管具有“忘記密碼”功能),它將向您發送一封重置鏈接到您的電子郵件。

問題的評論中涵蓋了這一點
bremen_matt
2019-04-04 10:31:48 UTC
view on stackexchange narkive permalink

良好的通話是一種可靠的嘗試方法。

除此之外,SSH握手是一種很好的方法...

您和接收方都可以生成SSH密鑰。您生成一個密碼並使用密鑰對密碼進行加密。您將加密的密碼發送給客戶端。他們使用其密鑰為您的消息添加了額外的加密。然後,他們將雙重加密的郵件發回給您。您解密此消息,只剩下用收件人的密鑰加密的密碼。您發回此消息。他們使用密碼解密它以獲取密碼。這樣,未加密的數據永遠不會接觸網絡。

當您只能使用PGP(實際上用於此類操作)時,為什麼要這樣做呢?
n0rd
2019-04-04 09:46:36 UTC
view on stackexchange narkive permalink

OAuth是訪問第三方系統的替代方法,而無需在所述系統中設置密碼驗證,並且無需交換密碼。當然,這將要求系統支持OAuth,但這並非總是如此。

這不能回答問題
您能詳細說明一下@schroeder,嗎?
我的意思是,“ OAuth”如何不能解決“通過電子郵件發送密碼...”的替代方案?(假設僅“是”是不夠的)
這是完全不需要發送密碼的替代方法。這是問題的重製。這意味著需要傳達密碼。
替代品正是這個問題的實質。沒有前提條件是不能選擇OAuth。我處理過的許多B2B應用程序都支持它,但是使用它的人通常會忽略該功能。
但是,與我一起使用的應用程序集肯定存在偏差,因為這些應用程序主要託管在Azure中並支持Azure AD。
iBug
2019-04-05 20:47:43 UTC
view on stackexchange narkive permalink

我想到的第一件事是非對稱加密(例如GPG)。這可能在不使事情複雜化的情況下特別有用。

查找或設置公共密鑰服務器,並讓每個人共享其公共密鑰。然後,每當您需要共享對特定收件人敏感的內容時,就可以抓住他的密鑰並加密內容。除了收件人,沒人會知道原始內容。

一個示例電子郵件將變為:

嗨,iBug,

這是您的登錄憑據信息安全堆棧交換。它使用在公司密鑰服務器上找到的密鑰 DEADBEEF 進行了加密。

  < GPG加密消息>  
已經被其他答案覆蓋
Toine-L
2019-09-26 22:40:59 UTC
view on stackexchange narkive permalink

您可以使用SendPass( https://sendpass.app

在我看來,發送純文本密碼的兩個最大風險是它們可能駐留在存檔,日誌或仍保留在用戶郵箱中,第二個則是截取密碼,而實際收件人則不知道該密碼(因此不通知管理員)。

為了解決這些風險,我創建了一個免費的應用程序,您可以使用該應用程序發送一次性代碼,收件人可以使用該代碼來檢索密碼。我已經發布了SendPass以幫助其他人,尤其是非技術人員,但是它也可能對您有用。SendPass通過生成唯一的一次性代碼來工作,您可以將其發送給收件人。該密碼只能使用一次,之後密碼將立即被刪除。



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