> intruder attempted to secure personal information
haha "secure". Am so using that word next time my site gets hacked.
Apple Developer Website Update
131–140 of 223 posts
Re: Apple Developer Website Update
#132How is a developer's mailing address not a sensitive information for that developer? How does a tech company get away making a blanket assumption like that?
Re: Apple Developer Website Update
#133This may explain some strange occurrences I had yesterday. Starting at 7am, I received an Apple ID password reset request every 4 hours and 19 minutes, ending last night at midnight. This Apple ID is also the login for my personal developer account (several years old). My developers IDs used for work never received a password reset request.
I highly doubt the hackers plan was to get email addresses and try to brute force from there... just doesn't make sense.
If you search Google, people are all the time receiving password reset emails going back years, even repeated ones.
Email addresses are in the clear all the time, and I've never heard of them being considered sensitive before. You should assume everyone has your email address.
Re: Apple Developer Website Update
#134Is there a database of intrusion attempts (and successful ones too) made at tech companies?
Re: Apple Developer Website Update
#135Manage your Apple ID/password/security questions here: https://appleid.apple.com
What use would changing passwords be if passwords weren't stolen? If you think having your email address out there means you are at higher risk of being attacked, I've got news for you...
They said sensitive information is encrypted and can't be accessed, my interpretation of that is that the plain text can't be accessed but attackers may have the encrypted sensitive information (eg passwords). Depending on the strength of their encryption though, and the key used etc etc.. it might be perfectly accessible. In the absense of transparency on actual encryption details, you're probably better off assuming the data is compromised than not.
Re: Apple Developer Website Update
#136Earlier quoted context omitted.
My argument was that you were impressed by the press-release. Your opinion of Apple was improved such that you made a post in public expressing your admiration of them for telling you that they'd lost some data that you'd entrusted to them. This shouldn't happen. When my 4yr old tells me he did something "wrong" without any prompting (eg. "Dad, I broke your phone"), I'm impressed because he didn't have to out himself…
Your post basically amounts to a conspiracy theory. "It took them 3 days to tell us something happened. Obviously this means they would have kept it secret if it were at all possible." It takes time to figure out what happened in a breach. That doesn't mean that Apple is some evil company trying to hide the fact that there was a breach.
No, I made no mention whatsoever about how long it took them to tell us. Did you even read my comment?
> That doesn't mean that Apple is some evil company trying to hide the fact that there was a breach.
I never said that they were trying to hide anything. Again, did you even read my comment?
> Obviously this means they would have kept it secret if it were at all possible.
Well yes, that is logical. A corporation would keep such a thing secret if they had a guarantee that there was no other way people could find out. There are good people working at Apple, but they are not Apple. A corporation doesn't have morals. It will not damage itself and threaten profits just for fuzzy feelings, any more than it will drop the price of the iPhone 6 to $20 because that would be a good thing for the poor.
Re: Apple Developer Website Update
#137Earlier 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…
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 major drawback would be the same as the benefit. Since you can't know your users' CC numbers, you also can't make recurring charges.
Pipe-dream solution to that -- you should be able to get a token from your payment provider that authorizes you and only you to charge the CC. Should that token leak, you barely even need to revoke it. It can't be used by anyone else, because you need both the token and your company's api secret to charge anything, and even then, all they can do is send (easily refundable) money to your account.
Re: Apple Developer Website Update
#138Earlier 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.
It was down last night though, possibly related?
Re: Apple Developer Website Update
#139Jeez 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 security issue?
Re: Apple Developer Website Update
#140Any idea what "rebuilding our database" means? Reticulating the splines? I hear those go out of alignment sometimes.
There are lots of moving parts in a database, and lots of places one can hide back doors for later access -- triggers, etc. If you're not sure how hard you got owned, nuking, paving, and auditing is usually the best course of action.