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

91–100 of 223 posts

Re: Apple Developer Website Update

#91

Post by 0x0 »

Turing_Machine wrote: post #82
0x0 wrote: 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…

You can install .ipa files easily via http and mobilesafari, and enterprise certs are valid for ALL UDIDs :)

So (again, assuming no revocation), you could set up a web based alternative app store, or re-sign cracked apps/games, or just enjoy being able to run code on your own devices (and distribute to others without going through the app store) without maintaining the $99/year subscription, or you could start linking/redirecting unsuspecting web browsing users to install malicious apps (would only need 1 confirm click)

Re: Apple Developer Website Update

#92

Post by num3ric »

tlongren wrote: post #10
tsm wrote: post #6

These 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…

As I interpreted it, yes, the intruder does have your encrypted data.

I hope you were using good encryption Apple. This guy cracked 400,000 md5 hashed passwords: http://www.youtube.com/watch?v=0WPny7wk960 He says even with password salts, it could be done.

Re: Apple Developer Website Update

#93

Post by Watabou »

larrys wrote: post #70
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.

"why companies tells us DAYS after something serious happened" Companies are people. And all the relevant parties involved in handling this may not be accessible to make a decision as quickly as needs to be done. Or at least quickly enough to satisfy all people. Do you feel you suffered any harm in particular by the delay of three days?

I'm mainly complaining about the delay in telling us anything.

What I would love is an update whenever they suspect an intruder has accessed sensitive information. Many websites like Dropbox and last.fm do have a server status where they tell us if they have any planned maintenance or just general status of the server. Why can't Apple and the rest of the big companies do that?

Also, Apple first said it was just regular maintenance. I'm just confused as to why they said that instead of telling us the truth.

Re: Apple Developer Website Update

#95

Post by pdknsk »

peterkelly wrote: post #86
markdown wrote: post #73

Earlier quoted context omitted.

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…

This isn't about marketing. It's about a security breach. And security breaches take time (> 2 days) to properly investigate and report. It's entirely possible that this is a massive oversight by Apple and they've been extremely negligent in their security policies. It's equally possible that there's some bug (that either you or I could easily have made the mistake of introducing) that's resulted in this being possib…

>> It's about a security breach.

Well, you're very much mistaken. It's not about a security breach at all. If you read carefully, you'll notice it's merely about a "security threat".

:)

Re: Apple Developer Website Update

#96

Post by clarky07 »

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…

names, email adresses, and mailing addresses aren't particularly sensitive. These are all pretty easy to get for most people without hacking anything.

Re: Apple Developer Website Update

#97

Post by agent123 »

jordanthoms wrote: post #24
logicallee wrote: post #15

Earlier quoted context omitted.

That's not a long time to receive a letter like this. That's as fast as Apple instantly responds to anything, esp. considering the weekend. And the site was down, so it was clear something was going on. It is also extremely transparent in the sense that people were wondering this exact thing even earlier today, and now received a response detailing that this is an extremely severe breach, as opposed to something else…

Well I'm giving them a hard time due to the massive schadenfreude, obviously. Still, this is very vague about what the 'sensitive personal information' is (passwords?), what was encrypted, what was hashed, was it using a proper hashing scheme, etc. And announcing it just because people have started to speculate is damage control, not taking responsibility.

Shadenfreude? Do you mean something other than just enjoying their misfortune?

And 'taking responsibility' means solving the problem. They have told us what they are dealing with. What more do you want from them?

Re: Apple Developer Website Update

#98

Post by jacobwcarlson »

_delirium wrote: post #47
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.

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…

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

This is untrue. The magnetic stripe contains significantly more data than what is printed on the card and much of that Discretionary Data (DD) is used during authorization of 'card-present' transactions.

Re: Apple Developer Website Update

#99

Post by dools »

_delirium wrote: post #47
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.

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…

Most banks provide the ability to get a billing token to avoid having to store card details at all. In order to do recurring billing you only need to store the token and the CVV on the back.

Re: Apple Developer Website Update

#100

Post by agent123 »

general_failure wrote: post #94

If anyone thinks this is the complete truth, well be prepared to be fooled many times more. I mean the thing is down for 3 days now. This must be a huge breach.

No. That tells us nothing about how big the breach is. Only how much effort it is taking for them to be confident that they've properly patched it.
Post reply on HN