最近,我開始作為一家公司的承包商工作,這要求我經常登錄不同的B2B服務。
我接收登錄數據的方式通常是通過電子郵件發送純文本格式。我的直覺告訴我,以純文本格式發送敏感數據不是一個好主意,但是我不確定是否有替代方法,或者它已經受到郵件服務的保護(在這種情況下為gmail)?
我知道最明顯的危險可能是使我的電子郵件帳戶登錄並無人值守,但是我對某種中級攻擊或其他危險的人更感興趣。
我的問題的核心是:
除了通過電子郵件發送密碼外,還有其他選擇嗎?為此使用電子郵件的最大危險是什麼?
最近,我開始作為一家公司的承包商工作,這要求我經常登錄不同的B2B服務。
我接收登錄數據的方式通常是通過電子郵件發送純文本格式。我的直覺告訴我,以純文本格式發送敏感數據不是一個好主意,但是我不確定是否有替代方法,或者它已經受到郵件服務的保護(在這種情況下為gmail)?
我知道最明顯的危險可能是使我的電子郵件帳戶登錄並無人值守,但是我對某種中級攻擊或其他危險的人更感興趣。
我的問題的核心是:
除了通過電子郵件發送密碼外,還有其他選擇嗎?為此使用電子郵件的最大危險是什麼?
我通常使用密碼管理器來存儲和共享密碼。有許多具有此功能的密碼管理器。
密碼是從一個帳戶共享到另一個帳戶,並通過電子郵件將共享通知發送給另一個人,另一個人可以選擇接受,拒絕,或忽略共享。密碼的通信是安全的,而共享的通知則通過不太安全的渠道(如電子郵件)傳播,因此可以利用每種方法的優勢而不會損害安全性。某些產品將允許共享密碼而不將密碼透露給接收器。在這種情況下,可以撤消密碼。
我強烈建議您為所有密碼使用密碼管理器。一些商用的商品包括LastPass,1Password或Dashlane,但如果您不希望信任任何人,也可以自己託管一個。在Google上快速搜索“密碼管理器”應該可以使您走上正確的軌道。
一種常見的做法是通過電子郵件向用戶發送初始密碼,該密碼僅在很短的時間內有效,並且在首次登錄時需要立即進行更改。
這也不完美。具有對用戶電子郵件的讀取權限的攻擊者可以在用戶之前攔截該初始密碼,並代表他們使用該初始密碼。用戶在嘗試使用其初始密碼時會立即註意到。他們將通知管理員密碼錯誤,管理員將進行調查並註意到非法訪問。但是攻擊者已經有一些時間訪問該帳戶,因此可能已經受到了損害。但這比發送永久有效的密碼更好。
它還需要係統支持。因此,這不是普遍適用的做法。
當您不信任電子郵件提供商來保密電子郵件時(您使用的是 gmail,這是一種由數據挖掘提供資金的郵件服務)電子郵件的內容並通過結果獲利),則可以選擇電子郵件加密。有很好的舊版 PGP,更現代的 PEP,IETF標準 S / MIME以及一些非標準化的專有解決方案。關於標準的好處是:有太多選擇!但是它們都有一個共同點:它們只是不流行。讓您的業務合作夥伴以您了解的方案對他們的電子郵件進行加密可能是一場煩人的艱鉅戰鬥。
也許這從字面上看並不適合您的情況,但是通過不完全安全的通道發送敏感數據的一種合理方法是確保需要兩個單獨的因素來訪問該數據並且它們通過不同的渠道發送。例如,我已經看到了通過加密的zip文件通過電子郵件發送數據,並通過SMS發送數據密碼的方法。這樣,無論是擁有該電子郵件的人還是可以訪問您手機的人都無法獲取敏感信息。
以類似的方式,如果您通過電子郵件發送連接信息,則可能是更好的做法。可以通過電話說出密碼(尤其是密碼的話)-但這種選擇主要取決於組織發送的數據(據推測,利益相關者需要對數據進行保密),而不是剛剛收到它的人。
如果您信任它,則會存在 onetimesecret(是開放源代碼)來實現此目的。
當您發送敏感郵件時諸如密碼和通過電子郵件或聊天的私人鏈接之類的信息,這些信息的副本存儲在許多地方。如果您改為使用一次性鏈接,則該信息將保留一次查看,這意味著以後其他人將無法讀取它。這樣一來,您就可以安全地發送敏感信息,知道只有一個人可以看到它。可以將其視為自我毀滅的消息。
鑑於其固有的未加密性質,電子郵件不是共享純文本密碼的好方法。
如果以這種方式共享密碼,則服務應確保首次登錄時更改密碼,以減少暴露(並讓您檢測是否有人使用了被盜的密碼),這不是一個完美的選擇,因為它仍然允許某人利用機會訪問該網站,但總比不知道別人擁有該密碼要好
考慮到您對schroeder的評論的答复,這似乎不是您的選擇,所以我建議您考慮一種機制,該機制可確保客戶和您自己之間的密碼一直加密-電子郵件內容的端到端加密,或者使用經過身份驗證和加密的共享站點,在該站點中可以加密明文密碼。還要考慮一下,如果您真的對知道您密碼的其他人(您的客戶,您的其他團隊成員)感到滿意,那麼這將取決於您所訪問的應用程序的安全要求。
這裡的主要風險是除了您自己之外,還知道密碼的人。在您的情況下,至少是:
如果密碼的唯一目的是避免對B2B服務的未經授權的訪問,並且讓其他知道您密碼的人感到滿意,那麼您可以查看密碼分發的加密方式。儘管許多SMTP服務器實現了用於在郵件服務器躍點之間傳輸數據的加密,但是並不能保證加密,並且固有地電子郵件也沒有被加密,因此密碼至少在每個郵件傳輸(SMTP)躍點的處理期間都將以明文形式存在。
這意味著您需要查看端到端加密,以確保該密碼對於任何監聽的人均不可用,例如PGP,S / MIME或某些其他不對稱加密專有技術。這些將保證密碼在傳輸過程中的機密性,並且您仍然可以使用電子郵件進行分發-付出艱難的設置和運營成本的代價。
您可能會妥協並使用諸如加密的密碼通過安全通道(例如電話)共享的具有預定義加密密碼的ZIP文件或Office文檔,這將減少操作開銷和密碼保護。同樣,帶有密碼並受安全共享秘密保護的雲託管文件也將具有相同的優點/缺點。
我不明白您為什麼要向他們發送密碼?
客戶端設置了他們的首選密碼,您對其進行了哈希處理,存儲了哈希,除了客戶端/他的密碼管理器程序之外,沒有人知道原始密碼(甚至不是您自己的密碼),當他們忘記密碼時,您會向他們發送一個重置鏈接。
但是,如果您真的必須向他發送密碼,我建議您向他發送一個動態生成的鏈接顯示密碼的網頁(僅限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
,您可以執行以下操作
現在,第一個請求此鏈接的人將看到類似
您好,客戶您的密碼是yeheb8cvddt5)注意:我們將從我們的服務器上刪除此密碼,因此您必須記住/保存它。
如果以後有人請求相同的鏈接,他將看到一些信息。像
抱歉,此密碼不存在或之前已被瀏覽過!
此方法的優點是可以通過電子郵件發送密碼:
這種方法的缺點在於,它無法通過電子郵件發送密碼:
之前曾告訴過您,除了客戶端外,沒有人會知道密碼,我從未嘗試過這種方法,但至少比將密碼以純文本格式公開在可以駐留許多計算機/服務器的EMAIL中更好。
我創建了一個小項目,稱為“安全消息服務”,該項目可讓您鍵入消息並生成鏈接以查看該消息。查看該消息後,將從數據庫中刪除該消息。它甚至支持在閱讀消息時發送電子郵件!
鍵入消息並按“發送”,我們的服務器將基於uuidgenerator.net生成GUID,這是基於8個字符的隨機密碼在passwordwolf.com(未存儲在我們的數據庫中)上,並將使用AES-256-CBC加密您的消息。然後,您將收到一個包含GUID和密碼的鏈接,以查看消息(或發送給某人以查看消息),一旦使用該鏈接,消息將不再存在於我們的數據庫中。
您現在可以選擇使用我們的服務,以便在收件人閱讀您的消息時向您發送電子郵件。當您提供電子郵件時,我們會使用與您的秘密消息相同的加密方法(包括相同的密碼)將其插入數據庫之前,先對其進行加密。該密碼短語未存儲在我們的服務器中,而是作為查看消息的鏈接的一部分提供的。
由於發送到我們服務器的所有內容均使用AES-256-CBC加密,並且該密碼短語僅存在於提供的鏈接,這意味著只有您和您發送鏈接的任何人都可以查看消息。如果其他人想查看它,則必須對其進行暴力破解。從理論上講,五十台超級計算機每秒可檢查10億個(1018)AES密鑰(如果可以製造這樣的設備),則理論上將需要3×1051年的時間來耗盡256位密鑰空間。我們已盡最大努力使只有鏈接的人才能看到這些消息,即使該人具有數據庫訪問權限,但我們不做任何保證,也不對使用此服務造成的任何損害負責。
Secure Messaging Service還具有API支持,這意味著您可能會自動生成電子郵件並將其發送給通過鏈接註冊以查看其密碼的用戶。
這是數據的方式如您所見,存儲在數據庫中的消息無法使用表中的信息來恢復消息的內容,因為它需要特殊的口令短語,該口令短語僅附加在創建時提供給您的鏈接上消息,並且不存儲在數據庫中。
首先,這是一種糟糕的情況。聽起來您正在共享用戶帳戶。有時候,沒有別的選擇,但是不應將其與任何特別敏感的東西一起使用,因為當有多個人以相同的名稱登錄時,審核資源的使用會變得更加困難。
如果確實有必要讓多個人使用相同的帳戶,然後應親自提供憑據。
這可能不切實際,因此,您的下一個最佳選擇是通過固定電話發送。 (至少在大多數國家/地區。)固定電話相對較難攔截,並且在大多數國家/地區,電話公司被禁止在沒有法院命令的情況下收聽。政府間諜機構可能正在偵聽,但是如果他們想要您的密碼,它們只會擊敗您,直到您將它們交給為止。第三方更容易攔截和存儲數據,但在他們有足夠的時間破解密鑰之前,他們很難讀取數據。請確保每隔幾年更改一次密碼,並確保每次都不使用相同的套用信函,因為這樣會使破解更加容易。書籍代碼是您的下一個最佳選擇。需要成為每個人都擁有並始終使用的書,所以這可能有些棘手。典型的格式類似於pagenumber-paragraphnumber-wordnumber。將密碼設置為四個或五個單詞,即可正常使用。或根據需要使用每個指定單詞的首字母將其拼寫出來。
如果書籍代碼無法正常工作,那麼只要密碼中不包含任何單詞或類似單詞的結構,則將簡單的替換或換位密碼(例如報紙上的密碼)用於除密碼之外的所有內容即可最堅定的攻擊者。但是密碼必須是隨機字符,否則統計分析將使密碼工作變短,並且您仍然必須通過安全通道來傳遞加密密鑰。顯然,通過這種方法,您僅加密密碼以限制攻擊面,並且最好不要在電子郵件的其餘部分中加擾。關於密碼已加密以及必須通過安全通道進行加密的所有討論。
分佈式開發團隊有一個典型的用例,其中SysOps和TeamMembers為資源(數據庫,服務,服務器)創建憑據,並需要將其與團隊進行通信。如果您將新成員添加到團隊中:
我們使用分佈式密碼管理器。這使我們可以添加新密碼並與個人或團體共享。您將收到類似“ BOFH-1共享密碼'JenkinAdmin'”的電子郵件。您需要登錄以查看將通過https傳遞的真實密碼。
在某些情況下,集中式工具可能會過大,因為它會迫使您進行某些安裝和配置。如果您所有部門都使用它來更新它,那就太好了。只有一個人需要更新密碼管理器中的憑證。我們使用開源工具,但是軟件建議
中對特定程序進行了更好的討論正確無誤,在電子郵件中發送密碼是不安全的。
安全的初始帳戶協議是:
向用戶發送一次使用權限,使超鏈接到期並允許該用戶通過該鏈接設置其初始密碼。然後,可選地驗證用戶已設置第二個因素。然後,可選地以其他方式檢查用戶的身份(視頻通話?)最後,為用戶帳戶提供所需的訪問權限。
我建議使用信號來發送和接收密碼。這是一個端到端的加密聊天應用程序。
信號消息和呼叫始終是端到端加密的,並且經過精心設計,以確保您的通信安全。我們無法閱讀您的消息或看到您的呼叫,其他任何人也無法。
沒有電子郵件是不安全的,因為即使您在郵件服務器上使用SSL,也會有記錄服務器磁盤上的消息,管理員可以讀取。只有PGP / GPG或SMIME加密的電子郵件才是安全的。
有人在我的回答中添加了以下內容。我還沒有聽說過,所以不建議使用。
在Signal之上-可以使用另一種加密的消息交換選項,不需要通過單擊鏈接或提供來確認您的ID電子郵件等。這也是非常重要的多平台。對於Android:對話應用
它可以使用PGP或OMEMO加密-插件可能需要單獨安裝。
還有另一種方法,可能是您所遇到的最佳方法。
它要求您擁有一個具有SSL的網站以及一個網站和嵌入式盒。有人可以在該框中寫郵件,並且在發送後,應使用[即] PGP公鑰加密郵件,該公鑰只能在您的PC電子郵件上自動解密。
請他們改接電話並給您打電話。使用帶外通信可以大大降低竊聽者訪問您的信息的可能性。部分原因是,攻擊者不太可能入侵您的電子郵件系統或電話系統,但是攻擊者同時入侵這兩個系統的可能性很小。如果您可以拆分重要信息(例如電子郵件中的用戶名,電話中的密碼等),那麼相對於您所需的工作量而言,攻擊者就更難了。
如果您的電子郵件是公司預先設置的,那麼解決方案是根本不用密碼(密碼中包含一個沒人知道的長而復雜的字符串)。
然後您要求一項新功能(儘管具有“忘記密碼”功能),它將向您發送一封重置鏈接到您的電子郵件。
良好的通話是一種可靠的嘗試方法。
除此之外,SSH握手是一種很好的方法...
您和接收方都可以生成SSH密鑰。您生成一個密碼並使用密鑰對密碼進行加密。您將加密的密碼發送給客戶端。他們使用其密鑰為您的消息添加了額外的加密。然後,他們將雙重加密的郵件發回給您。您解密此消息,只剩下用收件人的密鑰加密的密碼。您發回此消息。他們使用密碼解密它以獲取密碼。這樣,未加密的數據永遠不會接觸網絡。
OAuth是訪問第三方系統的替代方法,而無需在所述系統中設置密碼驗證,並且無需交換密碼。當然,這將要求系統支持OAuth,但這並非總是如此。
我想到的第一件事是非對稱加密(例如GPG)。這可能在不使事情複雜化的情況下特別有用。
查找或設置公共密鑰服務器,並讓每個人共享其公共密鑰。然後,每當您需要共享對特定收件人敏感的內容時,就可以抓住他的密鑰並加密內容。除了收件人,沒人會知道原始內容。
一個示例電子郵件將變為:
嗨,iBug,
這是您的登錄憑據信息安全堆棧交換。它使用在公司密鑰服務器上找到的密鑰
DEADBEEF
進行了加密。< GPG加密消息>
您可以使用SendPass( https://sendpass.app)
在我看來,發送純文本密碼的兩個最大風險是它們可能駐留在存檔,日誌或仍保留在用戶郵箱中,第二個則是截取密碼,而實際收件人則不知道該密碼(因此不通知管理員)。
為了解決這些風險,我創建了一個免費的應用程序,您可以使用該應用程序發送一次性代碼,收件人可以使用該代碼來檢索密碼。我已經發布了SendPass以幫助其他人,尤其是非技術人員,但是它也可能對您有用。SendPass通過生成唯一的一次性代碼來工作,您可以將其發送給收件人。該密碼只能使用一次,之後密碼將立即被刪除。