[jokull]

Hi Hacker News. I’m one of the developers at QuizUp. We’re very proud of the product, but obviously we missed the mark when it comes to privacy and user data. On a cultural level we take these things to heart, and we take them seriously. It’s a matter of not having taken the time to review these things carefully enough.

Let me address the things mentioned in the article:

No data is ever sent or received to or from our servers in plain text. Due to a bug in our third-party network library the certificates were not being verified so a self signed certificate could decrypt the data. This issue has been addressed in an update waiting review at Apple. Users' passwords are hashed before we store them in our databases (pbkdf2, salt, multiple iterations).

Our user's address books are not stored on our servers and only used temporarily to help us find your friends. It was a mistake to not hash the contents of the address book before sending to our servers and we are currently changing the client application so it hashes the address book contents before sending to our servers.

Sensitive user data was exposed in certain endpoints (although only accessible for authenticated users). We have already addressed this issue in a server deployment and the hotfix is live now.

We are currently wading through inboxes looking for Kyle’s outreach. It looks like it may not have reached the core server developers. Please contact me personally at [e-mail] if you have questions.

Finally I want to thank Kyle Richter for working out our security holes, small and large. We’re currently reviewing our endpoints and codebase to further harden security and ensure the privacy of our users.

[riquito]

You make it sound like there are a couple minor bugs. What about the addresses of the users sent away? "only accessible for authenticated users": which means everyone.

From the home page "Play against friends in real time": this is a false advertising at best. Also, is it written anywhere that people can play against bots?

"We're sorry" would have been a better start

[ddoolin]

I don't understand how that's false advertising at all. I definitely have played with friends in real time, many times. That's just not the ONLY case.

I think most users with half of a brain can figure out that not all matches are real time. If you challenge a friend, it clearly tells you that you can play the match without them and they can play against "you" when they get around to it.

A really acknowledging response was given -- would those words really make that much of a difference?

[jokull]

We are very sorry for not treating our users’ private information more carefully.

In QuizUp you are playing a human in real time in almost every game. In the off chance we cannot find an opponent (which is becoming very rare due to our popularity) you may be pitted against a bot as a fallback strategy. Matchmaking is a hard technical problem, and we have chosen to maximize gameplay experience and consistency. I’m happy to share that the ratio of ghost games to real ones is getting very small! Hopefully we will be able to phase them out completely in the future.

[alandarev]

Good catch. Sadly the "We are sorry" for being careless reminds me of a "BP - we are sorry" incident.

There is no cost for a faceless company to be 'sorry', and only prmotes the further unethical actions by other companies. I would rather see them pay the fine for privacy breach.

Moreover, this all goes down to the apps requiring ALL permissions to run, why is that acceptable? Why is QuizUp allowed to see user's location in first place?

To me, it feels like making stalker's life easier than ever. Make an app displaying cats, set it require full permissions, put on App Store.

[jokull]

Geo coordinates are acquired from user via the iOS location permission. It is persisted in an ElasticSearch index for the "Nearby" leaderboard.

[loopdoend]

Simply verifying the certificate is not enough, it is simple to decompile and reverse-engineer an IPA to bypass certificate checks.

You should NOT be sending such sensitive information on other users, encrypted or not. Unless of course you want to continue this trend of violating your user's privacy.

[e28eta]

Given access to the device, I find it much easier and simpler to install my own Certificate Authority than to decompile and modify the IPA.

The CA can also be provided in a .mobileprofile, installable through email.

It also validates as a legitimate certificate, unless the app is looking for a particular certificate, which I think is rare.

[jokull]

To clarify, sensitive information is no longer transferred at all. This was hotfixed earlier today.

[nona]

my impression is the OP is a bit loose and ambiguous in the some of the terms used like "plain text" and "local" etc; and the TC article makes the confusion worse.

So just for the record, are these all of the actual issues?

  - no SSL verification means it's trivial to MITM
  - exposure of other player's emails/bio/birthday/location/exif data in pics
  - address book data is sent unhashed to the server
  - signup emails expose the cleartext password (is this right?)

All important issues, and I'm assuming you've corrected these.

But the way I understand it, there's no reason or way to protect the client from the user him/herself - custom CA install, decompilation, etc are all ways for the user to get to their own data, or their own communication with the server.

So I'm a bit at a loss why the TC article is hammering on the "… and the local file which contained user information did not require any decryption to read."

The OP also mentions the FB tokens being exposed and such - I'm assuming these are only sent over SSL, and other people won't have access to it (with the caveat of the SSL fix), right?

[jokull]

- Yes. The certificate chain will be embedded in the client in the next release to mitigate this.

- We haven’t stripped EXIF data from uploaded pictures, although this is on the roadmap. Sensitive fields from user profiles have been stripped from all endpoints. This was done before the news hit TechCrunch.

- We were never saving contact lists, just using to cross reference our user database. In the next update we will compare hashes, not plain text emails.

- No passwords are ever stored in plain text, but they are transmitted over SSL during signup and login. We are considering ways to further obfuscate this, but strengthening SSL goes a long way. Please contact me at [e-mail] if you have comments or questions about our password policy.

You are right about the Facebook access tokens. The tokens are sent over SSL and we are not breaking any usage guidelines from Facebook. Access tokens can of course be invalidated by the user, or by Facebook. We are open to further enhancing the security of our OAuth flow, but currently it has not been exposed to any security weaknesses.

[Quarrelsome]

> Due to a bug in our third-party network library the certificates were not being verified so a self signed certificate could decrypt the data.

Finally, now the TC article makes sense. Someone told me the guy that found the exploit works for one of your competitors. ;).

[skj]

You mean, the author of the article who disclosed that from the beginning?

[Quarrelsome]

Ah I didn't notice the disclosure so much as I skimmed the start looking for the technical details. Still strikes me as somewhat cynical though.