Developer shows how malicious apps on iOS can easily replicate the native system dialog box to phish for Apple ID passwords
Do you want the user's Apple ID password, to get access to their Apple account, or to try the same email/password combination on different web services?
Context & Ripple Effects
Felix Krause's demo lands in a long-running pattern: iOS phishing keeps resurfacing through whatever channel is least policed. Two years earlier, an iOS Mail bug let hackers send phishing emails to steal iCloud passwords with no fix shipped; the same year, scammers were running deceptive security apps and search-ad abuse in the App Store to harvest subscriptions.
What makes this demonstration different is that it needs no bug at all — an ordinary app can draw a pixel-perfect copy of the native Apple ID password dialog inside its own window, so the visual cue users rely on to 'trust' a prompt is forgeable by design. It reframes every later iOS scam vector, from fake crypto apps pushed through TestFlight and Web Clips to [[a:881211|voice-phishing groups abusing Apple's support line to trigger real account-confirmation prompts]], as variations on one problem: Apple's interface itself is the attack surface.
First-order effects
- Any iOS user entering an Apple ID password into a dialog box can no longer verify it came from the system rather than the foregrounded app — the demo works with standard public APIs, so every installed app is a potential phisher.
- Apple faces immediate pressure to change how password prompts are presented or authenticated, since the sandbox rules that protect data do nothing to stop UI mimicry.
Second-order effects
- Because the harvested credentials are reusable across web services, a single spoofed prompt converts one compromised Apple ID into account-takeover attempts elsewhere — pushing security teams at other providers to treat Apple ID leaks as their incident too.
- App Store review gains a new mandate beyond malware scanning: reviewers must judge whether an app's UI could be mistaken for system chrome, expanding what Apple vets before approval.
Third-order effects
- If interface forgery stays trivially easy, platform vendors are pushed toward structural fixes — cryptographically verifiable system dialogs or biometric/hardware-mediated authentication replacing typed passwords — because visual trust cues cannot be patched per-app.
- The recurring pattern across Mail, the App Store, TestFlight, and now native dialogs suggests regulators and enterprises will increasingly treat OS-level anti-phishing design, not just app vetting, as a platform-security obligation.
The trend: iOS attacks keep migrating toward abused trust signals — mail, store listings, enterprise distribution, support flows, and now the system dialog itself — making authenticatable interfaces the next battleground for platform security.