題:
通過手機短信發送密碼是否安全?
Rachel
2015-03-12 11:53:26 UTC
view on stackexchange narkive permalink

發送方和接收方都在發送文本後刪除了該文本,但是它仍然可能存在於某處並且有人可以訪問它嗎?

您忘記考慮了最近的智能手機在通知欄上顯示了部分消息。如果用戶借用手機給某人發送SMS / MMS /玩遊戲/等...,他可能會看到它,並且您的安全性已完成。手機上可能還存在一種病毒,該病毒會讀取消息的副本並將其副本發送到另一台服務器。
確保您不要將密碼與身份驗證代碼(例如Google通過短信發送的數字)混淆。驗證碼的壽命很短,必須與單獨的密碼一起使用,並且只能使用一次。如果您(分別)詢問身份驗證代碼,則可能會得到與詢問密碼稍有不同的答案。
您安裝了多少個可以閱讀短信的應用程序?您能保證它們不緩存任何一個嗎?
不給政府。但是,這裡有TextSecure https://play.google.com/store/apps/details?id=org.thoughtcrime.securesms&hl=zh-CN。我還在Google雲端硬盤上創建了一個KeePass數據庫,以與助手安全地共享密碼。當然,主密碼是不安全地發送的:(。
消息可以簡單地記錄在運營商的服務器上。
應當避免任何能夠以純文本形式向您發送密碼的網站,無論使用哪種媒介。密碼應經過哈希處理並添加鹽分。
詢問它是否不安全可能會有所幫助。 :)
“它仍然可能存在於某個地方,並且有人可以到達它嗎?”這不僅可能,而且可以保證。每個人都聽說過使用短信歷史記錄作為騙子證據的刑事案件。這僅是因為保留了短信。
如果輸入的密碼僅有效60秒或類似的時間,我只能真正看到這是安全的。
五 答案:
Jeff Ferland
2015-03-12 12:00:50 UTC
view on stackexchange narkive permalink

這絕對不安全。短信的功能基本上與電子郵件相同:客戶端(電話)將其轉發到服務器,然後服務器查找可能在另一個網絡(運營商)上的目的地,然後將其通過郵箱中的位置進行發送,直到

它可以被複製,保留比預期更長的時間等。合法攔截,非法攔截,克隆的手機,Google +帳戶等都是消息最終可能出乎意料的地方以及所有假定您信任手機和軟件的條件。

清除文字是洩露的文字。總是。

如果文本消息包含驗證碼,並且供應商僅允許其使用一次來執行某些任務,那麼任何截獲該驗證碼的人只有在驗證用戶之前這樣做才能從中受益。如果有人嘗試使用最近使用過的代碼時給出的消息指出了該代碼的使用時間,則該代碼被不當攔截和使用的人會發現該消息,從而可以尋求採取適當的措施。
@supercat是的,但最終仍然是事後緩解。您正在通過使用更安全的通信通道和/或實施其他更強大的安全增強功能來避免/應該避免的安全性損害。
@supercat另外,這裡的問題似乎不是特別關於“一次性代碼”情況。這似乎與個人之間的密碼共享有關。
明文*始終是被洩露的文本,但是請注意,您通過文本消息發送任何類型的安全證書的通常原因是要使它與正在發送的數據“帶外”:即數據正在通過wifi傳輸,但是憑據正在通過單元格。兩者都不是安全的,但是,折衷兩個通信頻帶所需的努力當然不僅僅是一個。
您是說“絕對嗎?不”還是“絕對不是”?
@Iszi:不同的協議適用於不同的威脅模型。據我了解,SMS消息至少可以通過某些鏈接進行傳輸,這意味著某人可以收集一堆,並定期查找有趣的內容。對於信息而言,這可能是一個很大的問題,即對手可能在事後幾天或幾週內使用信息,但對於僅對正在尋找信息的對手(在發送時)有用的信息卻不是那麼多。
如果密碼僅有效60秒怎麼辦?
spoorlezer
2015-03-12 15:56:42 UTC
view on stackexchange narkive permalink

據我所知,通過短信/短信發送密碼最初是用來確保密碼通過與接收密碼的加密文件不同的介質輸入的。

將通過電子郵件發送加密文件,並且用戶將在手機上收到帶有密碼的純文本短信。這將需要竊賊竊取筆記本電腦(或電子郵件收件箱訪問權限)和手機(或訪問手機的短信收件箱)以同時擁有文件和密碼。

當前,智能手機是通常也設置為充當郵箱,這意味著,即使您以短信形式發送,也將在同一設備上同時擁有密鑰和加密消息。如果手機隨後被盜,並且電子郵件仍駐留在可從設備訪問的收件箱中,則僅意味著小偷還必須檢查您大約在同一時間發送的短信,並且如果他發自同一聯繫人,則可能還要檢查密碼

因此,儘管發送純文本密碼從來都不安全,但過去它對我們來說已經足夠好了。但是,既然我們的許多電話也是移動電子郵件收件箱,我們仍在保持這種習慣,這是..我猜是更糟嗎?

它不能防止有人竊取(或破壞)您的智能手機,但可以防止有人破壞用於Internet訪問的WiFi,但不能破壞與電信運營商的連接。
真正。我覺得第一個答案已經解決了這個問題,所以不覺得簡單地重申一下會增加我的答案。
Tim X
2015-03-13 01:48:53 UTC
view on stackexchange narkive permalink

“安全”不是絕對的。考慮事物是安全的還是不安全的是錯誤的。您需要在上下文中評估安全性-誰是用戶,什麼是威脅,受保護的事物的價值是什麼,等等。所有適當的控制措施是什麼?文本消息是僅需要的一點信息,還是只是身份驗證/授權鏈的一部分?

其他答復強調,普通SMS消息與電子郵件非常相似,因為您不了解或控制消息通過的服務器,因此不了解公司,系統管理員等的信譽程度是。您不知道政府監控的級別等。

最近有很多關於兩步身份驗證失敗的新聞,這些新聞使用SMS消息發送必須輸入的附加代碼。實際上,嚴格來講,這並不是嚴格意義上的兩因素身份驗證,而是兩步身份驗證,但這是另一回事了。

這些黑客中常見的“線程”能夠擊敗兩步身份驗證,但這與SMS消息在傳輸過程中被攔截或被盜無關-它實際上要簡單得多,並且使用最簡單,技術含量較低的方法-社會工程。基本上,僅通過聯繫接收者的小區提供商並通過各種社會工程學方法說服它們是合法所有者,就需要繞過這些系統,並且需要將其號碼轉發給新電話(通常是某些刻錄機電話)。一旦完成,SMS消息將被直接重定向到壞人刻錄機電話,傳輸過程的安全與否無關緊要。這就是為什麼,如果您真的很在意,應該選擇不使用SMS的解決方案,而選擇在設備上運行的google authenticator這樣的解決方案。像往常一樣,這都是在方便程度和威脅程度之間取得的平衡。對於許多人來說,SMS可能就足夠了,但對於其他更有可能成為目標的人來說,則風險太大,正如其他人所提到的那樣,SMS消息的目的/類型也很重要-完整的密碼可以提供不需要具有任何其他信息的訪問比具有有限生命週期/用途的一次性令牌要高得多,一次性令牌只是生命週期中需要使用的事物鏈的一部分。

Kevin Peter
2015-03-13 21:31:33 UTC
view on stackexchange narkive permalink

下面是有關GSM短信加密的有趣總結:攔截SMS(兩因素身份驗證)有多難?

據我所知,短信是它們經過空中時被加密。 SIM卡提供用於加密消息的信息,而單元提供者俱有解密消息所需的信息。 (最近發現,美國國家安全局(NSA)入侵了全球90%左右的SIM卡製造商的數據庫,這家荷蘭公司名為Gemalto,並捕獲了解密所有SIM卡文本消息所需的數據

然後服務提供商將他們做的一切事情都完成,以將文本消息發送到預定的目的地,我不知道這是否涉及加密。它與電子郵件的不同之處在於,文本消息通過一個或多個服務提供商的網絡進行傳遞,並且在空中傳播的任何時候都可以被截獲,因此在最脆弱的位置對其進行加密。

文本消息也不同於電子郵件,因為它們不會像電子郵件一樣通過開放的Internet傳播,任何人都可以觀看它。服務提供商和NSA之類的政府組織可以通過在服務提供商的網絡中佔有一席之地輕鬆獲得它,但是您的一般惡意行為者不太可能能夠進入服務提供商的網絡。只要您信任服務提供商(包括您和目的地的服務提供商),您就不會擔心政府機構會使用您的密碼,並且您可以肯定沒有其他人會閱讀接收方的電話,那麼我認為發送一個通過文本輸入密碼不是問題。與電子郵件的傳遞機制大不相同。

使用iPhone和iPad上的iMessage(標准文本應用程序),可以從發送者到接收者一路安全地對郵件進行加密。使用接收者的公共密鑰對消息進行加密,並且只能使用接收者的私有密鑰對消息進行解密。我將注意到,從理論上講,iMessage也可以使用Apple或NSA可以訪問的特殊公共密鑰進行加密,以便它們也可以讀取這些消息,但是只有私有密鑰的持有者才能解密它。蘋果聲稱它沒有做任何這樣的事情,因此,只要您信任蘋果,任何人都無法閱讀這些消息。僅當發送者和接收者都使用Apple產品時,才使用iMessage加密功能。在我看來,發送密碼過於殺傷力。

上述張貼者之一是正確的,因為安全性不是一個是/不是問題。從非常不安全到非常安全的範圍。真正的偏執狂的安全性非常困難,因此您只需要選擇足夠適合您的東西即可。

那就是金雅拓。
讀到一個能真正理解該技術,備份其斷言,而不僅僅是誤解了偏執狂的安全答案,這令人耳目一新。
dtb_pen
2015-03-13 00:48:23 UTC
view on stackexchange narkive permalink

否。

以上答案已將其固定。如果留有藍牙,則有多種方法可以使手機藍調,使手機不受影響。如果有人可以實際使用手機,也可以使用FTK或任何不錯的數字取證工具,通過手機恢復已刪除的文本,照片,數據。



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