Apple Developer Website Update
51–60 of 223 posts
Re: Apple Developer Website Update
#52Hmm 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.
I know there are people here who probably have been in the start-up space for all of their working life, but never underestimate how piss poor architecture can be at big companies.
I would place a large amount of money that every single person here who has done a stint at a large corporation has a horror story about terrible, awful architecture, outdated practices, and shoddy insecure software. And yes, that includes companies like Facebook, Google, etc.
Re: Apple Developer Website Update
#53I wonder if the hackers managed to get code signing keys out? Ultimate jailbreak?
I highly doubt Apple keeps their master keys anywhere near a public facing web server.
Re: Apple Developer Website Update
#54Is there any other source that this actually happened besides from a guy posting some text on HN?
Re: Apple Developer Website Update
#55Until I see an email from Apple myself I will not see this info as credible.
Received: by 10.50.11.202 with SMTP id s10csp27972igb;
Sun, 21 Jul 2013 16:01:44 -0700 (PDT)
X-Received: by 10.68.172.34 with SMTP id az2mr27321730pbc.201.1374447703980;
Sun, 21 Jul 2013 16:01:43 -0700 (PDT)
Return-Path:
Received: from msbadger0508.apple.com (msbadger0508.apple.com. [17.254.6.162])
by mx.google.com with ESMTP id yo6si9958126pac.15.2013.07.21.16.01.43
for ;
Sun, 21 Jul 2013 16:01:43 -0700 (PDT)
Received-SPF: pass (google.com: domain of developer_bounces@insideapple.apple.com designates 17.254.6.162 as permitted sender) client-ip=17.254.6.162;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of developer_bounces@insideapple.apple.com designates 17.254.6.162 as permitted sender) smtp.mail=developer_bounces@insideapple.apple.com;
dkim=pass header.i=@insideapple.apple.com;
dmarc=pass (p=REJECT dis=NONE) d=insideapple.apple.comRe: Apple Developer Website Update
#56> 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…
Re: Apple Developer Website Update
#57These 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.
Re: Apple Developer Website Update
#58Well 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.
Re: Apple Developer Website Update
#59Starting at 7am, I received an Apple ID password reset request every 4 hours and 19 minutes, ending last night at midnight.
This Apple ID is also the login for my personal developer account (several years old). My developers IDs used for work never received a password reset request.
Re: Apple Developer Website Update
#60Earlier 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…