The shake that confirmed
macOS's lockscreen shake animation confirms valid usernames without authentication. A disclosure note on why Apple's closure was reasonable, and what the behaviour tells us about UI as an information channel.
The BBC Micros at school arrived in 1984, and they taught something that no teacher explicitly said out loud: the machine's response to what you typed told you as much as the input itself. You learned quickly that PRINT and PRNT produced different error messages, and that the difference in how the computer behaved told you whether you'd understood something or not. Getting a syntax error meant one thing. Getting silence meant another. The response was the signal.
Thirty-nine years later I was sitting at a macOS lockscreen making the same observation. The animation the system plays when you enter a wrong password is not uniform. It depends on whether the system knows who you are.
The finding
Component: macOS lockscreen login window
Behaviour: Entering a valid username with an incorrect password produces a shake animation. Entering an invalid username produces a different response — no shake, or a distinct error path — allowing an observer to enumerate valid local accounts without authenticating.
Prerequisites: Physical access to the locked Mac.
Filed: July 2023.
Apple's response: Expected behaviour. Designed this way. Closed without a fix.
The mechanism is straightforward. When you type a username into the macOS lockscreen and press Return, the system performs a lookup before attempting authentication. If the username is valid, the credential check proceeds — and if the password is wrong, the characteristic shake animation plays. If the username is not valid, the system responds differently: the shake does not occur, or the error is visually distinct. The difference is not subtle. Anyone watching the screen — or operating it — can distinguish the two cases.
There is no rate-limiting on lockscreen attempts. There is no lockout after enumeration attempts. The enumeration is purely observational: no privilege, no API, no special access. You sit at the machine and watch what it does.
What you can learn from it
In a home or small-office environment, the practical utility of this observation is close to nil. You already know who uses the Mac. The interesting scenario is a shared machine — a kiosk, a shared workstation, a Mac in a meeting room or reception area — where the local account names are not publicly known. An attacker with brief unsupervised physical access could enumerate local accounts by observing lockscreen responses to a wordlist of common usernames. That enumeration provides a foundation for a subsequent attack, whether a targeted social engineering effort, a physical shoulder-surfing attempt, or the preparation for a later login attempt when the attacker has obtained a password.
The other scenario worth noting: a machine with multiple local accounts where account names correlate with roles or access levels. Confirming that an account named admin, root, or a known administrator's name exists adds a piece of information to an adversary's picture. It is a small piece. But it is a free one.
Proof of concept
#!/bin/bash
# Lockscreen username enumeration — own machine, own accounts
# Demonstrates the visual difference (no automated exploitation possible without UI)
# Apple confirmed: expected behavior
# This requires physical presence at the macOS lockscreen.
# The observation:
# 1. Lock your Mac (Control+Command+Q or System Settings -> Lock Screen)
# 2. Enter a known valid username + wrong password -> shake animation
# 3. Enter an invalid username + any password -> different response (no shake)
# 4. The difference is visually observable
# This is not automatable without physical UI access -- no API surface.
# The finding is a UI/UX observation, not a programmatic exploit.
echo "Observation: macOS lockscreen shake animation confirms valid username"
echo "Requires: physical access to the locked Mac"
echo "Impact: local username enumeration (Apple assessed: not a security issue)"
echo "Mitigation: display-only lockscreen (no username field) via MDM policy"
# MDM mitigation:
# com.apple.loginwindow MCX key: SHOWFULLNAME = false
# Hides username field entirely; renders finding moot.
# In environments where username field is hidden, users select
# their account from a list -- enumeration is moot by design.Apple's response and honest assessment
Apple closed this in July 2023 with a response characterised as expected behaviour. The lockscreen shake is a longstanding macOS UI convention — it is the same animation the system has used for decades to communicate "wrong password". Changing it would require either removing the distinction entirely (degrading usability) or making both the valid-user and invalid-user paths visually identical (which introduces its own usability and accessibility concerns).
Apple's closure was reasonable. The information disclosure is real — an observer can enumerate usernames without authenticating — but the threat model is narrow. Physical access is required. An attacker with physical access to an unlocked or unattended machine already has a broad attack surface; the ability to enumerate usernames via lockscreen animation adds a marginal capability, not a meaningful step-change. Apple's bounty programme does not treat physical-access information disclosure as a priority finding, and that prioritisation is defensible. The mitigation via MDM policy — hiding the username field and displaying only account icons — renders the finding entirely moot in any managed deployment. For the remaining home-user and small-office case, the threat model barely reaches the threshold of concern.
The finding is real. The animation difference is observable and reproducible. Apple's assessment that it does not warrant remediation is, in my view, also correct. Those two things can coexist.
The deeper lesson from the BBC Micros still holds: the system's response to an input is itself information. When a computer tells you that it recognised your input but rejected your credential, it has already told you something. Whether that something is exploitable is a separate question.
Disclosure note
This finding was submitted to Apple through the Apple Security Research Framework in July 2023. Apple confirmed closure as expected behaviour. No fix is planned as far as I am aware. This post discloses the observation after Apple's confirmed closure. There is no exploit. The observation requires physical access to hardware you own or are authorised to test.
Are you there? The lockscreen shook. That was answer enough.