刚遇到的红宝石可以用来解密从手机缓存中取出的Snapchat照片,显然是从这里改编的。令我惊讶的是,考虑到Snapchat的安全性问题最近已经得到了很好的宣传(我记得多数情况下,整个电话号码/用户名泄露的问题),它的工作没有问题。



所以,我的问题是,他们在这里究竟在做错什么?为了提高应用程序在这方面的安全性,而不是现在在做什么,他们可以做得更好?考虑到人们经常向一个人发送绝不会共享超过10秒的私密事物,并且还考虑了此应用程序的受欢迎程度?真的很想知道计算机是如何工作的,但仍然想知道发生了什么:基本上,假设您有4,000万使用Snapchat的人,有1,650万用户互相发送图片,并且每张图片每天都在自己的细小安全锁中。现在,如果您给这1,650万人以同样脆弱的塑料钥匙打开每个密码箱以捕获Snapchat媒体,那该怎么办?

评论

2012年12月:twitter.com/adamcaudill/status/285300559269994497

@DmitriDB-关于保险柜的介绍,其中每个人都有可以打开“每个密码箱”的相同塑料钥匙,这意味着您正在谈论一种侵入他人照片的方法。但是您显示的代码依赖于从实际的单个电话中获取数据,不是吗?

@nnnnnn在我对外行的精简解释中,“钥匙”指的是“微型锁定的保险箱”,它被发送到每个装有媒体的电话。一些笨蛋把它自己“清理”了下来的定义,并加上了语法错误,所以我真的不确定它是否像以前那样清晰……但是,不,那绝对不是它意思。

清理评论,删除肥皂盒,在此处恢复为实际的主题问题。

#1 楼

这是密码管理中的一个严重问题。这里的第一个问题是他们在源代码中管理密钥的方式。 SnapChat声明他们通过互联网发送加密的照片,毕竟这是事实,但是他们使用“预共享”密钥对该数据进行加密(在ECB模式下也非常使用AES),因此,地球上的每个用户都有解密每张照片的钥匙。

这里的问题是,互联网是如何获得密钥的?小菜一碟,他们只是将其包含在每个应用程序中,而有人只是在搜索它。


任何Snapchat应用程序使用的这个魔术加密密钥是什么?

M02cnQ51Ji97vwT4

可以在com.snapchat.android.util.AESEncrypt;中的常量字符串中找到此字符(在Android应用程序中);无需挖掘,
从字面上看就围坐在等待被任何人发现的地方。

更积极的一点(也许)是,在Android应用程序的3.0.4(18/08/2013)构建版
中,有-很奇怪-第二个键!

1234567891123456


在源代码中对密码进行硬编码(无论是在标题中还是在二进制文件中)都是非常不好的做法,主要的问题是,任何人都可以使用简单的“字符串”命令将其查找到二进制文件中(或通过在以前与朋友共享代码的地方查看)来找到它:

strings binaryFile

>然后,恶意用户可以查看每个字符串,并检查是否这是他要查找的密码。因此,如果您确实需要在代码中对密码进行硬编码,则最好将其隐藏,但这只是“默默无闻的安全性”,恶意用户最终会找到密钥(因此,您最好采用其他方法)。

他们可以采取什么措施来提高安全性?他们可以为每张照片生成一个密钥,或者可以在要共享图片的客户端之间预共享一个密钥,即公共/私有密钥;有很多选择。

评论


最大的问题是他们的目标无法解决-阻止设备所有者保存图片。即使对于DRM方案,这仍然相当薄弱。更加精细的密钥管理可以稍微改善情况,但不会太大。您仍然可以拍摄屏幕快照或挂钩API,通过该API渲染解密的图像。

– CodesInChaos
2014年3月3日12:53



好吧,至少在截取屏幕快照时,它们往往会在收到通知时被捕获...至少当您以任何常规方法将其截屏时(按手机上的三个按钮或不按此按钮)。但是,是的,我所能做的就是同意,这是很薄弱的事情!

– Dmitri DB
2014年3月3日在16:35

您甚至都不需要截屏。由于您可以亲眼看到,因此请使用其他手机,网络摄像头,VCR便携式摄像机等保存图片。该应用无法阻止。

–布赖恩
2014年5月5日14:05

哎呀,如果他们完全删除了下载的图像,他们可以消除此漏洞。不会阻止模拟漏洞,但如果应用程序只是将其加密存储在内存中,则您将必须启动设备并在后台运行另一台设备,以将与手套有关的任何内容从内存中提取出来。

–布赖恩
2014年5月5日14:10



@ 0A0D&basher好吧,这是我对人们如何使用该应用程序的看法所提出的问题,以及您似乎在我的此处文章中遗漏的内容-人们正在使用它来发送“私密”照片。孩子,谁都不知道,等等。这些孩子在整个互联网上流失,现在我们有女孩成为无心色情明星。不,泄露这些照片的角色不是-用第二个相机使用愚蠢的方法。他们正在使用一些clickmouse蠕动应用程序,这些应用程序由于存在明显的漏洞,可以使笨拙的工作变得轻松。我认为这是可以预防的。

– Dmitri DB
2014年5月5日在20:38

#2 楼

因为这是信息论的基本原理。

如果机器可以解密一条信息并将其保留十秒钟,那么它可以将其解密并永远保留。

任何试图掩饰这只是烟和镜子的事情。

评论


+1而且无论如何也绝不打算保护手套

– Wim
2014年5月5日在1:22

如果该体系结构具有防篡改部件怎么办?看一次节目

– Janus Troelsen
2014年5月5日13:25



您链接的摘要中的@JanusTroelsen:“显然,仅使用软件就不可能完成所有这些任务,因为任何一件软件都可以复制并再次运行,从而使用户可以在多个输入上执行程序。我们所有的解决方案都采用了安全的方法受交互式遗忘传输协议的加密概念启发的存储设备,存储两个秘密密钥(k 0,k 1),该设备将单个比特bbit∈{0,1}作为输入,输出kb,然后自毁。”由于当前的PC没有这样的安全存储设备,因此无法实际实现。

–法律
2014年6月6日在8:27



@JanusTroelsen好的链接,如果PC和电话开始包括一些允许这种情况的更多硬件级别的安全性,那就太好了。实际上,自毁数字内容的主题是一个非常有趣的主题。

– DiidierA。
2014年10月10日15:25



@didibus没有这样的事情。任何硬件解决方案都可以进行逆向工程;您所能做的就是加大难度。

–钟莉莉
2014年8月5日在4:58

#3 楼

该代码不会“破解”加密。

您只是在使用通过对应用程序进行反向工程而获得的正确加密密钥解密数据。

他们如何做得更好?不能对一个加密密钥进行硬编码。

评论


@theGreenCabbage在任何情况下,晦涩难懂的经典示例。如果您希望接收者能够看到图片,则接收者可以对其进行复制。至少,如果您在电话上拥有全部特权,那确实不难实现。哎呀,让图片全屏显示(不知道是否有手套,但我想他们允许吗?)并制作一个屏幕截图-结果没有太大的不同。

– Voo
2014年3月3日在22:01



#4 楼

因为它不应该安全可靠。 Snapchat是用于共享的,与安全性相反。

我认为他们已经实现了他们认为对模型足够的安全性。他们不太关心持续时间超过几秒钟的照片,因为人们总是可以通过模拟孔复制它们。这种加密可以防止人们简单地保存文件以显示给朋友,因此他们必须做一些额外的工作。这个简单的步骤足以保护他们99%以上的照片。

#5 楼

通过设计。我认为行数无关紧要。我也不认为该语言是相关的。

简化的问题是“为什么任何人都可以解密这些”。
答案-因为那是目的。

背景是加密可能只是口头上的,就像加密的.pdf常常与四个字母的词典单词一起发送作为口令。外行人毫无头绪。我们知道得更多。 (我们知道,在后斯诺登时代,我们无法确定我们是否可以信任受SSL保护的网站。)简而言之,它是满足加密传输承诺的塑料挂锁。

#6 楼

“所以,我的问题是,他们在这里到底在做错什么呢?”

这很容易,他们在不熟悉他们所愿技术的人们中产生了一种虚假的安全感。信任向陌生人发送原本会被视为私人的信息...

这是设计中的真正缺陷。

而不是使用更方便的方法为此,他们应该帮助培养更聪明的一代,或者只是放弃安装,以免自残的受害者不会犯规。最终目标是,如果您希望安全性获得安全性,如果您希望获得拦截,重新分发和不良编码实践的机会,那么请下载本周应用商店中最热门的内容...不方便,通常不好玩,也不简单。所有杀死夜间飞行应用程序的东西。

我个人会更关心开发人员是否可以通过单个攻击大量访问...

#7 楼

手套的问题在于,他们在进行普通加密,而实际上他们需要DRM。后者涉及的主题不仅仅是简单地加密数据,还需要例如对用户隐藏密钥。看来他们在这件事上失败了。

评论


没有人需要DRM。

– AShelly
2014年5月5日18:25

DRM是关于控制数字内容可以完成的工作,而这正是人们所承诺的,显然是无法交付的。当您说没有人需要DRM时,您可能会想到DRM维护$ BigCompany $的利益,以防其客户的合法利益。我认为我们大多数人都不喜欢DRM的这种应用程序,但是在本质上,这是为了维护发布图像的用户的利益。保证图像在一段时间内不可用的每一个方案都在控制图像的使用,因此就定义了DRM。

– Drunix
2014年5月5日21:39

尽管我同意Snapchat模型的安全性远不如DRM,但同样的问题仍然存在。并不是说DRM是无法破解和剥离的不可穿透的东西。


2014年6月6日18:13

#8 楼

错误做法和已贬值的安全标准共同导致了此漏洞的出现。
特别是由于Snapchat的“任务”使得图像,文本等不可再现且只能查看一次,因此更好的方法是随机生成每次启动时使用PSK,并在应用程序运行期间使用它,从而使每次重新启动时数据都无用。是的,正如许多其他人所说的那样,将安全密钥直接硬编码到应用程序的代码中是非常非常糟糕的做法,并且可以很容易避免。

总结一下,轻松解决此问题: br />
使用随机生成的字符串(以及更好的加密算法,尽管这种较差的选择可能与较低的处理器要求和更可能拥有过时智能手机的主要目标受众[年轻人]有关)作为SSL的预共享密钥,该密钥在每次启动时都会循环运行,因此在应用重新启动时使缓存无效。

真的很容易解决。听起来他们可以在安全最佳实践方面进行一些咨询。

评论


即使这样,如果图像是通过未加密的wifi或LAN清晰传输的,那么拍摄仍然清晰,成熟

–布赖恩
2014年5月5日14:02

#9 楼

因此,我打电话给他们以回复我在他们的支持下提出的问题,而得到了这个。因此,几天后,这是Snapchat对我的支持要求的官方回复,我将其链接到此帖子,并询问他们是否可以自己对此问题做出诚实的答复。我个人认为这几乎是我所能获得的最弱的答复,这表明对安全实践的功能失调,更不用说公共关系了:

Team Snapchat replied:
Hi Dmitri,

Thank you for sharing your concerns. We remain committed to maintaining 
the security and integrity of the Snapchat community.

Best,
Tobias

/>谢谢你!