Live data from Hacker News

Apple Developer Website Update

news.ycombinator.com

161–170 of 223 posts

Re: Apple Developer Website Update

#161

Earlier quoted context omitted.

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

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…

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

Re: Apple Developer Website Update

#162
post #112

Earlier quoted context omitted.

How? They took it offline.

Yes, when they discovered it. We don't know for how long they have actually been compromised. Also, imagine if it happens again and is not discovered.

Seems like it's just your imagination: http://www.loopinsight.com/2013/07/21/apple-comments-on-deve...

Re: Apple Developer Website Update

#163

Earlier quoted context omitted.

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…

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

[deleted]

Re: Apple Developer Website Update

#164

Jeez people, a company identifies a hack attempt, stops it, and makes sure it never happens again. How often do you hear that one? Most companies don't even tell you anything happened and if they are forced to, they don't even admit anything bad happened (we only exposed 80,000,000 credit cards, no biggie). If my employer suffered this I doubt they'd even tell the employees. What do all of us do when we find a securi…

The thing that people are getting annoyed at is Apple are claiming this update to be in the name of transparency, even though it's 3 days late and is worded quite poorly. >Most companies don't even tell you anything happened Seeing as you're confident with the "most companies" part, name me 5 big tech companies that suffered a data breach and didn't tell the public, or were forced to. There are laws you know, about i…

You can't have it both ways. They were transparent. Complaining that it was 3 days after the incident is irrelevant since we don't know how much investigation was required for them to understand the problem.

Re: Apple Developer Website Update

#165
wow if they're "overhauling" everything that means Apple knows that hackers got some or all developers' info so it's not just that they can't "rule it out" they just don't want to publicly announce it.

Re: Apple Developer Website Update

#166

Earlier quoted context omitted.

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…

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

Re: Apple Developer Website Update

#167
post #69

Earlier quoted context omitted.

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

Mmmm... maybe. Okay, let's say you can sign code as anyone, even Apple itself, and create rogue apps. Now, how do you use that information to compromise iOS devices? You probably won't be able to get it in the App Store, and the iOS devices won't install from anywhere else. You could make an Ad Hoc distribution package, but for that you need to know the UDID of each device and convince your victim to download the rog…

If you have Apple's code signing keys, you can boot whatever software you want to on an iPhone. This has never been possible outside of Apple, except in the very rare cases of bootrom exploits (see limera1n).

Re: Apple Developer Website Update

#168
> In order to prevent a security threat like this from happening again, we’re completely overhauling our developer systems, updating our server software, and rebuilding our entire database.

I am wondering what was the thought process behind this gem. I think this looks like a knee jerk reaction and it's particularly lacking polish coming from Apple. I mean clearly Apple knows that "overhauling" systems and updating software is no guarantee for future security. It's not a one time fix - it's an ongoing process. And rebuilding entire database - that's just crazy talk! This is especially inexcusable because the target of this update are developers!

Security is hard - you've got legacy crap, 3rd party/unsupported code, you've got open source code and then you have your own code that has evolved to be a Frankenstein. I don't have a problem with Apple getting it wrong once - but the statement does nothing to make developers confident that Apple will finally get web services right.

Re: Apple Developer Website Update

#169

Earlier quoted context omitted.

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…

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

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.

Re: Apple Developer Website Update

#170
post #128

I downloaded the CRL for developer certificates [1] and quickly looked at it using grep: grep -E "Revocation Date: Jul 17 .{8} 2013" wwdrccrl.txt | wc -l 3065 grep -E "Revocation Date: Jul 18 .{8} 2013" wwdrccrl.txt | wc -l 2289 grep -E "Revocation Date: Jul 19 .{8} 2013" wwdrccrl.txt | wc -l 2 grep -E "Revocation Date: Jul 20 .{8} 2013" wwdrccrl.txt | wc -l 0 grep -E "Revocation Date: Jul 21 .{8} 2013" wwdrccrl.txt…

That's because the portal is down and people can no longer log in to revoke their developer certificates.

That's what I thought -- but it was also down the 19th yet 2 were revoked.

Probably means nothing however. I doubt that anybody with the ability to get into the system would want to get only developer certificates.

Post reply on HN