題:
為什麼我們仍然可以在Ruby的12行中破解帶照片的照片?
Dmitri DB
2014-03-03 14:53:16 UTC
view on stackexchange narkive permalink

只是碰到了這种红寶石,可以用來解密從手機緩存中取出的Snapchat照片,顯然是從此處改編而成的。令我驚訝的是,考慮到Snapchat的安全性問題最近已經得到了很好的宣傳(我記得大多數情況下,整個電話號碼/用戶名洩露的問題),它的工作沒有問題。

 需要'openssl'ARGV.each do | a,index |數據= File.open(a,'r:ASCII-8BIT')。read c = OpenSSL :: Cipher.new('AES-128-ECB')c.decrypt c.key ='M02cnQ51Ji97vwT4'o =''。 force_encoding('ASCII-8BIT')data.bytes.each_slice(16){| s | o + = c.update(s.map(&:chr).join)} o + = c.final File.open('decyphered_'+ a,'w'){| f | f.write(o)}結束 

所以,我的問題是,他們在這裡到底在做什麼錯,為了提高應用程序的安全性,他們會做得更好嗎?考慮到人們經常向一個人發送絕不會被分享超過10秒的私密事物,並且考慮到此應用的受歡迎程度,而不是現在正在做什麼?

tldr //對於那些真的不太想知道計算機的工作原理但仍然想知道怎麼回事的人:基本上,假設您有 4000萬人使用Snapchat,有1,650萬用戶彼此發送圖片,並且每張圖片每天都在自己的小鎖保險箱中。現在,如果您給這1,650萬人以相同的脆弱塑料鑰匙來打開這些密碼箱中的每一個以捕獲Snapchat媒體呢?

2012年12月:https://twitter.com/adamcaudill/status/285300559269994497
@DmitriDB-您對保險櫃的介紹,其中每個人都有可以打開“每個密碼箱”的塑料鑰匙,這意味著您正在談論一種侵入所有人的Snapchat照片的方法。但是您顯示的代碼取決於從實際的單個電話中獲取數據,不是嗎?
@nnnnnn在我為外行人做的精簡說明中的“鑰匙”指的是“微型鎖定的保險箱”,該保險箱被發送到每個裝有媒體的電話。有些笨蛋把它自己“清理”了下來的定義,並加上了一些爛透了的語法,所以我真的不確定它是否像以前那樣這麼清晰了……但是不,那絕對不是它的意思。
清理評論,刪除肥皂盒,在此處恢復為實際的主題問題。
九 答案:
kiBytes
2014-03-03 15:18:23 UTC
view on stackexchange narkive permalink

這是密碼管理中的一個嚴重問題。這裡的第一個問題是他們在源代碼中管理密鑰的方式。 SnapChat聲明他們通過互聯網發送加密的照片,這畢竟是對的,但是他們使用“預共享”密鑰對該數據進行加密(在ECB模式下也使用AES) ,地球上的每個用戶都有解密每張照片的鑰匙。

這裡的問題是,互聯網是如何獲得密鑰的?小菜一碟,他們只是將其包含在每個應用程序中,而有人只是在搜索它

任何和所有Snapchat應用程序都使用此魔術加密密鑰是什麼?

M02cnQ51Ji97vwT4

您可以在com.snapchat.android.util.AESEncrypt中位於
的常量字符串中找到該字符(在Android應用程序中);無需挖掘,
從字面上看它正圍坐在等待被任何人發現的地方。

(也許)更積極的一點是,在Android應用程序的3.0.4(18/08/2013)構建版
中,有第二個鍵-奇怪的是!

1234567891123456

在源中硬編碼密碼(無論是在標題中還是在二進製文件中)都是非常糟糕的做法,這是主要問題成為任何人都可以通過簡單的“字符串”命令將其放入二進製文件中(或通過在以前與朋友共享代碼的地方查看):

 字符串binaryFile  

然後,惡意用戶可以查看每個字符串,並檢查是否這是他要查找的密碼。因此,如果您確實需要在代碼中對密碼進行硬編碼,則最好將其隱藏,但這只是“ 通過默默無聞的安全性”,惡意用戶最終會找到密鑰(因此,您最好考慮一下以另一種方式)。

他們可以採取哪些措施來提高安全性?好吧,他們可以為每張照片生成一個密鑰,或者可以在要共享照片的客戶端之間預共享一個密鑰,即公共/私有密鑰;有很多選擇。

最大的問題是他們的目標無法解決-阻止設備所有者保存圖片。即使對於DRM方案,這仍然相當薄弱。更加精細的密鑰管理可以稍微改善情況,但不會太大。您仍然可以拍攝屏幕快照或掛鉤API,通過該API渲染解密的圖像。
好吧,至少在使用屏幕截圖時,它們往往會在捕獲通知時被捕獲……至少在使用任何常規方法(按手機上的三個按鈕或不按此按鈕)進行捕獲時。但是,是的,我所能做的就是同意,這是很薄弱的事情!
我有個問題。如果需要在源代碼中輸入密碼,該如何確保密碼的安全?這純粹是一個示例,但是假設有一個正在使用API​​的應用程序,並且您不想公開您的API密鑰,但由於已使用它,因此需要將其包含在源代碼中。如何有效地使用用戶無法檢索的字符串。如果不向服務器詢問字符串,這似乎是不可能的。
@Fogest本身就是一個問題。
@SQB我同意,這是一個不同的問題。
我的意思是,這是一個有趣的問題。我希望@Fogest希望將其從評論提升為問題。
嘿!你可以自己做!
好問題-http://security.stackexchange.com/questions/52693/how-can-one-secure-a-password-key-in-source-code
您甚至都不需要截屏。由於您可以親眼看到,因此請使用其他手機,網絡攝像頭,VCR便攜式攝像機等保存圖片。該應用無法阻止這種情況。
哎呀,如果他們完全刪除了下載的圖像,則可以消除此漏洞。不會阻止模擬漏洞,但如果應用程序只是將其加密存儲在內存中,則您將必須啟動設備並在後台運行另一台設備,以將與手套有關的任何內容從內存中提取出來。
@CodesInChaos我不認為這是他們的目標。他們知道您可以使用外接相機拍照。那不是重點。關鍵是您可以向您的朋友發送在Facebook等網站上永遠不會出現的快速照片。您可以快速,輕鬆地與選定的一組朋友共享內容。您沒有發送核發射代碼。您正在發送一張有趣的小圖片。老實說,我認為他們做得足夠。如果您想保留我在大便時拍攝的自拍照,那就去吧。
@0A0D&basher好吧,這是我的問題,您對人們如何使用該應用程序的觀點以及您似乎在我的帖子中錯過的某些內容–人們正在使用它來發送“私密”照片。孩子,誰都不知道,等等。這些孩子在整個互聯網上流失了,現在我們有女孩成為無心色情明星。不,洩露這些照片的角色不是-用第二個相機使用愚蠢的方法。他們正在使用一些clickmouse蠕動應用程序,這些應用程序由於存在明顯的漏洞,可以使笨拙的工作輕鬆自如。我認為這是可以預防的。
-1
@0A0D好點。我認為將其存儲在內存中而僅使用內存是不太可能的選擇,因為人們傾向於讓電池幹and等(* poof *永遠消失了)。考慮到視頻也是通過這種方式傳輸的,而且我認為在世界範圍內還沒有可靠的3G / 4G,因此我也不認為僅將其託管在雲中一次訪問是一個切實可行的答案。無論如何,這些只是我對開發人員在這里工作原理背後的思考過程的猜測...如果他們懷疑並加入這裡的convo,仍在等待來自手套本身的評論!
@DmitriDB:我不使用該應用程序,但我聽說過。如果重點只是發送一張可以看到幾秒鐘的傻照片,那麼保存它毫無意義。除非有令人信服的理由回頭看看它們。我當時認為,使用密鑰對軟件包進行加密將是一個有爭議的問題。
-1
如果您將任何東西放在網上,則必須假定它將永遠存在。這包括圖片在兩個移動設備之間通過Internet傳輸。 Snapchat實際上應該有道義上的義務告知人們,他們不是在阻止人們保存圖像,而只是試圖使其變得更加困難。此外,似乎Snapchat過去是,現在也是由業餘愛好者製作的。將解密密鑰硬編碼在二進製文件中嗎?真?在上完第一堂編碼課之後,我們所有人都停止這樣做了。
@DmitriDB _“我為那些不得不天真爛漫地信任錯誤的人而忍受嚴肅的女孩感到抱歉。一方面,您可能會在這裡將他們歸咎於他們,並說這是他們做這些事情的錯。 “ _-誰是“錯誤的人”?即使Snapchat本身俱有100%的安全性,但照片仍會最終顯示在屏幕上,供外部相機捕獲。當然,年齡大到想要發送私密照片的女孩已經大到可以意識到這一點了嗎?
@nnnnnn當然,認為大多數人都像您可能感到驕傲一樣合理。在任何情況下,並不是說我們真的有責任推理它們,但是我喜歡SnakeDoc的建議,即他們至少應該警告人們,對於所謂的無限回波腔,這裡沒有任何東西具有短暫的質量保證。互聯網,尤其是對安全性完全半估的實施而言。
@DmitriDB-我同意,第一次使用該應用程序時,以紅色大寫字母警告會很好,以使所有人都清楚。
由於我懷疑實際上在當今的電話中是否存在一種方法可以自我毀滅不可複制的代碼,至少沒有軟件實現,因此沒有什麼可以阻止它的完全安全。另一方面,他們本可以使該過程更煩人,以便只有最專心/最了解知識的人才能洩漏圖片。
事實是,Snapchat沒有給出真誠的回應。只要他們擁有自己的市場份額,並且沒有人抱怨會損害他們的利潤,他們將繼續重申自己的半成品安全策略,並告訴外行“這種加密,更安全,哇”。他們沒有也從未致力於安全和/或隱私。
hakjhkjdhakjhdkja
2014-03-03 17:26:57 UTC
view on stackexchange narkive permalink

因為這是信息論的基本原理。

如果一台機器可以解密一條信息並將其保留十秒鐘,那麼它可以將其解密並永久保留。

任何試圖掩飾這只是煙和鏡子。

+1而且無論如何也絕不打算保護手套
如果該體系結構具有防篡改部件怎麼辦?參見[一次性程序](http://link.springer.com/chapter/10.1007%2F978-3-540-85174-5_3)
您鏈接的摘要中的@JanusTroelsen:“單獨使用軟件顯然不可能完成所有這些任務,因為任何一件軟件都可以復制並再次運行,從而使用戶可以在多個輸入上執行程序。我們所有的解決方案都使用安全的內存該設備受到交互式遺忘傳輸協議的加密概念的啟發,該設備存儲了兩個秘密密鑰(k 0,k 1),該設備將單個比特b∈{0,1}作為輸入,輸出kb,然後自毀。 ”由於當前的PC沒有這樣的安全存儲設備,因此無法實際實現。
@JanusTroelsen好的鏈接,如果PC和電話開始包括一些允許這種情況的更多硬件級別的安全性,那將是很好的。實際上,自毀數字內容的主題是一個非常有趣的話題。
@didibus沒有這樣的事情。任何硬件解決方案都可以進行逆向工程;您所能做的就是加大難度。
user10211
2014-03-03 15:05:25 UTC
view on stackexchange narkive permalink

該代碼不是“破解”加密。

您只是在使用通過對應用程序進行反向工程獲得的正確加密密鑰解密數據。

他們如何做得更好?不能對一個加密密鑰進行硬編碼。

@theGreenCabbage在任何情況下都難以理解的經典示例。如果您希望接收者能夠看到圖片,則接收者可以對其進行複制。至少,如果您在電話上擁有全部特權,那確實不難實現。哎呀,讓圖片全屏顯示(不知道是否有手套,但我想他們允許嗎?)並製作一個屏幕截圖-結果沒有太大區別。
John Deters
2014-03-03 17:17:06 UTC
view on stackexchange narkive permalink

因為它不應該安全可靠。 Snapchat是用於共享的,與安全性相反。

我認為他們已經為他們的模型實現了他們認為“足夠”的安全性。他們不太關心持續時間超過幾秒鐘的照片,因為人們總是可以通過模擬孔複製它們。這種加密可以防止人們簡單地保存要顯示給朋友的文件,因此他們需要做一些額外的工作。這個簡單的步驟足以保護他們99%以上的照片。

mckenzm
2014-03-04 05:43:54 UTC
view on stackexchange narkive permalink

通過設計。我認為行數無關緊要。我也不認為該語言是相關的。

簡化的問題是“為什麼任何人都可以解密這些”。答案-因為那是目的。

背景是加密只能是口頭上的服務,就像加密的.pdf文件通常以四個字母詞典單詞作為密碼發送一樣。

p>

雖然有安全性,但在某些令牌級別上可以避免。外行人毫無頭緒。我們知道得更多。 (我們知道在後斯諾登時代,我們無法確定我們是否可以信任受SSL保護的網站。)

簡而言之,這是一個塑料掛鎖,可以滿足加密傳輸的承諾。

Lolol
2014-03-05 23:31:10 UTC
view on stackexchange narkive permalink

“所以,我的問題是,他們到底在這裡做錯了什麼?”

一個簡單的做法是,他們在對技術不夠熟悉的人們中產生一種虛假的安全感。願意信任向陌生人發送原本會被視為私人的信息...

這是設計中的真正缺陷。

通過更方便的方式來做到這一點,他們應該幫助培養更聰明的世代,或者只是放棄安裝,以免自殘的受害者不會感到犯規。

有可靠,經過嘗試和真正的加密和傳輸互聯網通信的方法,最終目標是,如果您希望安全性獲得安全性,如果您希望獲得攔截,重新分發和不良編碼實踐的機會,那麼請下載本週在應用商店中最熱門的內容...

安全性不方便,通常它並不有趣,而且也不簡單。所有會殺死夜間應用程序的東西。

我個人會更擔心開發人員可以通過單個攻擊大量訪問...

Drunix
2014-03-05 20:18:17 UTC
view on stackexchange narkive permalink

手套的問題在於他們實際上在進行普通加密,而實際上他們需要 DRM 。後者涉及的主題不僅僅是簡單地加密數據,還需要例如對用戶隱藏密鑰。看來他們在這件事上失敗了。

沒有人*需要* DRM。
DRM涉及控制數字內容可以完成的工作,而這正是人們所承諾的,顯然是無法交付的。當您說沒有人需要DRM時,您可能會想到DRM維護$ BigCompany $的利益,以防其客戶的合法利益。我認為我們大多數人都不喜歡DRM的這種應用程序,但是在本質上,這是為了維護髮布圖像的用戶的利益。保證圖像在一段時間內不可用的每一種方案都在控製圖像的使用,因此就定義了DRM。
儘管我同意Snapchat模型的安全性遠不如DRM,但同樣的問題仍然存在。並不是說DRM是無法破解和剝離的不可穿透的東西。
Russell.Clare
2014-03-05 13:27:01 UTC
view on stackexchange narkive permalink

不良做法和折舊的安全標準共同導致了此漏洞的出現。特別是考慮到Snapchat的“任務” ,使圖像,文本等不可複制,並且只能查看一次,因此,更好的方法是一直在每次啟動時隨機生成一個PSK,並在應用程序運行期間使用它,從而使每次重新啟動時它的數據都無用。是的,正如許多其他人所說的那樣,將安全密鑰直接硬編碼到應用程序的代碼中是非常非常糟糕的做法,可以很容易避免。

總結一下,輕鬆解決此問題:

使用隨機生成的字符串(以及更好的加密算法,儘管這種較差的選擇可能與較低的處理器要求和更容易擁有過時智能手機的主要目標受眾[年輕人]相關)預共享密鑰,每次啟動時都會循環運行,從而在應用程序重新啟動時使緩存無效。

真的很容易解決。聽起來他們可以通過一些有關安全最佳實踐的諮詢來做到這一點。

即使這樣,如果圖像是通過未加密的wifi或LAN清晰傳輸的,那麼拍攝仍然清晰,成熟
Dmitri DB
2014-03-11 00:59:58 UTC
view on stackexchange narkive permalink

因此,我打電話給他們以回复我在他們的支持下提出的問題,而得到了它。因此,幾天后,這是Snapchat對我的支持要求的官方回复,我將其鏈接到此帖子,並詢問他們是否可以自己對此問題做出誠實的答复。我個人認為這幾乎是我所能獲得的最弱的答复,並且表明對安全實踐的功能失調,更不用說公共關係了:

  Team Snapchat回答:嗨德米特里,謝謝你的關心。我們始終致力於維護Snapchat社區的安全性和完整性。Best,Tobias  

謝謝,謝謝!



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