Hacker News Reader

Comment by jpdoctor | Hacker News Reader

> Sensitive personal information was encrypted and cannot be accessed, however, we have not been able to rule out the possibility that some developers’ names, mailing addresses, and/or email addresses may have been accessed.

So they can't rule out the possibility that sensitive personal information, which cannot be accessed, has been accessed. Got it.

Apparently our intelligence, which cannot be insulted, has been insulted.

View on HN

By "sensitive personal information" they probably just mean passwords and credit card information, not names, email addresses and mailing addresses.

Passwords could be hashed, but credit-cards are the big one you have to keep in plaintext. If you want to bill the card without asking for the number to be reentered, there's no way to avoid storing the number and expiration date. PCI does mandate that you keep less than necessary to initiate a new charge, though: you are not allowed to store the 3-digit verification code from the back of the card. Future charges from the same vendor can go through based on the stored information (without re-sending the verification code), but charges from a new vendor would need the code, so this is intended to make it harder for someone who stole the saved information to initiate a new charge. A loophole is that in-person charges do not use the verification code, so someone could use the saved information to fabricate physical cards, and try to use them at stores (the U.S. doesn't typically use either chipped or PIN-protected credit cards, so cloning a card from the number is relatively easy, prevented more or less only by the heuristic fraud-detection algorithms).

Purchases of developer memberships are handled through Apple's online store. And that is still up.

There also is the bank account information for apple created payments to the developers... that could be part of the compromised items.

That is in iTunes Connect, completely separate from the developer portal.

It was down last night though, possibly related?

Probably took it down to check and patch.

The Apple Online Store is a completely separate system. Different servers, very different codebase.

> ...but credit-cards are the big one you have to keep in plaintext. If you want to bill the card without asking for the number to be reentered, there's no way to avoid storing the number and expiration date.

Not necessarily, if you're using a payment gateway that supports token billing...

Yes, but then you're going to start running into the "don't keep all your eggs in one basket" situation. Sure there are companies out there that will store that information for you, so you don't have to worry about living up to the standards of storing it, but what if that company is compromised? You can't just say "oh they should just let someone else deal with storing that information..." SOMEONE is going to have store the actual information in the end.

When it's the bank that issues you the token, the buck stops there. The bank has the card details anyway.

Credit cards don't need to be kept in plaintext. I'm a big supporter of having the frontend encrypt the data using a public key. The private key is stored only on backend servers.

So now if something needs to kick off a billing process the frontend sends a signal using a defined service method (preferably something so simple that it is secure) and then the backend goes off and decrypts the data followed by doing the actual processing required.

If the frontend and backend are on two seperate networks, and the frontend is only allowed to talk over TCP/IP port 5930 for example to the backend, now you have reduced your attack surface tremendously while making customer data more secure.

The last system I worked on that actually stored it’s own CCs (Lately it’s been all tokens, all the time, for me) did roughly this with the added, fun, feature no SSH or remote shells on the backend box.

You sent messages to add or charge our client’s credit cards from the front end - on the ultra-simple protocol, to the 1 (!) open network service on the backend. And that’s all the input it took from the network.

If something more complex was needed someone with much higher permissions than I went to the server room and typed into the terminal. Which really minimized attack surface.

Couldn't you also do something like this? Store each user's key, transformed in such a way that you could get it back only if you have the password. Serve the key to the user's session on login (maybe -- depending on how long you store the session, you may want to require password reentry to initiate any charges). Encrypt all sensitive data with the user's key, such that only that logged in user can read it back.

The major drawback would be the same as the benefit. Since you can't know your users' CC numbers, you also can't make recurring charges.

Pipe-dream solution to that -- you should be able to get a token from your payment provider that authorizes you and only you to charge the CC. Should that token leak, you barely even need to revoke it. It can't be used by anyone else, because you need both the token and your company's api secret to charge anything, and even then, all they can do is send (easily refundable) money to your account.

Even better - how about simply doing a form of OAuth with the service provider? A token would be authorized for recurring billing or anything else. I think Verified By Visa is an example of something like that...

If such a provider could also SMS you on your chosen # to confirm the purchase then the system would be secure!

> A loophole is that in-person charges do not use the verification code, so someone could use the saved information to fabricate physical cards, and try to use them at stores (the U.S. doesn't typically use either chipped or PIN-protected credit cards, so cloning a card from the number is relatively easy, prevented more or less only by the heuristic fraud-detection algorithms).

This is untrue. The magnetic stripe contains significantly more data than what is printed on the card and much of that Discretionary Data (DD) is used during authorization of 'card-present' transactions.

Specifically, the magnetic stripe contains the CVV1, which is used for card-present transactions. The number on the back is the CVV2, used for card-not-present transactions.

Most banks provide the ability to get a billing token to avoid having to store card details at all. In order to do recurring billing you only need to store the token and the CVV on the back.

I would imagine Apple would not trust the ability to bill its customers to a third party. They have touted their collection of CC numbers for quite a few years, it's treated as an asset to the company.

You do not need the CVV for recurring billing. Indeed, card processing standards explicitly forbid you from storing the CVV at all.

> Future charges from the same vendor can go through based on the stored information (without re-sending the verification code), but charges from a new vendor would need the code, so this is intended to make it harder for someone who stole the saved information to initiate a new charge.

That's not true >"charges from a new vendor would need the code". Online credit card transactions only require a credit card number, expiry month & expiry year. The verification code is optional and is used as a fraud check / deterrent. Payments with an invalid verification code are highly suspicious. Therefore, when Apple (or any merchant) asks for the verification code initially, it passes the initial fraud tests and the card is stored as a "verified card" (or perhaps, only verified cards are stored). Further charges are then most probably legitimate (since it passed the previous fraud check).

What I find slightly unnerving is that Apple didn't make this clearer.

If they know that credit card information was not affected, they should say that. E.g. "Sensitive personal information (such as credit card data) was encrypted and cannot be accessed, ..."

It's reasonable to suppose that 'sensitive' includes credit card information, but as it stands it's something we have to interpret.

I'd suggest we all check our credit/debit card statements more often over the coming days, just to be sure. =)

>What I find slightly unnerving is that Apple didn't make this clearer.

Apple is not a startup. They were ranked 6th in Fortune 500 for 2013. They are going to be rehearsed, political, and vague with their descriptions. Were you actually expecting them to release a postmortem on their blog with a link to the GitHub repo with the fix?

Sure, but I don't think it's a bad idea to raise the median level of expected standards. It seems reasonable to ask for clearer reports and some kind of a postmortem.

One of the hopes for the notion of startups searching / optimizing in these kinds of niche spaces (transparency, communication on a more personal / no-bullshit level, whatnot) might be that these kinds of optimizations will hopefully change what is to be expected from IT businesses in general (at least in terms of communication and so on.) One can at least hope..

If they say X wasn't leaked while it was, they will open themselves for litigation. A company of Apple's size cannot afford to make mistakes there. So, they have to put in weasel words such as "such as".

Also, this isn't a postmortem (yes, we may never see one, it is premature to comment on that _now_)

I do see your point. It just seemed odd to me that they didn't take that simple step to clarify what is arguably the most pressing question on everybody's mind: is my CC/bank data safe?

This is most likely just me being too paranoid and literal, of course. =) In general I'm not too disappointed with how they've handled this - it could've been far worse.

I'm imagining bank account numbers over CC info/passwords was the sensitive part.

Bank account numbers are not secret. If you write a check to someone they have your account number.

Well they are in this weird space of being able to be used to pull money from the account though ACH/demand drafts, so they _should_ be secret, but then as you said they are on the bottom of every check. Which is super weird, and not the case in other countries' banking systems.

I think I would rather someone have my CC number than my home address (which would be the same as my mailing address).

You're not in the phone book, then? County property tax database? I mean, your home address is not exactly something you can really hope to keep secret.

Why?

Credit cards can be cancelled. Home addresses plus other information could be valuable to identity thieves. Maybe it's not that big a deal, but the idea of hackers (criminals?) knowing my name, email and home address seems a bit creepy.

Perhaps if it were a case of a targeted attack I'd agree Identity theft etc doesn't really scale as well as credit card fraud.

"First of all, this does not affect iTunes customer accounts—this is a different system and all iTunes customer information is completely safe, Apple told me.

It’s also important to note that the hacker did not get access to any app code or even the servers where the app information was stored. The hacker also did not get access to any credit card information.

The only thing that the hacker could have gotten access to was the names, email addresses and mailing addresses of the developers. At this point, Apple doesn’t know if the hacker even managed to see that information. Worst case, that is all the information they would have seen, according to Apple."

http://www.loopinsight.com/2013/07/21/apple-comments-on-deve...

Alternately, inside the reality distortion field developers’ names, mailing addresses, and/or email addresses is not sensitive personal information.

Anyone who has my name can find my email address with a simple Google search. My mailing address is on all kinds of public records.

"Give me a list of all registered developers email addresses" is a little harder though.

What use is the list without passwords?

Spear phishing

Spamming them with something that may interest iOS developers.

Pretty sure it'd be easy to sell that list for several thousand dollars, over and over.

How are names, mailing addresses, and email addresses sensitive personal information?

I would imagine that for most of the people signed up, it wouldn't be that hard to track down their name and email just from knowing the name of their app.

Name and e-mail, I'm kinda with you. Everyone who uses my app knowing my current mailing address I look at a little bit different.

If by "reality distortion field," you mean the legal community, then yes. Having been through something similar recently, the lawyers will likely be making sure everyone involved understands the concept of PII: https://en.wikipedia.org/wiki/Personally_identifiable_inform...

One of the understood requirements of publishing an app on the App Store is that developers must provide some means for customers to contact them directly (support page, email address, etc). If you're selling apps on the app store, people can already peddle their wares to your email account.

So yeah, developer's names, addresses and emails are not secrets by any means. Why would anyone buy an app from someone they had no means of identifying?

iOS developers != App Store vendors. There are plenty of developers who work on other people's apps for a living.

names, email adresses, and mailing addresses aren't particularly sensitive. These are all pretty easy to get for most people without hacking anything.

Apple apparently doesn't agree that, in context of the data they have on you, your name, mailing address or email address qualifies as sensitive.

"The intruder had good intent with trying to "secure" our personal information. But despite nothing being hacked, as it was only a 'threat', we still need to tear down and build up the system from scratch again. In the spirit of transparency we've waited 72 hours before giving you this nonsense bullshit. Please note that some (that is all) of you will from now on get regular viagra offerings in cyrillic. Good for you!"

  secure
  verb [ with obj. ]
  
  2 succeed in obtaining (something), especially with difficulty

Reply on news.ycombinator.com