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

71–80 of 223 posts

Re: Apple Developer Website Update

#71

Post by dakrisht »

"Completely overhauling our developer systems, updating our server software, and rebuilding our entire database."

That does not sound like an intruder "attempt" by any means.

They got hacked, and they got hacked bad if they're rebuilding databases and overhauling entire enterprise-class systems over there.

Transparent my ass. They're deep in the gutter, 3-days and counting no fix, engineers are probably working 24 hours a day and the entire site is still down. This isn't a small time breach folks. They had to go public considering it will probably be down for a few more days...

Re: Apple Developer Website Update

#72

Post by JoshGlazebrook »

wmboy wrote: post #61
_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…

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

Yes, but then you're going to start running into the "don't keep all your eggs in one basket" situation. Sure there are companies out there that will store that information for you, so you don't have to worry about living up to the standards of storing it, but what if that company is compromised? You can't just say "oh they should just let someone else deal with storing that information..." SOMEONE is going to have store the actual information in the end.

Re: Apple Developer Website Update

#73

Post by markdown »

peterkelly wrote: post #26

Good to see some transparency on Apple's part here. I understand this must be a very challenging situation for them to deal with, and I appreciate the notification. As I'm sure many developers feel, I'd like to know more details, but I'm sure these will come in due course.

It's a strange world we live in when every time we're told by a big corp that our personal info was compromised, we're grateful for being told.

This is the worlds most cashed-up corporation. They could buy entire countries, yet they made a conscious choice not to update their server software or hire more competent sys-admins.

There shouldn't be a way for them to gain marketing wins out of this. There should be a law requiring notification when personal information is compromised.

Re: Apple Developer Website Update

#75

Post by peterkelly »

objclxt wrote: post #52
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.

> 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, outdate…

Case in point: http://bugreporter.apple.com still reflects the UI style of OS X 10.0

Re: Apple Developer Website Update

#76

Post by __david__ »

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?

Re: Apple Developer Website Update

#77

Post by 0x0 »

Imagine what you could do here: - break into facebook or twitter or any other high profile dev account - reissue new code signing keys - crack the latest public app and patch in a backdoor - code sign with new keys and submit as an app update

Re: Apple Developer Website Update

#78

Post by nmcfarl »

X-Istence wrote: post #64
_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…

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…

The last system I worked on that actually stored it’s own CCs (Lately it’s been all tokens, all the time, for me) did roughly this with the added, fun, feature no SSH or remote shells on the backend box.

You sent messages to add or charge our client’s credit cards from the front end - on the ultra-simple protocol, to the 1 (!) open network service on the backend. And that’s all the input it took from the network.

If something more complex was needed someone with much higher permissions than I went to the server room and typed into the terminal. Which really minimized attack surface.

Re: Apple Developer Website Update

#80

Post by robryan »

Turing_Machine wrote: post #67
jordanthoms wrote: post #36

Earlier quoted context omitted.

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.

"Give me a list of all registered developers email addresses" is a little harder though.
Post reply on HN