Edit: deleted, for very valid criticism. Next time I won't post in a rush during work hours.
I'd suggest taking the same approach with your "secure, end-to-end encrypted communications" app you keep mentioning here[0]
A one-way sha256 hash of a message using a password that has to be 8 characters long[1] and can't accept special characters[2] is not a secure communications app
It is trivial to find the plaintext in these situations.
Your Chrome extension has a very elementary RCI bug in it[3], which because of your extensions broad permissions[4] profile means anyone with your extension installed can have any code executed by visiting any page.
To release (excuse me) crap like this on one hand while FUD'ing Google's security practices on HN on the other requires a level of hubris that I don't think i've ever previously encountered.
[1] http://i.imgur.com/CsgOkZ2.png
[2] http://i.imgur.com/uZg0E4l.png
As for Chrome - that team has some of the smartest infosec and cryptography people in the world working on and contributing to the project. If you want some insight into how some of the security design principals and tradeoffs were rationalized, i'd start with the project wiki:
it is also being marketed as such by you here
Believe it or not, I would love to get Nik as a consultant. I fear my 'hubris' (I won't deny it, this idea is extraordinarily ambitious and I have to be arrogant to even conceive of it) will have pissed him off irrevocably.
That aside, I don't really follow his point on the login PW. I understand 8 char alphanum pw is pretty low entropy... but that isn't used for encryption. And the login attempt rate is pretty strictly rate limited.
And yes, I am getting professionals - not me - to do the heavy lifting. I wrote the proof of concept. I am in no way surprised to find it has issues - I am aware of a few others myself.
if you're doing
aes(plaintext, sha2(password)) = cyphertext
given cyphertext I can get to plaintext with sha2(8-char dictionary)
well designed systems will generate a truly random key there, exchanged using public-key. if you're going to use a password, you need a key-derivation algorithm
this is all bunk tho since the big vulnerability here is that you're delivering the encryption routines via javascript in a global browser space
So what about mailvelope?
I want you to know, very sincerely, I appreciate your feedback over the past two days.
Some lessons (re-)learned:
* Security is a conclusion, not an assertion - it is improper to present a system as secure without evidence. * I am not, nor will I ever be, qualified to provide a conclusion regarding security. * The language on the homepage needs to be clear in this regard without being 'cute.' * If I ever post on HN regarding security, either use evidentiary sources to back my points on provide code.
Thanks for the reality check.
the design of the app is that it injects content scripts with global variable names everywhere.
any site can overwrite the encryption functions, or redefine some of the global vars that are used for images, etc.
Would you consider heavily caveating statements you make about information security? A lot of what you say here is basically wrong.
A national security lawyer could provide interesting insight into how the CIA is allowed to use these tools vs NSA.
That is appreciated, and you are in the minority.
I'm taking this advice, btw, and being more circumspect when I post in the future.
Cheers.
The whole "why not encrypt local resources" thing is an odd red herring that a lot of (even fairly experienced) people trip over. There was a massive public furor over Chrome's chrome://settings/passwords (i.e. lack of a master password) design choice a couple of years ago that was a specific such case in point.
Chrome: =======
Someone who can access chrome://settings/password is presumed to have physical access to your powered-on, unlocked machine. E.g. someone who sits at your keyboard when you get up for coffee.
And that person can just as easily install a Chrome extension that sniffs your passwords or steal your raw auth cookies directly from the developer console. (He could even paste some JS into the developer console to intercept the password as-typed by autocomplete!)
(Note that an attacker with access to a locked/powered-off machine or with no local access is not part of the threat model, since they are presumed to be addressed by FDE, screen locks, remote access controls, etc.)
Now, the major counterargument is essentially that a lot of unsophisticated attackers (like spouses) may not know about cookie jars or JavaScript, but they know about "view saved passwords." I find this argument somewhat reasonable, but from some vantage point it's security theater--not knowing about ctrl+j isn't a strong security guarantee, after all. So I view the Chrome team's stance as being a very principled one, namely: don't invest in "security" features where a bypass would not be a bug.
(In some literature this is referred to as a "security boundary", typically defined as "a control which, if bypassed, has a bug." Note the contrast with, for example, spam filters and antivirus, which may be sometimes bypassed while working as intended.)
More generally: ===============
I think what was lacking in this conversation in general was a firmly defined threat model and a firmly defined security boundary. My contention about per-application encryption is that it doesn't represent a security boundary because any attacker who can execute code that can read application-ACL'ed data on disk is by definition either running code at a higher security level (e.g. has root) or is running code at the same security level (and can thus inject code into the browser process itself).
This conversation gets a little more complex when talking about mobile OSes that have per-application sandboxing, but the same observation effectively holds.
Anyway, I'm tired of typing, but hopefully that makes a bit of sense. Let me know if I'm being confusing.
* On OSX, OS passwords are stored in the keychain. * However, Chrome stores passwords in a local SQLite database https://www.howtogeek.com/70146/how-secure-are-your-saved-ch..., which, on osx, I believe is in your Application Support Folder ("ChromeDB") * The user, who is not root, has read/write access to the ChromeDB * Is it not the case, then, that any script that has user-level permissions can access the Chrome passwords? Because Chrome is not available through the app store, it does not store passwords on the OSX keychain, which, again, correct me if I'm mistaken, requires higher permissions to read? So that, for instance, a malicious script that only had user-level permissions could not access the contents of databases encrypted with credentials stored in the keychain?
A malicious script that runs as user X can typically (on desktop OSes) inject code into any other process running as user X at the same security level. The details vary by OS--in Windows there's a system call called NTCreateThread that lets you inject code from a loaded DLL in your process into any other process at the same or lower security level; in OSX, at a quick Google, it looks to me like http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_c... may do the same.
So the attack that this opens up is to basically wait until Safari is running and loads the credentials into its memory--which it has to do to prefill the password field in a page--and then just read that memory from your code running in the same process in a different thread (which shares the address space). And if you don't want to wait, you can simply request the credentials directly from the Keychain API; Keychain doesn't know you're not "Safari" (since you're running in the same process) and will happily give you the credentials!
Now, there's still a small advantage to the DPAPI/Keychain approach, namely that it allows the OS to show approvals to the user ("Unlock the keychain?" dialogs or whatever), ensuring that the malware can only steal credentials while the user is present. There are some circumstances where a credential API is nonetheless useful. Offhand:
1. Cases where there's a test-of-presence ("Do you want to unlock the Keychain?") conducted by the higher-privilege process, and where approval is not routine (so that the user is not going to just click "OK"). Browser password autofill is not such a case, however.
2. Cases where there's a test-of-presence and the user assent is transactional (i.e. they see what they're approving and the approval is only good for that one action--as with Windows UAC).
3. Cases where the credential granted is a signature and not a bearer-token, and we find some advantage in the token itself being bound to the device. (IOW, the down-level process can steal a signature, but it can only use the signature for some limited use, and cannot steal the signing secrets, which never leave the privileged domain.)
So to get this right requires a lot of thought about things like broker processes, transactional approval, etc. I'm far from an expert in this, but hopefully the above makes some sense.
However, in my experience (disclaimer: the plural of anecdote is not data, I am very well aware of this), the frequency of worms and viruses that are released by script kiddies using commercially available malware is on the rise, and these are malicious and effective but not terribly sophisticated. Check my other thread for more on this.
In other words, what I am saying is that you are describing a very nasty theoretical worm - I am, however, describing to you a family of worms that is currently out in the wild and causing a hell of a lot of damage, and, as far as I know, actually does function in the way I describe. Filecryptor viruses can be made / purchased by any script kiddy jerk these days, and it seems to me that they do not function in this very sophisticated way you describe, but instead may actually be stymied by local encryption of files with passwords in them. (Or, rather, the distribution of your passwords to the virus owner would be stymied.)
I would very much like to know if is accurate or not. I understand that the devil is in the details, but if it is true, then I stand by my point that it seems unwise (borderline indefensible) not to encrypt local password stores - as there is a known valid threat. If it is not true, then I stand corrected - which happens all the time.
Either way, I am deeply interested to know.
You're right that unsophisticated malware may be thwarted by per-app disk encryption or credential stores like Keychain, but it doesn't represent a security boundary. That's why I would describe the Chrome team's approach as being "principled"--they're refusing to implement an ambiguously useful security feature because its bypass would not represent a bug.
Whether such a feature is nonetheless valuable for the user is unanswered by that discussion, however; as you say, it may have value in some circumstances.
However, remember that by volume most exploitation is (as best as I can tell) economic--people who do it for business. And people doing it for business can buy whatever malware is on the market. If stealing in-memory secrets is reliably accomplished (which it is), malware vendors have a strong incentive to implement this and sell it as well.
So I think you have the right idea, but answering the question is nontrivial. If Chrome implemented file encryption (or, more likely, used the platform APIs where available), would the engineering cost (and complexity--e.g. different behavior on different platforms) be counterbalanced by the increased cost imposed on malware authors? Or would one or two malware authors quickly adapt and malware prices/effectiveness would remain fairly static?
You get the point.
Check it out and let me know what you think.
Edit: from the top google result on Dynacrypt:
>While the ransomware portion of DynA-Crypt, as described in the next section, is a pain, the real problem is the amount of data and information this program steals from a computer. While running, DynA-Crypt will take screenshots of your active desktop, record system sounds from your computer, log commands you type on the keyboard, and steal data from numerous installed programs.
>The programs and data that DynACrypt steals includes:
>Screenshots
>Skype
>Steam
>Chrome
>Thunderbird
>Minecraft
>TeamSpeak
>Firefox
>Recordings of system audio
Would local encryption of these password stores be a (potentially) effective protection against this?
To what are you referring to here, precisely?
Since AOSP is open source, is there a specific line of code that you can point to that contains (or is emblematic of) this insecurity?
Your article doesn't seem to say.
as a "(slightly-higher than script-kiddy-level) web developer" I'm going to guess that he doesn't actually know very much about AOSP, the Linux kernel, or indeed GNU/Linux security in general. So his emphatic statement "Compare the security of Android - which we now know to be 'owned' by the US Government" is pretty much worthless as he's very clearly speculating about things that he doesn't understand.
I know a fair amount for a 'layperson', which you can (probably rightly) argue means I am unqualified for comment in these circles, and you are right that I am including too much speculation. I absolutely, inarguably overstepped. My bad.
However, with regard to Android being owned - this article is literally about the CIA tools that are used to compromise Android. The trove has been released. It is incontrovertible at this point: https://www.washingtonpost.com/world/national-security/wikil...
The issue is to what extent other fundamental assumptions are now called into question. Is it only android, or is Chrome now suspect as well? What protocols are compromised?
I suspect we will find out more in the coming days, and I should have been more circumspect in my own post. It was unbecoming.
In any event, thanks for your feedback.
Back to the question at hand - there seems to be extremely strong evidence that android - and iOS, apparently - are compromised pretty thoroughly. https://betanews.com/2017/03/07/wikileaks-vault-7-cia-year-z...
If this is not the case, then what is your conclusion? Because the claim that is being made far and wide, right now, is that android, ios and samsung smart TVs appear to be fundamentally compromised.
You want to distinguish between:
- remote takeover (like stagefright vuln)
- ability to take control of the device from within an app sandbox
- ability to unlock a device in your physical possession (FBI was able to do this on prev V of ios)
The background video on gibber is awful, makes it very hard to read the page. I've just opened it in another browser with all the JS on and again your page totally doesn't work with the google ajax switched on. Worth fixing.
So your comparing the current security of the iPhone with old CIA Android and Chrome exploits from circa 2011-2013?
But this is just as secure as full disk encryption of the device right?
Android applications are also sandboxed from each other. You would have hard time getting from one app to another's files, unless the original app published them - or you've got root.
Just hacking the device while it is being used is what every iOS jailbreak does. And there seem to be quite a number of them.
Not sure why you mention "secure local storage"; none of that local storage is secure if the device is compromised! That can then be bypassed in the same way that you bypass WhatsApp or manipulate any other app on the device.
If you are running something based off of AOSP, you're running code that was touched by Google employees. Is your fear that Google is installing backdoors to help the CIA? If so, why are you afraid of that?
Is that your concern? And if so, why are you concerned specifically about Google apps? Any malicious app can exploit a local EOP.
To expand, this would be some vulnerability which allows a non-privileged local app (like Gmail) to execute code at a higher security level.
The focus on Google apps specifically here is misleading. In the Android (and iOS) security model, apps are sandboxed, and cannot generally inject code into other apps (in contrast to most desktop OSes, where all processes running as "you" can sort of do what they want to each other).
The threats that apply on Android or iOS are, roughly speaking:
1. You grant an app more permission than it should have (e.g. microphone or keyboard input)
2. Local EOP plus installing a malicious nonprivileged app (or a remote code execution vuln) such that someone can get root on the device and inject code into Signal (or whatever)
3. A backdoor in the OS or app you are using
Android and iOS both have vulnerabilities in the wild. Older Androids are riddled with them, and the Android ecosystem is shit for getting updates out. If you're not using a Nexus or Pixel or a device from a reputable OEM (supposedly Samsung takes patches seriously, but I don't pay attention to this), you're probably easily exploited.
That's all the news that's here, AFAICT. The focus on encrypted messaging apps is on the one hand silly and on the othe rprobably necessary. Everyone in the security world knows that the easiest way to beat end-to-end encryption is to compromise the endpoint. But everyone in the wider world thinks that if they use Telegram they're secure, even if they're using an unpatched Samsung from 2011.
Also, if I remember right (and I'm not an Android expert, so grain of salt here), Android OS itself enforces sandboxing based on app signing keys; even the Play app can't overwrite the Signal binary without a binary signed by the same key (though conceivably it could install some other fake-Signal app that looks just like Signal and has a similar icon--but that app would not have access to your private key!).
Personally I trust Android as much as I'd trust iOS... Which is to say I expect the government can get at either with physical access but only at the highest levels of government (CIA/NSA/FBI).
As you say, in both cases (iOS and Play Services) it's a commercial closed-source bundle. shrug
I don't personally spend time worrying about that, given that Google and Apple's code is probably better reviewed than some random open source app, but some people like to nerd out about such things.
As you say, the FBI was eventually able to get access to the San Bernardino shooter's phone. But this isn't exclusive to the highest levels of government; it just depends on your budget: http://www.reuters.com/article/us-apple-encryption-fbi-idUSK.... It's not surprising the CIA would have a stockpile of unpatched 0days, found or bought.
I don't believe I'm worth $1m to anyone, so I feel pretty safe using both iOS and a recent, patched Android.
And it's kinda an unspoken goal of mine to, ya know, not end up on a CIA watch list. Now I know some of the concern goes around controlling so the Government doesn't get out of control but I think that we would expect a government's worth of resources able to do something as trivial as cracking a commercial phone.
First rule of not being on the watch list is not to admit you don't want to be on the watch list.
What, do you have something to hide? Huh?
Maybe he was referring to these privileged permissions: http://android.stackexchange.com/a/17874/104563
Doesn't matter who touches code when that code is publicly visible and available to the scrutiny of everyone. AOSP can be checked out and audited independently, just like any open source project.
Open vs closed source is a distinction I don't see a lot of folks in the security community take seriously, and for good reason: it's a response to a very specific threat model, where your concern is not primarily accidental 0days but intentional backdoors.
I would posit that the cost of a backdoor is probably higher than the cost of an 0day: the reputational risk to Google or Apple if they were discovered to have planted one is worth potentially billions of dollars in sales, so they will spend a lot of money fighting any such court order (and, as far as we know, such an order has never been successfully made).
The counterargument here is that if the government did win such an order, the backdoor is the gift that keeps on giving, whereas 0days eventually get patched and fixed.
But that's a long digression. For most users, this is simply the wrong threat model.
There was some huge political problem and the Cyanogen company did something the open source guys didn't like, so they left.