Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Developer Website Update

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 223 posts

Re: Apple Developer Website Update

#61

Post by wmboy »

_delirium wrote: post #47
kristofferR wrote: post #39

Earlier quoted context omitted.

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 fro…

> ...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...

Re: Apple Developer Website Update

#62

Post by _delirium »

pdknsk wrote: post #16

Hmm so it only takes a few days to "completely overhaul" their developer systems? Not sure I believe this is what they're actually doing. And why haven't they updated their server software before? I know mistakes can never be completely avoided, but this seems slightly amateurish for a company with so much cash.

There was some discussion in previous threads about how their systems seem (like many others, to be fair) to be a taped-together mess of old perl scripts and server-side includes and CMSs and who knows what else. So they're probably trying to come back online with a cut-down version that presents a smaller attack surface and contains only components that have been vetted in the last 10 years, which is overall not a bad idea.

Re: Apple Developer Website Update

#63

Post by [deleted] »

_delirium wrote: post #47
kristofferR wrote: post #39

Earlier quoted context omitted.

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 fro…

[deleted]

Re: Apple Developer Website Update

#64

Post by X-Istence »

_delirium wrote: post #47
kristofferR wrote: post #39

Earlier quoted context omitted.

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 fro…

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.

Re: Apple Developer Website Update

#65

Post by Turing_Machine »

0x0 wrote: post #53
RKearney wrote: post #49

Earlier quoted context omitted.

I highly doubt Apple keeps their master keys anywhere near a public facing web server.

The dev center seems to be able to autogenerate code signing certificates at least. But maybe those can be revoked via online checks. I wouldn't mind having a wildcard enterprise cert with a 20 year expiration =)

Access to an API to get certificates from a different server one at a time is different thing from having the actual private signing key.

Re: Apple Developer Website Update

#67

Post by Turing_Machine »

jordanthoms wrote: post #36
jpdoctor wrote: post #29

> 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 in…

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.

Re: Apple Developer Website Update

#68

Post by peterkelly »

I understand everyone's frustrations with this, and the fact that Apple haven't been immediately clear on exactly what happened. As a developer, I too am alarmed by what has happened.

But these things are complex, and it takes time (i.e. a few days) to fully and properly evaluate what has happened and what information leaks/security breaches have occurred.

Let's give this a reasonable amount of time, and only then pass judgement on their handling of the case.

I don't want to appear like an Apple apologist - and maybe it is a serious fault on their side. But in fairness I do think it's reasonable we give them time to evaluate & respond appropriately.

Re: Apple Developer Website Update

#69

Post by 0x0 »

Turing_Machine wrote: post #65
0x0 wrote: post #53

Earlier quoted context omitted.

The dev center seems to be able to autogenerate code signing certificates at least. But maybe those can be revoked via online checks. I wouldn't mind having a wildcard enterprise cert with a 20 year expiration =)

Access to an API to get certificates from a different server one at a time is different thing from having the actual private signing key.

Certainly, but an unrestricted code signing certificate would be quite useful too (until they are revoked)

Re: Apple Developer Website Update

#70

Post by larrys »

Watabou wrote: post #19
tsm wrote: post #6

These details are befuddling. "Personal information was encrypted and cannot be accessed". It can't be accessed because it's somehow stored elsewhere, or it can't be accessed because of the encryption? That is, does the intruder currently own my encrypted data? I'm also disappointed that it took them 72 hours to tell us anything, and that the update doesn't even have a timeline for when the site may be back. "Soon" i…

Yeah I'm confused why companies tells us DAYS after something serious happened as opposed to right away. I can understand waiting a day but 3 whole days?! I just don't understand the delay. It's our data, we should have the right to know what happened to it.

"why companies tells us DAYS after something serious happened"

Companies are people. And all the relevant parties involved in handling this may not be accessible to make a decision as quickly as needs to be done. Or at least quickly enough to satisfy all people.

Do you feel you suffered any harm in particular by the delay of three days?

Post reply on HN