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

41–50 of 223 posts

Re: Apple Developer Website Update

#45

Post by [deleted] »

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…

[deleted]

Re: Apple Developer Website Update

#46

Post by 0x0 »

Sucker wrote: post #38
0x0 wrote: post #14

Well at least it was "only" the dev center, and not iCloud and iMessage!

It's not uncommon for developers to use the same credentials for both their developer account and their iTunes/iCloud account. I do.

Good scary point (I don't). At least I've pre-emptively disabled Find my Mac to avoid another Wired-like remote wipe. Imagine that being pushed to all ios and mac developers at once!

Re: Apple Developer Website Update

#47

Post by _delirium »

kristofferR wrote: post #39
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…

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

Re: Apple Developer Website Update

#50

Post by lambda »

badclient wrote: post #30
Watabou wrote: post #19

Earlier quoted context omitted.

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.

It can take more than a day to know what happened to your data.

Yes, but it doesn't take more than a day to know that an intruder had accessed the system in a way that may have compromised your personal information.

Basically, once the problem was serious enough that they felt like they needed to take the site down, I'm pretty sure they knew which machines had been accessed (or at least may have been accessed). They knew that some of those machines had developer's personal information. They could have posted as much up front, rather than waiting 3 days to do so.

Post reply on HN