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.
Apple Developer Website Update
141–150 of 223 posts
Re: Apple Developer Website Update
#142Re: Apple Developer Website Update
#143Earlier 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…
Re: Apple Developer Website Update
#144Hmm 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…
... 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
#145Jeez 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…
>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
#146From 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
#147Re: Apple Developer Website Update
#148Re: Apple Developer Website Update
#149Earlier 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…
Re: Apple Developer Website Update
#150Earlier 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.