nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

back to article
Dumb bug of the week: Apple's macOS reveals your encrypted drive's password in the hint box

Anonymous Coward

That's no bug, it's a feature, what better hint could you ever devise to help you remember your password than the actual password.

It's genius.

113
0
Silver badge

+900Mb does not equal a patch, its an upgrade.

23
1

That's not even wrong

Wait. How do they even _have_ the plaintext password to display there? Shirley they should store that well hashed and with a pinch of salt?

39
2
Anonymous Coward

Re: That's not even wrong

Clearly no unit testing.....

7
1
Silver badge

Re: That's not even wrong

"Shirley they should store that well hashed "

That was my first thought. I think the article hinted that the password was also stored in the hint field at the time it was set or something , ie before it got hashed. Thats the only excuse I can think of anyway.

18
0
Silver badge

Re: That's not even wrong

How do they even _have_ the plaintext password to display there?

They have it in plaintext at the time you enter it to create the volume. The root of the issue is that they've done something like

diskval.hint = null

diskval.pass = buildKey(password)

if (hint)

set diskval.hint = password

createVolume(diskval)

The root cause is probably a copy/paste of a block that checked for and set the password, and then they changed the conditional but forgot to change the name of the variable they were taking data from

15
0

Re: That's not even wrong

I don't think even Shirley can help here. This is clearly a job for Mavis.

5
0
Bronze badge

Re: That's not even wrong

Sounds like Archie Bunker is the new chief of QA at Apple.

4
0
Silver badge

Another advantage is it would really piss the Spanish off.

It's actually a bundle of patches..

0
0
Silver badge
Joke

Its a feature

Hint:

What is the name of your first pet?

Password:

What is the name of your first pet?

It's even got a special character!

Might have to rethink the strategy if they refuse spaces or insist on including a number...

4
0

Re: That's not even wrong

As they said, it's a bug, they intended to store the hint but stored the password. The real password is not in free text.

This has to go down in history as one of the silliest bugs I have ever seen, if it wasn't so serious.

Bug of the week - I think not - maybe bug of the year.

2
0
Bronze badge

Upgrade?

I think you have a typo there. It's possibly an upDATE, but I haven't gotten an upGRADE from Apple in years. Sideways occasionally,. Downwards way too often. But _UP_? Not so much.

(Not to be ungrateful for the bug-fixes, but I really wish they wouldn't bundle them with even more bugs)

1
0
Silver badge

That's what you get

for installing a .0 release.

no matter what OS there re always faults in a GA release. It is common practice to wait until a .1 release before even thinking about upgrading.

20
7
Anonymous Coward

Re: That's what you get

Absolutely.

There is no way I'll go near 10.13 for at least half a year. I may do after I get a dev machine so nuking it would not be a catastrophe, but for my main work machine it ain't happening just yet.

The Apple page on this is shocking, though - in a nutshell, it suggest a full backup, reformat and restore. It appears it is not exactly a *trivial* fix.

19
0
Silver badge

Re: That's what you get

Aaahahaaaaahaaha.

Long live the Apple Reality Distortion Field.

32
9
Silver badge

Re: That's what you get

@J. R. Hartley

Dick.

0
16

Wait, does this mean Apple responded to a Reg request for comment? That is bigger news than these flaws. :)

97
0
Anonymous Coward

Don't get carried away, it's a start, the first tentative steps to rekindling a lost relationship. It'll take time to build on this but one day they might send them the web link to a live product launch video stream.

32
0
Silver badge

You're wearin' down their resistance, boyo! Keep it up!

22
0
Silver badge

"...Wait, does this mean Apple responded to a Reg request for comment? That is bigger news than these flaws. :)..."

Nah just someone new to Apple who hasn't read the "do not correspond with" list. :)

10
0

Re: Apple responding to ElReg / Vulture

Given the spate of non-overtly positive articles recently (EFI, High Sierra, iOS11, Apple Watch LTE, Beats Headphones, iPhone X notch, iPhone general gripes), I thought that Team Vulture had given up and gone full scavenger.

The fact that they got something from an 'Apple spokesperson' is odd; I can only surmise this was an off-day and they caught an intern who was trying to be helpful. Why Apple's email system hasn't yet got a domain rule set to put these requests in a 'pending' folder aka 'Deleted Items' or auto respond with 'No Comment' is also strange.

6
0
Silver badge

Nah just someone new to Apple who hasn't read the "do not correspond with" list. :)

Would that be the same person who said, "I am approving the release of this upgrade since it looks ok to me"?

1
0

No problems here

I had more issues with iOS 11 than High Sierra.

3
5

This post has been deleted by its author

This post has been deleted by its author

Silver badge
Facepalm

Fruity!

That is all.

2
2
Anonymous Coward

To be fair

This is a problem with creating an encrypted disk in Disk Utility, as the problem is not reported to happen when the encrypted disk is created via the command line. Granted, most users are going to use Disk Utility to encrypt their disks, so still a pretty major fail there.

13
1
Silver badge

Re: To be fair

It's more worrying than that.

Plain-text copies of your password are being used and stored. That's just not how you do it. You take the password, hash it like mad - including salting it - and then encrypt using the hash.

If you have half-a-brain, you then use that only to encrypt the REAL key that unlocks the drive, rather than the data itself.

In this way, the password is not stored anywhere. You have to match the salt and hash (which can only come from the password the user types in), to unlock the real encryption key (which can be many times stronger). Nowhere on the disk is stored "My Key Is: ...", only users who know the password can log in, anyone can steal the drive and NOT be able to unlock the key, because the drive isn't unlocked until you've typed in the password, there's no chance of there being remnants of the key stored on that same drive, and you can back up the critical headers which store the real key (and the initial password they were created with) and so recover the drive later if something goes drastically wrong or the user forgets the password they changed it to.

There's a reason that TrueCrypt and all its descendents work like that, as well as any sensible commercial encryption software. Because anything else is snakeoil.

The Disk Manager app should have PRECISELY zero access to the actual password, it should be hashed and salted immediately on entry and only THAT passed to the processes that need it. That fact that there's even a bit of code that resembles "put plain-text password into this structure" means that they did not design the encryption properly, whether or not they slipped up between "password box" and "password hint" box.

3
11
Bronze badge

Re: To be fair

The password isn't being stored anywhere. The hint is being stored. Unfortunately the hint was being set to the password (and the actual hint lost). This happens when the drive is created, not when it is accessed. The code that fetches and displays the hint doesn't know it is the password.

13
0
Anonymous Coward

Re: To be fair

Read and digest before ranting next time maybe?

4
0
Silver badge

Re: To be fair

AND THE HINT IS COPY/PASTE OF A PASSWORD FIELD THAT SHOULDN'T BE ANYWHERE IN PLAIN TEXT.

Literally, they have two variables;

Password

Password Hint.

They have taken plain text from the user, put it into password and that's ended up in password hint by mistake.

But EVEN PASSWORD shouldn't be like that. It should be opening keychain, or it should be hashed and stored and the original immediately disposed of, and it certainly shouldn't be accessible to the disk encryption program. That the password and the hint are handled anywhere near the same way tells you that they're doing it wrong.

The entire PROCESS is wrong, such that a simple error reveals the password. That password shouldn't be sitting in a plain-text field to begin with, such that it can be confused and accidentally written somewhere else.

(Hell, I'd argue the password shouldn't be in memory as a string anywhere... I would code it so that the password box was really just a keyboard-event receiver and for each key hit I would throw the received key straight into the hash function and store only that in RAM. Store the last 50 hash functions to let people backspace (and, yes, stop, them clicking into the middle of the password and typing extra chars, etc.) - show it as a password box with X amount of *'s in it, but only store it as a hash)

0
2
Silver badge
Boffin

Re: To be fair

You take the password, hash it like mad - including salting it - and then encrypt using the hash.

Here is another perfect example of why getting security right is hard.

What you would actually want to do is hash the password, with a random salt (to prevent rainbow attacks against the hash), and then store the hash and salt in order to verify the password. In turn, you would use the password (not the hash) to protect a decent length encryption key, ideally alongside something that also uniquely identifies the hardware (in order to prevent brute force attacks on stolen drives slotted into custom hardware) that cannot be spoofed, such as a master machine encryption key. You then use that key that you have protected with your password to encrypt the contents of the drive. You certainly wouldn't use the hash, which will be stored and accessible and used to validate the password when the user enters it.

2
0

Re: To be fair

I think you have given people some ideas - why not use the hash to encrypt the drive and then you don't have to worry about forgetting the password. Now that is a genius solution :)

0
0
Silver badge
Facepalm

Hint: Pa55word!

I'm thinking that nobody noticed this bug because they were, in fact, using their password as their hint.

35
0

Just another example of Apple copying Microsoft... anyone else remember bob? https://books.google.co.uk/books?id=HCQdypbpZXgC&pg=PA17&lpg=PA17&dq=microsoft+bob+looks+like+you+have+forgotten+your+password+change+it?&source=bl&ots=nqK3Qo1EBY&sig=EcFV4ZbCMJIKfU7Dv4u2AetdND4&hl=en&sa=X&ved=0ahUKEwiDx_uMqdrWAhUJBsAKHZhbBi8Q6AEIJDAA#v=onepage&q&f=false

0
3
Anonymous Coward

Um? Your link is dead.

Also Microsoft was not the first to have disk encryption at all. Windows didn't get built in encryption until bitlocker - which wasn't introduced until either Vista or Windows 7 - Prior to that built in disk encryption has already been added to Linux with LUKS in 2004. No doubt other operating systems had it by that point too.

Of course, there's been third party software also for years which could do it, but it was never "built in" by default.

2
6

Whoosh. That went over your head, AC buddy.

Try this link.

5
0
Silver badge

If you don't "linkify" links, long ones get truncated.

0
0
Silver badge

Problem's with DiskUtility, not ADFS

They seem to have given DiskUtility to a succession of work experience kids. After all, it doesn't do anything important.

The other problem is their QA is bordering on nonexistent.

14
1
TRT
Silver badge

Re: Problem's with DiskUtility, not ADFS

I suspect you are correct. And they also gave them a box of crayons. Usefulness of an iTunes like multicoloured swap space line bar diagram ... ... versus the usefulness of being able to prepare a disk image for restore and re-image a volume from a .dmg, or set up / modify a RAID configuration?

3
0
Bronze badge

Why, what?

Question, why is the password stored at all, anywhere? Shouldn't it be immediately hashed?

This was addressed by clearing hint storage if the hint was the password, and by improving the logic for storing hints.

Improving "logic" for storing hints. I suppose it used to be

if (True) {

Store_Hint(Password.To_Plain_Text());

}

and now its

if (False) {

Store_Hint(Password.To_Plain_Text());

}

else {

Store_Hint(Hint.To_Plain_Text());

}

10
4
Len

Re: Why, what?

There was no logic to store the password but there was logic to store the hint, obviously. Unfortunately the UI (the app, not the underlying filesystem) stored the contents of the password input into the hint field.

The solution that Apple is now applying in the fix will be to test if the volume can be decrypted using the password hint. If it can, this user has suffered from the error and the fix will delete the contents of the hint field. If it can't, this user hasn't suffered and nothing needs to change. Quite a neat approach in the fix tbh.

9
1

Re: Why, what?

That was my first thought but then I realised that now those people no longer have their hint accessible - if they forget the password they are bu99ered?

Wouldn't it have been better to prompt for a new hint next time they used the machine as it was wiping the old one - at the point the user has just successfully entered the password?

6
0
Silver badge

Re: Why, what?

Presumably/hopefully when they blank the hint they'll ask the user to set the hint properly.

This is exactly the sort of bug you'd expect to miss testing. Apple employees doing alpha testing and power users doing beta testing don't need hints, they remember their passwords. The kind of people who forget their password and make use of the hint aren't the type to be testing pre-release software, at least not voluntarily!

11
2
TRT
Silver badge

Re: Why, what?

And Dr David Banner does the Gamma testing. Just don't make him angry. You wouldn't like it when he gets angry.

4
0
Len

Re: Why, what?

Those people never had their hint accessible anyway as the field where it was supposed to be stored was used to store the password instead. Emptying the hint field if it can be used to decrypt the drive still makes perfect sense as nothing is lost while a vulnerability is solved.

But yes, the fix must be accompanied by a suggestion to change your password and add the hint to be on the safe side.

0
0
Silver badge

Re: Why, what?

This is exactly the sort of bug you'd expect to miss testing.

Really? If that's the case then you need to rethink your testing regime. Does the specification for the hint field contain a constraint that it must not contain the password?

0
2
Silver badge

Re: Why, what?

There was no logic to store the password but there was logic to store the hint, obviously. Unfortunately the UI (the app, not the underlying filesystem) stored the contents of the password input into the hint field.

In a proper security design, both the UI layer and the storage layer would be explicitly checking that they hadn't been passed anything in the hint field that could be hashed down to the same as the password hash and; in the UI layer given a message that the password and hash cannot be the same; in the storage layer throw an exception.

In a proper n-layer architecture, as any fule kno, you do not trust the input from the layer above you.

0
0
Silver badge

@Charlie Clark

Even if the code had a constraint that the hint can't contain the password, if they tested the hint you typed in first (to give an error message "the hint cannot contain your password") it would have passed the test. The bug was storing the password in the hint field instead of storing the hint in the hint field, that's something you'd generally do AFTER you've tested the hint because you don't store it until it passes all the test - just like you wouldn't store the password until the user enters one that meets the length/complexity/etc. requirements.

0
0
Bronze badge

Why

Why is this information even trivially retrievable by something running in (what i presume to be) userland?

I have no other relevant words.

7
6

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing