Apple Passwords: They All ‘Just Work’

When the Macintosh was released some thirty-odd years ago, to Steve Jobs’ triumphant return in the late 90s, there was one phrase to describe the simplicity of using a Mac. ‘It Just Works’. Whether this was a reference to the complete lack of games on the Mac (Marathon shoutout, tho) or a statement to the user-friendliness of the Mac, one thing is now apparent. Apple has improved the macOS to such a degree that all passwords just work. That is to say, security on the latest versions of macOS is abysmal, and every few weeks a new bug is reported.

The first such security vulnerability in macOS High Sierra was reported by [Lemi Ergin] on Twitter. Simply, anyone could login as root with an empty password after clicking the login button several times. The steps to reproduce were as simple as opening System Preferences, Clicking the lock to make changes, typing ‘root’ in the username field, and clicking the Unlock button. It should go without saying this is incredibly insecure, and although this is only a local exploit, it’s a mind-numbingly idiotic exploit. This issue was quickly fixed by Apple in the Security Update 2017-001

The most recent password flaw comes in the form of unlocking the App Store preferences that can be unlocked with any password. The steps to reproduce on macOS High Sierra are simply:

  • Click on System Preferences
  • Click on App Store
  • Click the padlock icon
  • Enter your username and any password
  • Click unlock

This issue has been fixed in the beta of macOS 10.13.3, which should be released within a month. The bug does not exist in macOS Sierra version 10.12.6 or earlier.

This is the second bug in macOS in as many months where passwords just work. Or don’t work, depending on how cheeky you want to be. While these bugs have been overshadowed with recent exploits of Intel’s ME and a million blog posts on Meltdown, these are very, very serious bugs that shouldn’t have happened in the first place. And, where there are two, there’s probably more.

We don’t know what’s up with the latest version of the macOS and the password problems, but we are eagerly awaiting the Medium post from a member of the macOS team going over these issues. We hope to see that in a decade or two.

40 thoughts on “Apple Passwords: They All ‘Just Work’

    1. This was common on *nix when the length of your password is the maximum OS length. The default algorithm for crypt() was DES, using 8 7-bit ASCII characters; which made 56-bit DES. eg. if the password length is 8, and your password was 12345678, then 12345678a and 12345678abcdef also used to work.

      In essence the passwords were truncated to 8 characters. No warning was given if your password was too long.

      1. This is correct. Within the last few years, I discovered a major VM hosting provider was still using `crypt()` when setting the root password on initial VM creation. Happy to say they were quick about fixing it, I don’t know if they let other customers know they should reset their root passwords.

      2. One of the forums on Hewlett Packard’s site for a long time limited passwords to a max of 8 characters, and IIRC also restricted which characters could be used. I pointed out both the security issues and inconvenience of such limits. They didn’t care.

        A 16 character or more password one can remember, with upper and lower case and at least one number, even without using special characters, is far more secure than an 8 character one that requires at least one upper case letter, one number and one special character. Especially when not so long ago a cracking rig could be built using a few of the then top of the line GPUs to brute force any 12 character password in a few minutes.

        I’d like to see how long C0rrectHorseBatterySt4p!e would take to brute force hack.

    2. I think in older unix the max length of a password was 8 chars; and anything entered after the 8 (if the first 8 are correct) was ignored. OSX probably piggy-backed on the same system.

  1. Even Linux/GNU isn’t immune to these incidents, here’s one account of my experience with a Linux distro:

    As far as I’m aware… there are more versions and spins of Ubuntu than there are stars in the universe.

    I scored a half decent netbook (ultrabook apparently, core i7u 1.xGhz nominal 3Ghz turbo) from the boot-sale with Elementary OS on it.
    First I tried going into su and sudo on both the guest and the non-admin no-password user that was left behind on the machine, I even tried to log in as root (and no password) via a virtual console (CTL+ALT+F2, for example) only to be told incorrect password (so root has a password).

    I then tried the recovery mode expecting the Enter root password for maintenance (CTRL-D to continue) to appear… but instead I was thrown into a root shell.
    From there I done a mount -o remount rw / then added a new user with admin (sudo group) capabilities, rebooted, sudo -s #types password and I was root!!!

    Scored a super cheap Ultrabook,
    had an Ubuntu flavor OS,
    hacked OS due to a security epic-fail.

    1. That all sounds like expected behavior on an Ubuntu-based distro, so no, not an “epic fail”.

      The root user is disabled and has no password, so attempting to log in as root would fail. But single-user mode should drop you right into the terminal with no password required. This is explained in the documentation, of course.

      1. yeah, I remember being able to do that with SunOS.
        Oh, wasn’t it how Evie Nemeth recovered a file she had accidentally deleted?
        IIRC, she put the computer (a UN*X server on the Univ. of Colorado-Boulder) into single user mode, and then wrote a quick program in ed that allowed her to search free nodes until she found the various fragments of her file.
        As Mel Brooks said in “History of the World”; “It’s good to be [root]!”

    2. That’s completely intended behavior. Password on unencrypted drives only keep people from messing with your stuff, they don’t really protect anything, Someone could just as easily boot the computer on a live USB. Having single-user mode just makes it so you can fix things without having to do that.

    3. To those whom say it is as intended…
      Well Intel Management Engine is a sysadmin’s backdoor as intended…

      So I am at a workstation in a government place (Local council… for example) and all the staff have the password to boot the machines (because the HDDs are encrypted)…
      Finds a PC out of view of CCTV whilst another few people wander around doing their tasks…
      Boots into this super secure recovery mode (Just have to type the encryption password) and now I’m root on that machine… installs a back door.

      Yes Intel Management engine and forced password-less root on recovery-mode are good things but have some very short-sighted gaping big holes that even the hardest of encryption cannot stop! Documented or not!

      2018 is SecFail year! (Or Sec-pic FAIL!!!)

      1. “all the staff have the password to boot the machines (because the HDDs are encrypted)…”

        You’ve made your first mistake in the first sentence. Why would the staff have the passwords for fully encrypted drives? Why would the staff be allowed to turn the machines on and off? Why would the computers even be off? Weren’t they performing their scheduled updates and maintenance tasks the night before? If not after business hours, then when?

        This example shows a clear lack of understanding about what it takes to properly secure high-value systems. These are workers who are using company equipment. The computer’s may sit at their desks but they certainly don’t own them, so why would they be allowed to use them as if they did?

        Having no password on a maintenance mode doesn’t matter one way or the other if the environment is so mismanaged that anyone can just sit down at a computer and reboot it into another environment if they wish.

    4. Single-user mode without a password is common on older distros. I used it on the daily to reset passwords and firewalls at my old job (clients loved copy-pasting firewall rules off the internet). It’s unusual for that to be enabled on an Ubuntu flavor though. “init=/bin/bash” is an option for avoiding that password, although the permissions in that state are odd. And of course there are bootable flash drives, and you can just read the drive from another machine.

      Basically physical access = pwnd. Use drive encryption if you’re concerned.

    1. “it just worked” largely on the strength of having a smaller user base, and also that the hardware and software didn’t appeal to the type of people who discovered security vulnerabilities. today not so much.

    2. I just got a new used iMac and guess what? Everything just works. In fact, everything I migrated from a 2007 system just works – except the few things the migration tool said need updates. I went from OS X Lion to High Sierra and everything works better. Apple’s Unix is way more stable than my Ubuntu setups. And the 5K display is – wow.

  2. This reminds me of multi-user login features in Windows 9x. I distinctly remember being able to effectively create new accounts by just typing them in and having full access to other accounts files. Also I’m not sure password checking was implemented without a domain controller to connect to.

    1. Given that 9x would be running on a fat32 filesystem without any sort of permissions passwords were close to ceremonial. If you couldn’t log in as anyone at all you might be unable to do things; but when anyone has the same level of access to all the files there is really only a distinction between ‘can’t log on’ and ‘can log on’ not among different user accounts.

      1. Microsoft did have some additional downloads for 9x that if properly used would harden it pretty good, especially if you wanted to restrict a user to only one or a small number of programs.

        That was often used for kiosks, which usually also had keyboards minus the Ctrl or Alt key just to keep anyone from bringing up task manager.

        Another thing that could be done was replacing the shell (Explorer in 9x, Progman in 3.x) with another program. Want an internet kiosk that cannot be used to run anything else? Replace the shell with a web browser and rename or delete the original shell executable. Then even if someone does manage to stop the shell it just restarts it or reboots. Delete all the DOS executables not required to boot and nothing can be done with that. To really be sneaky, use a hex editor to rename all the built in commands in, just have to find the command name text strings and keep the same number of characters. For example change DIR to DIE, FORMAT to TAMFOR, DEL to ELD, or use something completely different to avoid someone guessing correctly.

        Way back when, with MS-DOS 4, I changed DIR to DIE. After the novelty wore off I changed it back but for a long time after I was still typing DIE. :P

  3. This is yet another example of the lack of ANY clear leadership and direction at Apple since the passing of Jobs.
    Debacle of the continued pathetic iOS updates and MacOS updates lays firmly on the shoulders of the CEO.

    The joker at the helm these days needs to go.


    I wonder though if Jobs Hand picked Cook because he knew he was not capable of running the rock show and that after Jobs death Apple would also die with him.
    Job’s certainly appeared arrogant enough to do it.

    1. There is legal action being leveled against them in Australia to but not at a government level our current pollititical climate is at the extreme edge of pathetic and gutless. At least from the major political parties. So there is no hope for any serious action against them here. Even the so called investigation into the ‘Australia” tax was some kind of joke. Or the collusion of the fuel companies to put prices up just comming into public holidays.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.