Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
It’s good this security issue was fixed, but the probability that it would be exploited was less than tiny, even on public WiFi networks.

It’s addressed now. Move along and stop worrying.

It’s indicative of extremely poor coding practices at apple. The fact this made it through code reviews (which we hope are being performed!) is not a good indicator of the quality of product they are releasing nor their development practices. Most major bugs start with something trivial like this that is overlooked.
 
What’s surprising is the lack of HTTPS?

For this to work one must have knowledge of the vulnerability then create a fake website and hope the conditions are correct to exploit. Is it possible; yes, is it probable; no
No, the point is another. Not using https denotes a lack of mindset: using https should be a MUST of good practices.

If you don't use https how many other "quick and dirty" there could be we haven't discovered yet (but maybe hackers have)?
 
It’s indicative of extremely poor coding practices at apple. The fact this made it through code reviews (which we hope are being performed!) is not a good indicator of the quality of product they are releasing nor their development practices. Most major bugs start with something trivial like this that is overlooked.
So how does Apple prevent issues like this — not just this specific issue, but Apple’s “poor coding practices” as you stated? In other words, you've determined Apple has bad coding practices, so what do you recommend Apple does to improve? What are your coding design practices that prevent you from ever having security issues or bugs in what you program?
 
Last edited:
  • Disagree
Reactions: Robert.Walter
Was this a zero-day exploit or something discovered by a third-party security organization that was not revealed until after the first was released in a recent iOS update? The vibe I'm getting since there is no discussion of the damage caused by exploit is the latter.

Glad it is fixed. Calm down everyone else. There is no sweeping judgements to made here. Vulnerabilities will happen and luckily it seems to have been found by White Hats first.
 
So how does Apple prevent issues like this — not just this specific issue, but Apple’s “poor coding practices” as you stated? What are your coding design practices that prevent you from ever having security issues or bugs in what you program?
It's not possible but it is fun to shoot from the hip and act holier than thou.
 
  • Like
Reactions: Robert.Walter
It's not possible but it is fun to shoot from the hip and act holier than thou.

It’s worth pointing out this is a little bit special versus most other vulnerabilities.

Apple requires all app developers to send data to and from their apps via https, and if you want to use unencrypted http, you have to file an exemption and give reasons that are checked at the App Store review. Without that exemption, all attempts to communicate via http will just fail.
 
That feature is garbage. "Cool", I thought "I'll be saving on my Dashlane subscription."
Wrong. It's unusable, can't be used on PC.
Also it has these 5 to 6 steps you have to repeat all the time, where Dashlane is seamless.

It's really really bad.

I take it this still has the vulnerability of when sending a device in for repair the techs have unfettered access to all of your passwords, unless you wipe everything out first.
YES AND that !! No master password means anyone can do anything.
 
What’s surprising is the lack of HTTPS?

For this to work one must have knowledge of the vulnerability then create a fake website and hope the conditions are correct to exploit. Is it possible; yes, is it probable; no

I mean, this is an absolute classic. Top ten basic security error for literally decades. Apple themselves rejects apps for not using HTTPS. I believe they require the use of a library that enforces it. The fact that they missed it themselves in a security focused product is worrying.

And there's also the privacy issue. Passwords does not need to send an HTTP request for a favicon to every single website I've ever saved every single time with no option to turn it off.
 
It’s worth pointing out this is a little bit special versus most other vulnerabilities.

Apple requires all app developers to send data to and from their apps via https, and if you want to use unencrypted http, you have to file an exemption and give reasons that are checked at the App Store review. Without that exemption, all attempts to communicate via http will just fail.

This is what makes this bug so baffling. Unless Apple has some unfettered access the rest of us do not you have to put in work to make this bug happen.
 
Last edited:
I didn't think you could even connect to a regular HTTP URL without explicitly stating so. At least, that's how it is for apps in the app store. I'm surprised using non-HTTPS even got through a code review.
 
  • Like
Reactions: sleeptodream
This is exactly why you can’t leave passwords to just being “one of many features” for a mega corporation

The data is too important
 
  • Like
Reactions: wanha
No because it’s so niche and never actually caused an issue.

Unless your mates are salivating over you downloading a picture in your passwords app, it would never get picked up and never be a realistic problem.
It’s not niche. In the video it shows that when you click the link the change your password on an external site in the passwords app, that link was also loaded over an insecure connection and could be intercepted. All throughout their app they were not using secure connections.
 
  • Like
Reactions: turbineseaplane
It’s not niche. In the video it shows that when you click the link the change your password on an external site in the passwords app, that link was also loaded over an insecure connection and could be intercepted. All throughout their app they were not using secure connections.
That's a problem (and it's been fixed), but it is niche. Someone has to be on the same WiFi network or is in some other way acting as a man-in-the-middle to specifically spoof the intended website. That doesn't make it something to ignore (Apple didn't), but it's something that wouldn't have affected many or any people. Again, that's niche -- well, probably less than niche, realistically.

Apple's programmers shouldn't have been using http, just as Microsoft could have forced https connections to live.com, as the team that found this security issue said (comment on their YouTube video): "It's also surprising that Microsoft didn't enforce HTTP Strict Transport Security (HSTS) for its popular domain live.com. Not only Microsoft, we also spotted several other popular services. But we chose live.com for this demo."

That's not to blame Microsoft and not Apple, but this issue isn't only affecting Apple.
 
Last edited:
It’s good this security issue was fixed, but the probability that it would be exploited was less than tiny, even on public WiFi networks. That means the real world implications were negligible. It’s addressed now. Move along and stop worrying about this issue.
True
No because it’s so niche and never actually caused an issue.

Unless your mates are salivating over you downloading a picture in your passwords app, it would never get picked up and never be a realistic problem.
General population sure, however there are criminal groups, governments, and individuals whose job it is to find info about exploits and quickly use them before being reported and fixed. One would hope bug finders all wear white hats and are wealthy enough not to be tempted or threatened by bad actors. Of course that's not the case. After the 26 billion MOAB list it's academic.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.