Live data from Hacker News

High Sierra vulnerability exposes the password of an encrypted APFS container

medium.com

1–10 of 11 posts

Re: High Sierra vulnerability exposes the password of an encrypted APFS container

#4

Glass half-full: "Oops! They missed this because they were busy making all the other stuff super-secure." Glass half-empty: "Oh-my-goodness...what would Steve say? FFS. We can't trust anyone any more!" I'm inclined to be half-full.

Glass completely empty: why is the system storing your password when the volume is not mounted so it can be revealed by the dialog?

Re: High Sierra vulnerability exposes the password of an encrypted APFS container

#5
post #4

Glass half-full: "Oops! They missed this because they were busy making all the other stuff super-secure." Glass half-empty: "Oh-my-goodness...what would Steve say? FFS. We can't trust anyone any more!" I'm inclined to be half-full.

Glass completely empty: why is the system storing your password when the volume is not mounted so it can be revealed by the dialog?

Someone probably just mixed up the hash keys for the password field and the hint field. The hint needs to be stored unencrypted so that it can be displayed.

Re: High Sierra vulnerability exposes the password of an encrypted APFS container

#6
post #2

So... it stores the password as a password hint? One must wonder how Apple's QA process didn't catch something as egregious as that in a piece of security code.

Probably some unthinking tester was just using the same string in both fields (e.g. “test”). As a developer I’ve learned over the years not to do that. That tester should have their work attitude adjusted and their methods thoroughly reviewed.

Re: High Sierra vulnerability exposes the password of an encrypted APFS container

#7
post #4

Earlier quoted context omitted.

Glass completely empty: why is the system storing your password when the volume is not mounted so it can be revealed by the dialog?

Someone probably just mixed up the hash keys for the password field and the hint field. The hint needs to be stored unencrypted so that it can be displayed.

Agree. It's probably an issue with the form, nothing underlying. (which means encrypted containers created via the command line should be safe from this vulnerability?)

Re: High Sierra vulnerability exposes the password of an encrypted APFS container

#8
post #6
post #2

So... it stores the password as a password hint? One must wonder how Apple's QA process didn't catch something as egregious as that in a piece of security code.

Probably some unthinking tester was just using the same string in both fields (e.g. “test”). As a developer I’ve learned over the years not to do that. That tester should have their work attitude adjusted and their methods thoroughly reviewed.

There’s probably some easy explanation but why is there a need separate code to store variables for the ssd vs hdd version? I would think this would be high level code, abstracted far away from any hardware differences

Re: High Sierra vulnerability exposes the password of an encrypted APFS container

#9
post #6

Earlier quoted context omitted.

Probably some unthinking tester was just using the same string in both fields (e.g. “test”). As a developer I’ve learned over the years not to do that. That tester should have their work attitude adjusted and their methods thoroughly reviewed.

There’s probably some easy explanation but why is there a need separate code to store variables for the ssd vs hdd version? I would think this would be high level code, abstracted far away from any hardware differences

I believe the SSD vs HDD issue is not about the password hint codepath, but rather that APFS is only supported on SSDs right now.
Post reply on HN