NQ Mobile buys cheap installs in under developed countries where there are no in app purchases (Or very low).
The same technique is followed by several Chinese mobile companies. I don't think its well understood why these companies are buying installs and where the money is coming from.
Here are the top ten Tool in India. 8 of 10 are by Chinese companies (Primarily by buying Installs. I am not saying all of them but most of them are). India and China have Conflicts.
Tools is one category that require scary permissions.
It is interesting to consider if this was bred from sloppy ethics or ignorance. It would not shock me to find that someone really thought that this is good enough "security".
That being said, those that do not have the skills to realize that this is not sufficient need to reach out to those that do. If you organization does not have security staff, then a contracted audit is necessary. If someone is producing a product and are trying to claim it is secure, ignorance of what secure actually is, is not an excuse.
Hey let's actually do something about this: go to the play store and leave a 1 star review saying something like "this app doesn't encrypt anything, <non-technical explanation>".
There are already a couple of comments by people who obviously read this article, please upvote them. I mean, you have to install it but I just told it to install it on a phone that broke years ago ;-)
If true, this also shows the TRUSTe privacy seal is worthless. The name implies it's undergone some kind of assessment that showed it's good for privacy when just looking at an encrypted file would immediately show the problem. TRUSTe itself is a bit vague on what they really do.
I can't find NQ in their search tool for certified companies. Perhaps it's been retracted or was never really issued? Maybe I'm looking in the wrong place
Never trust a website just because it has a seal of approval from an organization like TRUSTe.
I routinely perform code and web app audits on companies that proudly bear this seal and find security flaws that will compromise users. The seal means nothing.
Pretty much all the seals you see on the bottom of a website are worthless. Nobody ever does an actual code audit. But it makes the users feel safe, so that's what matters.
I could understand this being a tough position from google's perspective. When talking about how secure something is, one has to consider the threat model - there is not absolute. If the goal is to keep naughty pictures confidential from one's mother - this may indeed be "secure" enough for that situation. Keeping blackmail photos safe from a nation state on the other hand, likely not.
I do not think that we currently have a good way as product creators to specify what secure actually means - and what is more - our customers won't understand the nuance either.
This is in no way trying to excuse passing this "encryption" scheme off as secure.
XOR is the appropriate operation if you're using a stream cipher to generate an arbitrarily long keystream. Or a one-time pad. It also makes random access a lot simpler.
Of course, you do actually need to generate that keystream and not just repeat a short key.
There are very few cases where you should be doing encryption without authentication... and as soon as you're doing authentication you'll be doing more than just xoring with a stream cipher output. :)
It is a Chinese company, so it isn't beyond belief that the Chinese government asked them to make the encryption "reversible" and doing it correctly was behind their technical know-how.
A couple summers ago, myself and some fellow interns were considering looking at android file vault applications as a research project. We downloaded a bunch of the top rated free ones and they were all universally crap. I think the most secure one just ran the entire file through a substitution cipher. There were plenty of others that would just swap the file header with something else, or just XOR the file with some constant value. When I read this blog post, all I could think was "Yeah, looks about right".
"Google it up if you want to: NQ Vault. I don't wanna link it form here."
Please do link it, if only to put your readers 1 click away from giving it bad but honest ratings. Do this also for search engines to find and associate your post with the app. Such bad software needs to be exposed. So here it is: https://play.google.com/store/apps/details?id=com.netqin.ps
Give a man the assumption he is safe and he will lower his guard. There is no reason to not believe the algorithm used is intentionally marketed as safe but is in fact not. From the top of my head I can think of numerous three-to-four character organizations which would benefit from people thinking they have secured their data when they in fact have not.
> I can think of numerous three-to-four character organizations which would benefit
But this encryption is laughably simple. Those organizations would probably encourage at least somewhat better security. From their point of view the best possible situation is if they can read the data but non-state actors can't.
People are downvoting you, but I totally agree. Stop requiring javascript to let me read text: literally the first thing ever put on the world wide web. Fancy your page up with javascript if you must, but let me choose to consume the text how I want.
Since you are new here, I'll explain why I and others most likely have downvoted his comment, and why it's acceptable to do so, regardless of whether I agree with the sentiment or not: it's off-topic, and adds nothing to the discussion in the linked to article. Most importantly, it's essentially complaining that the content is inappropriate.
I have no idea why the blog is fetching a Markdown file via JavaScript from GitHub and then using JavaScript to render it... but at least you get the nice "doge" if you don't have JavaScript enabled.
I beg to differ. A vocal minority of users who are aware of the JS dependency speak up for the unknown subset of users who can't read the page due to an error and don't care enough to investigate.
If a page starts to lag when I'm scrolling on a phone, it isn't worth the CPU cycles, battery life or my frustration to continue using it.
It doesn't even load anything from another domain, so what's the problem with it? That link says that it's "dead to history" which has nothing to do with reading it right now.
The link you gave requires knowledge of the Github API. The original HN link does not give useful page content when cURL'd, and is the same stuff seen when you view source in any browser:
From a decision standpoint, wouldn't sites that require JS to render content be more important to read now, while they're correctly rendering? It's transient information that may not exist tomorrow -- why would you choose to not read it?
Because presumably you're "NR" as a method of punishing the author of the page, but surely you can't think this act is in any way consequential.
I think the author is overreact / grandstand, it's not fair to say this app encrypted nothing - I decompiled the code and found it at least does encrypted the SMS/Call logs data, using AES. Secondly,maybe only XOR the front 128bit for video/image files is not secure enough, but anyone who has a brain knows that, considering the computing power of most Android phone, using strong algorithm to encrypt a whole media(e.g. video) file is hardly realistic, even unwise -- unless you can tolerate a long decrypting decrypting process before playing a video.
BTW, I read through the description of Vault Google Play page, there is nothing says it sales the ability of encrypt data, it just claims to "Hide some xxx on your phone" -- for that purpose XOR is enough
Don't most popular video formats essentially store certain frames as complete images, and then store frame to frame differences to cover the video between frames?
If so, I wonder how effective it would be to encrypt just the complete frames, leaving the frame differences for the in between frames unencrypted?
That would not be very semantically secure; while you could not see exactly what the original image was, you could still make out the movement. That would sort of be the analog of the ECB penguin on moving pictures.
XOR is not, by itself, a problem. Heck, the most secure encryption method on the entire planet, the one time pad[1], is just an XOR of some secret bytes with a plaintext. XOR is also one of two fundamental building blocks of the current state-of-the-art AES-256 encryption algorithm[2] (the other being a series of bit shifts).
The problem here is deriving something so simple from the key, and only applying it to the first 128 bytes. This is unforgivably dumb, when there are perfectly serviceable encryption services available as part of open source libraries, such as the aforementioned AES-256 algorithm.
XOR is only one implementation of one time pad, it is also commonly used with modular addition. If you do it with letters then it effectively becomes a Vigenère cipher with a long key.
The one-time-pad is a special case of any number of poly-alphabetic substitution ciphers, XOR just being one that happens to be implemented on lots of silicon. Considering this is all about an app that has very short keys (a few numeric digits) it's perfectly legitimate to criticise the use of a substitution cipher as they are especially poor when used with short keys compared to real crypto libraries that will use that short key as the passphrase for a real key.
When I said XOR I meant XOR with a one-byte key on every character of input. e.g.
char* xor_encrypt(char* input, char key) {
int i;
int m = sizeof(input);
output = (char*)malloc((int) m + 1);
for (i = 0; i < m; i++) {
output[i] = input[i] ^ key;
}
output[m] = 0;
return output;
}
Well, to decrypt the xor'd data you need to keep the key around. So either you a) memorize the entire one-time pad for every file, or b) you encrypt the one-time pads with AES.
http://www.forbes.com/sites/afontevecchia/2013/10/24/nq-mobi...
link to original muddywaters research: http://www.muddywatersresearch.com/wp-content/uploads/2013/1...