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

Apple on Thursday released a security patch for macOS High Sierra 10.13 to address vulnerabilities in Apple File System (APFS) volumes and its Keychain software. Matheus Mariano, a developer with Brazil-based Leet Tech, documented the APFS flaw in a blog post a week ago, and it has since been reproduced by another programmer, …

Page:

  1. Anonymous Coward
    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.

    1. macjules

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

      1. CrazyOldCatMan Silver badge

        Another advantage is it would really piss the Spanish off.

        It's actually a bundle of patches..

      2. Mike 16

        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)

    2. scarletherring

      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?

      1. Anonymous Coward
        Anonymous Coward

        Re: That's not even wrong

        Clearly no unit testing.....

      2. Prst. V.Jeltz 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.

      3. Ben Tasker

        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

      4. enormous c word

        Re: That's not even wrong

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

        1. herman

          Re: That's not even wrong

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

      5. rsole

        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.

    3. Whitter
      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...

  2. Steve Davies 3 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.

    1. Anonymous Coward
      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.

    2. J. R. Hartley

      Re: That's what you get

      Aaahahaaaaahaaha.

      Long live the Apple Reality Distortion Field.

      1. Lord Elpuss Silver badge

        Re: That's what you get

        @J. R. Hartley

        Dick.

  3. Tomislav

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

    1. Anonymous Coward
      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.

    2. Mike Moyle

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

    3. TonyJ

      "...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. :)

      1. macjules

        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"?

    4. davemcwish

      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.

  4. danielanthony

    No problems here

    I had more issues with iOS 11 than High Sierra.

    1. This post has been deleted by its author

  5. This post has been deleted by its author

  6. PNGuinn
    Facepalm

    Fruity!

    That is all.

  7. Anonymous Coward
    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.

    1. Lee D 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.

      1. Brangdon

        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.

      2. Anonymous Coward
        Anonymous Coward

        Re: To be fair

        Read and digest before ranting next time maybe?

        1. Lee D 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)

      3. Loyal Commenter 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.

        1. rsole

          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 :)

  8. Kevin McMurtrie Silver badge
    Facepalm

    Hint: Pa55word!

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

  9. Bug71

    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

    1. Anonymous Coward
      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.

      1. Timmay

        Whoosh. That went over your head, AC buddy.

        Try this link.

      2. Jamie Jones Silver badge

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

  10. Dan 55 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.

    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?

  11. hellwig

    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());

    }

    1. 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.

      1. Mystereed

        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?

        1. Anonymous Coward
          Anonymous Coward

          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!

          1. 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.

          2. Charlie Clark 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?

            1. Anonymous Coward
              Anonymous Coward

              @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.

        2. 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.

      2. Loyal Commenter 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.

  12. fobobob

    Why

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

    I have no other relevant words.

Page:

POST COMMENT House rules

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

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like