Apple Finally Fixes Unencrypted App Store Login 52
Deekin_Scalesinger writes "More than eighteen months after being first brought to Cupertino's attention, Apple gets around to addressing insecure logins to the App Store. In theory, this could be used to view lists of installed apps and make unauthorized purchases."
Yep, they were sending login information over plain http.
Re: (Score:3)
Would the good ones use rot26(password);
?
easier to do it right the first time. (Score:1)
as my father said, if you can't afford to do it right, how will you afford to do it twice?
Re:easier to do it right the first time. (Score:5, Insightful)
Re:easier to do it right the first time. (Score:5, Informative)
i'm glad they're fixing it, and i'm glad they took the time to do it right.
How do you know they "did it right" this time?
Are you merely assuming that it was coded correctly because it took them so long to issue the fix or have you seen the code? Or do you simply have that much faith in Apple (the very company that thought it was a good idea to send the information over plain HTTP in the first place)?
In fact, if you read the article, "SSL Labs, a report card system from security firm Qualys that rates the quality of websites' HTTPS protections, gives Apple's App Store a failing grade" despite the update.
Re: (Score:2)
In fact, if you read the article, "SSL Labs, a report card system from security firm Qualys that rates the quality of websites' HTTPS protections, gives Apple's App Store a failing grade" despite the update.
And what exactly does that mean?
Re:easier to do it right the first time. (Score:5, Informative)
Re: (Score:1)
Are you merely assuming that it was coded correctly because it took them so long to issue the fix or have you seen the code?
not only have i seen the code, but i wrote most of it!
Re: (Score:2)
i'm glad they're fixing it, and i'm glad they took the time to do it right.
... and it took so long because before Apple, nobody had thought up a way to encrypt data on transmission between a server and a client. So they had to research, and write something that would work. Maybe they might even come up with a patent application ... let's think, what may they call it - maybe something like "secure http"?
A: Because it disrupts the flow of a message (Score:5, Funny)
This is exactly what my ass (Score:5, Funny)
ociate once told me.
Further evidence... (Score:3, Funny)
...that no-one doing anything relevant would choose Apple.
This also explains why Apple has become very popular over the last decade.
Apple's reason for this (Score:5, Funny)
Apple's official statement: "We used plain http because it 'Just Works'."
Re: (Score:1)
Funny but, maybe this illustrates just how overblown this vector is.
I mean, it's one of the largest targets on planet earth, with billions of dollars transacted there.
Re: (Score:2)
I don't know about where you spend your money on the web, but I certainly don't do business with any site that doesn't use SSL at the very least. Exactly where are these 'billons of dollars' being transacted over plain http?
Re: (Score:2)
Re: (Score:2)
SSL only secures the network traffic. It does not ensure that the other end is who you think they are. Nor does in ensure that the other end is honest, or competent for that matter. All it ensures is that the other end has a valid certificate for the domain.
Wait.. what?.. an important element of having a "valid" SSL Certificate is that it's signed by a third party trusted authority (such as Thawte or Verisign) who vouches for the authenticity of the Certificate. So, ideally, SSL does ensure the other end is who they say they are. In theory, anyway.
Granted, it can't vouch for the honesty of said company or any of it's employees. But then again, neither can anything else. I think it's funny my MIL refuses to buy online, she'll call the company instead an
Re: (Score:2)
Oh boy! (Score:5, Insightful)
/. redirects me from https back to http.
So what about that?
Re:Oh boy! (Score:4, Insightful)
Re: (Score:1)
Slashdot doesn't have direct access to your credit card.
It still constitutes the pot calling the kettle black.
Re: (Score:2)
Bullshit, and you're troll-fu is very weak. You aren't buying stuff on /.
Re: (Score:2)
I buy that argument. Oh, wait...
Re: (Score:2)
True. But it is still a good practice to authenticate using ssl.
Re: (Score:2)
Re: (Score:2)
It stays on HTTPS if you're a subscriber. It redirects users who cost them money back to HTTP so they don't have to spend so many CPU cycles.
It's a feature (Score:1)
Not a bug
Typical haters (Score:5, Insightful)
Yep, they were sending login information over plain http.
The author of the original article was very careful with what he did and didn't say. He didn't say that Apple sent login information over plain http. And if you read the support document [apple.com] where Elie Bursztein gets his 15 seconds of Apple fame, you will see that Apple says the update now encrypts "active content". In short, login information was never sent over plain text.
Re: (Score:3)
WRONG SUMMARY (Score:5, Informative)
Login information has always been sent over HTTPS.
However, the app store traffic was not entirely encrypted. This meant that a sophisticated MITM attack could, say, inject a fake login prompt that would capture a user's password.
Bad, too be sure, but nowhere near as bad as TFS makes it seem.
Nice summary (Score:5, Informative)
Yep, they were sending login information over plain http.
Uh, no they weren't. [elie.im]
They were serving mixed content. As a result, the unsecured content was vulnerable to a MITM attack and could be replaced by whatever the hacker wanted—even javascript that pops up a fake password prompt.
But the login was definitely secured; you couldn't get someone's username and password just from captured packets. You could, however, gather certain less-sensitive information, most notably a list of installed apps used for update checks.
It was a big vulnerability, and it's good they fixed it. If only more sites would stop including unsecure content on "secure" pages.
Re:Nice summary (Score:5, Funny)
Yep, they were sending login information over plain http.
Uh, no they weren't. [elie.im]
They were serving mixed content. As a result, the unsecured content was vulnerable to a MITM attack and could be replaced by whatever the hacker wanted—even javascript that pops up a fake password prompt.
But the login was definitely secured; you couldn't get someone's username and password just from captured packets. You could, however, gather certain less-sensitive information, most notably a list of installed apps used for update checks.
It was a big vulnerability, and it's good they fixed it. If only more sites would stop including unsecure content on "secure" pages.
Stop ruining our Apple bashing session with 'facts'.
Re: (Score:2)
If only more sites would stop including unsecure content on "secure" pages.
Even better, just go HTTPS for everything.
Re: (Score:2)
Since every app has to be signed by apple's key, how would a hacker get their software on your phone?
Only thing I can think of is create a jailbreak and try to deploy it via an App Store GUI
Re:Nice summary (Score:5, Insightful)
Since every app has to be signed by apple's key, how would a hacker get their software on your phone?
Only thing I can think of is create a jailbreak and try to deploy it via an App Store GUI
Look, I'm an Apple fan, being a former employee, but that is honestly a naive question, at best.
The point attack vector on you is not tor trojan your iDevice, it is to hijack your account credentials. There are a lot of things you can do with hijacked App Store/iTunes credentials:
(1) Buy a lot of stuff from the store on your credit card associated with the account. Who cares if it's ever installed anywhere, it costs you money and Apple reputation
(2) Astroturf an application to raise its ratings in the store by posting reviews.
(3) Inflate sales numbers for an App; this is similar to astroturfing as well, but along a different axis.
(4) Obtain a portion of your credit card number to obtain credentials elsewhere you have accounts; Apple verifies with accounts wih the credit card number, but uses the very public part of the credit card number, which is why account hijack attacks occur
(5) Deauthorize all your devices
(6) Authorize an additional device; if your slots aren't all full, you aren't going to notice this, and in combination with #1, this will allow them to utilize your account to obtain content for the device
(7) Track the location of your device (and by inference, you), and plan an attack on you, rob your house while you are too far away to get back in time, or just notice that your Mac Latop and your iPhone are in different locations, the iPhone is moving, and then, hey, free laptop
(8) Remote wipe your device(s)
(9) Use "Back To My Mac to remotely access your laptop/desktop system
(10) Authorize and iSync another device, and obtain access to all your personally created content, like your address book contents, business contacts, and in the case of them installing all the Apps you have installed on your device on a similar device, obtain all the personal information in those apps as well from the iSync'ed device
(11) Access your keychain contents using #10, and if one of your devices is a laptop/desktop/in-some-cases-ipad, log in to al the accounts you have elsewhere (including maybe HRBlock.com?) that Safari kindly offered to "Remember my password for this site?" for you
(12) Remote access your camera, if you happen to have an App that can do that.
There. A dozen reasons why it's a bad thing, and that's without breaking a sweat, or pulling in indirect attacks, like the fact that a lot of foolish people tend to use the same login and password everywhere, and once they have it for yourApp store account, they probably have it for other accounts as well.
Nope, they weren't (Score:1)
Yep, they were sending login information over plain http.
Nope, they were not sending login information over plain http, but their store did some information in the clear.