Nothing instills confidence in cryptographic code like the constants "bananas" and "seems legit...". I'd have hoped that anyone dealing with AES and block cipher modes would take the task a bit more seriously, even if the whole task is, in this instance, ultimately futile due to the lack of a trust root.
> Nothing instills confidence in cryptographic code like the constants "bananas" and "seems legit...".
And a class called "SlightySecurePreferences". One gets the feeling that the programmer responsible knew exactly what he was doing, but had been told to do it anyways.
Well, prior - there were apps you could download that would save Snapchat images that would work on non-root devices. At least by enabling this encryption that's now only available to the relatively small amount of root users out there.
If Snapchat is serious about its users' private messages, it should be implementing the Axolotl protocol for end-to-end encryption (what TextSecure uses, too). But Snapchat isn't serious about it, as we've seen in several securiy/privacy scandals involving the company so far, so I'm not going to hold my breath for this.
Pro tip for future chat app start-ups promising "security" or "privacy" or as the latest trend goes, "anonymity" for their users. If you can't really hold your end of the bargain, don't do it! Promise cute emoticons or whatever, instead. Hopefully there will be some class action lawsuits against companies like Snapchat, soon. They need to learn their lesson.
You don't quite understand. The threat model here is "a Snapchat user copying/saving a Snapchat image they receive", not TextSecure's threat model of "a third party observer or man in the middle". Implement whatever protocol you like, it doesn't matter; a user who roots his own device will be able to do whatever he likes to data stored on that device.
In the end the application needs a key to decrypt the storage. That key has to be stored somewhere on the device. On a rooted phone there is no place out of reach, so all they can do is make the storage obscure. Unless the hardware provides some inaccessible secure thingy there's not much they can do... I guess even if it did a script like that could access the secure thingy via USB debug as well.
I don't think the developers are to blame. They did what they could.
The real problem is that snapchat promises something it can not technically deliver. Once a photo leaves your phone and is delivered to somebody else, you lost control over that photo.
The real problem is that snapchat promises something it can not technically deliver. Once a photo leaves your phone and is delivered to somebody else, you lost control over that photo.
It's precisely the same problem with DRM. You either lock down everyone's devices against their owners (a massive "do not want" situation) - and then you could still copy the data via the old-fashioned analogue hole (I'm not including the truly disturbing idea of adding implants to people's brains that force them to "delete" something they've seen) - or accept the inevitable fact that data that can be accessed is data that can be copied.
Quite frankly, Snapchat is a form of DRM, except it's marketed toward users in a way that makes it appear desirable.
> or accept the inevitable fact that data that can be accessed is data that can be copied.
I think this is something that is orders of magnitude easier for technophiles to accept than the average person.
Because to the average person it so so easy to delete data - they press the delete key and its gone! So they look at the problem and think the computer programmers just need to do a better job.
Whereas you or I realize that it virtually is impossible to prevent access of data - at least on a systemic level, and the problem (though in some cases it is the programmer's fault) isn't something that better programmers could fix.
No matter how secure they store the photo, at the end the day a simple screenshot makes it all for nothing. It would be cool if Android had some API to disable screenshots.
It actually has — Apps can prevent the system from taking screenshots by telling the DRM hardware chip that they are showing important data. Actually you can even prevent users from obtaining the data if you encrypt it with a secure key and store this key in the DRM hardware chip.
Only problem: Someone could still decompile your app, use your API and request the decryption keys.
Uhm, Android had an API to disable screenshots since forever - see http://developer.android.com/reference/android/view/WindowMa... . As soon as you add this flag to the Window, the contents will disappear from screenshots or device will refuse to make them (depending on Android) version.
The reason why Snapchat has screenshot notification is actually due to that API being absent from iOS for a long time.
Or, you could take a photo of the screen, if you wanted to save images you already have access to (something snapchat is supposed to prevent). The good old analog hole.
I believe that SnapChat alerts the sender if a screenshot happened. While this doesn't prevent the action, obviously, it at least lets the sender know.
They shouldn't store the images on the phone. You should be only able to view the image immediately after downloading it. After 10 seconds of viewing the image, everything gets deleted from ram.
It's also not difficult to bypass the app completely and poll the service from another program (for instance, run by cron on a server). Like other people have said, the entire premise is flawed.
I wouldn't say the premise of the app is flawed, rather it's just that people seem to misunderstand its technical capabilities.
Snapchat was designed for ephemeral communication, not secure "send-and-destroy" messages. It would be very foolish of them to market it as something it cannot possibly be.
Actually you could just download the encrypted images without the unique key( for every image ) and then get the key on demand. Load the image into ram, decrypt, show the image and then erase everything.
Because it's still totally flawed? Nothing stops anyone from writing a program that pretends to be Snapchat and downloads the keys and images as it pleases.
If you hide a per-device API key inside the real Snapchat app, you might at least require that the user root the device before being able to grant an Evil App access to their photos.
I was thinking about Bad Apps that users voluntarily hand their login details to (so they can download snapchats they get sent). Those don't need root, since they're just mimicking the Snapchat app and receiving the photos directly.
But it doesn't work, since you need some way to generate new API keys for your second device... which could be a Bad App.
If you 1) enforce one key at at time (so one "device" at a time), 2) rate-limit key changes (if you switch to a new device, or Bad App, you can't switch back within a day or two) and 3) eliminate Bad Apps in the app stores- you effectively limit Bad Apps to being entirely web-based, and hopefully the restrictions on webapps will make the Bad App sufficiently a pain in the ass to use that people won't want to switch to it, even though it lets them save photos, since it locks them out of the real app.
The fundamental problem here is application security in situations of rooted devices is non-existent. Android lacks mechanisms for apps to tell they're running as root too (as the root user could disable this) so you can't disable functioning on rooted devices. (Chrome OS does not have this problem, as the official builds are signed by a single authority).
Newer Android versions have support for hardware DRM modules which would allow potential for some sort of nasty workaround (which may involve transcoding any images into movies), but in the general case for the wider market it's not going to work yet.
Finally, this is also why the NFC stuff is generally accompanied by another isolated system, though I seem to recall early versions of that (like in the Nexus S) proved to be sidesteppable.
> Android lacks mechanisms for apps to tell they're running as root too (as the root user could disable this) so [apps] can't disable functioning on rooted devices
As the owner of the device (ie the one who should have ultimate control over it), this is precisely what I want. It would be horribly broken for an operating system to do anything else!
That we're not only still fighting the battle for personal computing but additionally having to defend against misguided ideas from people in supposedly technical communities is ridiculous.
You are not providing for the security of those that own the content, either in the case of a movie studio or in this case the taker of the photograph.
If you choose to have root, fair enough, but that decision does mean certain applications should cease to work. Simply banning all those applications from being allowed isn't really a solution at all.
Personally, I prefer to carry separate devices which are rooted and not, and this strikes me as the only viable way forward.
Some of your tech details are wrong btw. It is quite possible to get images on the screen which can't be accessed by the CPU, for example. Phones are not architecturally anything like as simple as desktop PCs.
This work was done within the Sadosky Foundation in Argentina under a new program to research/enhance security for mobile users. World renown researchers are part of the team. Kudos to them!
Snapchat does not take security seriously. I used the Gibsonsec description of the SnapChat API to make a Java Snapchat client called JavaSnap (github.com/hatboysam/JavaSnap). It has been used in many Android apps with close to 2M combined downloads (from what contribs have told me).
It was too easy. This is why things like 'The Snappening' happen (note: I never did anything evil like that, but it would not have been hard).
1. "The Snappening" was due to a breach of a third party service with no actual ties to Snapchat. This is like saying Bitcoin is insecure because of Mt. Gox's breach(es).
2. Most apps have documented or undocumented APIs. Writing a client to consume them does not indicate insecurity. It's only a security issue if the undocumented API exposes something that the company did not actually intend to expose (which, to be fair, is fairly common).
I have serious doubts about Snapchat's security due to the username <-> phone number leak discovered by GibsonSec, but the other things you listed say nothing of their security posture.
I don't know much about the Android environment, and I get that regardless you're storing keys in a hostile environment, but would using the Android KeyChain to store the passwords instead work?
You can do this for any app.... not just snapchat.
He sets his computer as a proxy between snapchat-app and snappchat-server. When I did this, Snapchat was certificate pinned to their server (it's been over a year though..so correct me if Im wrong).
This isn't an attack other people on the network can perform on you.
How a company with $163M in funding is not able to put just a normal encryption into their app or hire someone who knows about encryption is out of my comprehension.
We implemented a standard Blowfish encryption in university at a small project on the side and it was better than that.
I'm by no means a cryptography expert, but you don't store keys on the device, they are generated dynamically. Storing them in a directory that seems like an unimportant directory is the most amateur mistake of trying to increase security, as it adds zero security.
There is absolutely no cryptographic means of preventing a Snapchat user from saving a Snapchat image he/she receives. No matter what measures they put in place, they will all effectively be security by obscurity. If the image is in RAM long enough for a human to see it, then it can be copied elsewhere.
The fact that their current encryption procedure is half-assed is because they know it'll be security by obscurity no matter what they do, so why even waste time?. It doesn't make a real difference either way. They just want to prevent the absolute simplest attacks. They could have XOR'd all images with a 1-byte key and it would be equivalent, and still would suffice the business need.
Enlightens on then on how you would solve the issue. You have a program, and the program is storing data and the "attacker" (here really the user himself) wants to bypass the policies enforced by the application. The attacker has access to both the binary of the app and the data.
What would you encrypt the data with that the user himself cannot also access? Without a secure encryption hardware module, there's little you can do except add additional layers of obscurity.
You could encrypt all the data with a key derived off the user's password, and require the user to re-enter the key if the app stops. That too could be broken.
You could store the images in some odd obfuscated format that only the app can understand. That too could be broken after some time.
You could never store any images on disk at all and fetch them only when requested. Then you have the third-party services imitating the app.
Lemme get this straight.. The password is hardcoded into Java code, so by decompiling it you can get that pw and break it? So essentially simple decompilation was all that was needed? That's weak.
What would have been some better alternatives to keep the encrypted files safe on the phone? Couldn't they have it call the server for a dynamic (safe) key?
I cannot understand people who confide their privacy to companies like Apple and Snapchat. Of course their photos will be 'leaked'. It's just a matter of time.
Not really. Most people couldn't care less about the 10 second thing. They use Snapchat just as a means of sending a quick photo. It's just more fun than texting. I know very few people who actually care about the privacy aspect of it.
It is technologically impossible to prevent Snapchat users from saving or copying images they receive from other Snapchat users. Replace "Snapchat" with any other app here and the same principle applies.
Their proposition is not that this is impossible, but rather that it is not easy for a typical end user to see past images. This enables a form of ephemeral communication; it was never intended as a security feature, simply a communication feature.
