Live data from Hacker News

Apple Developer Website Update

news.ycombinator.com

141–150 of 223 posts

Re: Apple Developer Website Update

#141
post #92

Earlier quoted context omitted.

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.

To be fair, unsalted md5 hashes are only one step above storing passwords in plain text.

Re: Apple Developer Website Update

#143

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…

[deleted]

Re: Apple Developer Website Update

#144
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…

>a cut-down version that presents a smaller attack surface

... or simply a cut-down version they know how to run.

"Mhh, what did that old cron job do, again?"

"I don't know; it was written by Mike, he left 3 years ago."

"oh ok, so not important then."

"OMG OUR DB EXPLODED AGAIN! That script was clearly essential! Can you rewrite it??"

"Er, I've looked at it: 2000 LOC of obscure Perl. Gonna take a while..."

Re: Apple Developer Website Update

#145

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 informing people about (potential) security breaches.

Re: Apple Developer Website Update

#146
I got this email about an hour ago. I feel sorry for the folks who are "updating our server software, and rebuilding our entire database". Songs will be sung in the opsen bars about about this battle.

From the sound of the email it suggests they have records of some data (perhaps not sensitive data :-) being compromised but no root cause on how it was compromised, so they are re-building systems from the ground up validating, configuring, and then moving to the next step.There are times where this is faster than spending time trying to root cause the exploit.

That said, this is where privacy and security collide. Since logs going back months of what everyone has done on every system really helps reconstruct things, but of course if you have those logs it means that someone else can abuse them.

Re: Apple Developer Website Update

#147
I got kicked out of an Apple store. I questioned a Managers managatorial expertise. I took his angry picture at the door(Eric in Corte Madera). I am tempted to post it on youtube, but feel punishment enough is working there? Oh yea, the reason he was furious at me, is because I didn't like the way he was treating my salesman. I've never understood people who let a title go to their head? Off topic, just venting.

Re: Apple Developer Website Update

#148
post #80

Earlier quoted context omitted.

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

What use is the list without passwords?

Pretty sure it'd be easy to sell that list for several thousand dollars, over and over.

Re: Apple Developer Website Update

#149

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…

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

Specifically, the magnetic stripe contains the CVV1, which is used for card-present transactions. The number on the back is the CVV2, used for card-not-present transactions.

Re: Apple Developer Website Update

#150
post #99

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…

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.

You do not need the CVV for recurring billing. Indeed, card processing standards explicitly forbid you from storing the CVV at all.
Post reply on HN