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

151–160 of 223 posts

Re: Apple Developer Website Update

#151

Post by cmelbye »

tcas wrote: 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.

Re: Apple Developer Website Update

#152

Post by ams6110 »

smegel wrote: post #121
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.

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.

Re: Apple Developer Website Update

#153

Post by EGreg »

jamesaguilar wrote: post #137
X-Istence wrote: post #64

Earlier quoted context omitted.

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…

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…

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!

Re: Apple Developer Website Update

#154

Post by stan_rogers »

nwh wrote: post #122
fleitz wrote: post #88

Earlier quoted context omitted.

Maybe they phoned for a ransom after breaking in? Your post is pure speculation and depends heavily on what Apple means by 'sensitive'. I'm guessing that Apple means your CC numbers, certs, shared keys, etc. Possibly also your support tickets, your bank numbers, etc. As for how encryption works, I'd suggest Applied Cryptography by Scheiner. I think there's a problem in that book about Bob keeping speculative posts to…

I am aware how crypto works. I was commenting on there being no source for a key in this situation, rendering it a fairly useless venture.

In a case like this, there would (normally) only be one secret to find. (IVs, or at least the information IVs are derived from, and so forth would be stored with the data.) That doesn't necessarily make it easy to break if the key was securely handled, but it does make it catastrophic if the key is determined.

Apple's email essentially says, "we don't think they have the key, but..." And a complete investigation, along with changes to the system and an opportunity for users to change data as soon as possible under the new system, is the right way to go about it.

Re: Apple Developer Website Update

#155

Post by michaelxia »

__david__ wrote: post #76
michaelxia wrote: post #43

Thanks Apple! This email was super helpful, now I know exactly whats going on.

I sense some sarcasm here, but I don't get it. Yesterday the site was just down, now we officially know why and have some sense of a timeline. It seems reasonable enough to me—what more do you want?

Then let me clarify...

1) The site was down since Thursday, not yesterday. 2) You can't "overhaul" and expect to deploy "soon", so wtf are you doing apple? 3) "Soon" is not a timeline, at least not in the real world. 4) What info got owned? What could be effected?

Re: Apple Developer Website Update

#156

Post by threeseed »

kybernetyk wrote: post #60
_delirium wrote: post #47

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.

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

Re: Apple Developer Website Update

#157

Post by threeseed »

aaronbrethorst wrote: post #23
kyro wrote: post #13

No reason to be up in arms, folks. They've got the marketing team working on this too.

The marketing team runs the portal. https://twitter.com/chockenberry/status/358310019537715200

Marketing has financial responsibility but engineers still develop and maintain it. And there is lots of cross collaboration with iTunes Store and Apple Online Store teams.

WWDR is all about evangelising the platform to a technical audience. Of course it belongs in marketing and not engineering i.e. it involves road shows, presentations, reach out activities etc. Not everyone that is technical are developers remember.

Re: Apple Developer Website Update

#158

Post by llamataboot »

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…

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

Re: Apple Developer Website Update

#159

Post by threeseed »

_delirium wrote: post #62
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 b…

I've worked on some of those systems. This isn't true.

Most of their web apps are WebObjects/Java apps. Sure some of them would be classed as legacy but it is hardly different from most other enterprise companies. And their systems are completely separate from each other e.g. iTunes, Apple Online Store, ID auth, Developer Portal.

Post reply on HN