
iOS Privacy: Easily get a user's Apple ID password, just by asking - krausefx
https://krausefx.com/blog/ios-privacy-stealpassword-easily-get-the-users-apple-id-password-just-by-asking
======
tolmasky
When the iPhone X notch was first announced I thought it would be a fantastic
security UI opportunity: What if the top of the screen was only writable by
the system? It would normally be black or show the time, but whenever there is
a password dialog, it turns green with a security lock. This is something I've
wanted on all computers for a while: fundamentally, any computer where you can
get access to the whole screen's buffer means you can fake a logged out screen
asking you to log in, or any other number of phishing attacks. The _only_ way
to prevent this is to have a separate secure screen buffer for a special part
of the screen that the user can use to visually verify the security of an
operation. The notch provided an awesome opportunity for the because: 1) it
was NEW screen real estate, it wouldn't feel like you were acquiescing
existing screen space for this security need and 2) it looks absolutely
horrible when integrated into apps anyways, so why not use it minimally for
good reason instead?

~~~
zacmps
This already exists on Windows (via require Ctrl-Alt-Del) and to a lesser
degree on Android (by always being able to show the action bar in fullscreen).

~~~
andrewla
Not really. From the GP

> This is something I've wanted on all computers for a while: fundamentally,
> any computer where you can get access to the whole screen's buffer means you
> can fake a logged out screen asking you to log in, or any other number of
> phishing attacks.

In Windows, I can render the whole screen, so I can put up a fake login
dialog. To some extent, Windows users are used to requiring a ctrl-alt-delete
before being prompted for a password, but there's no reason why I can't put up
a static image of what the screen looks like during a password request. Having
a portion of the screen which an application is forbidden from accessing would
solve this, but the requirement for full-screen applications that want to
write every user-visible pixel means that there's fundamentally no way to
prevent this attack.

~~~
jychang
No, he's correct.

Ctrl-Alt-Delete on windows is a privileged hotkey that goes directly to the
kernel. A phishing program can't intercept it once it has been pressed. If you
know that Ctrl-Alt-Delete has been pressed, you are already privileged as the
kernel and would be able to compromise a hypothetical protected screen buffer
anyways.

[https://i.imgur.com/BE0xN3i.png](https://i.imgur.com/BE0xN3i.png)

The Windows login screen here doesn't allow you to type in the password until
you press the magical keys that only the kernel can access. This significantly
increases security, since any phishing program that puts up a fake static
image doesn't know when to present the login dialog.

~~~
MichaelGG
Programs can detect Ctrl alt del somehow, because RDP clients do it. But they
can't intercept it.

But a phishing program can just show the enter password screen, without the
ctrl alt del prompt. Few users understand the security need to press ctrl alt
del. And in newer Windows, it doesn't seem to prompt unless you enable it via
GP.

~~~
howellnick
Doesn’t RDP use Ctrl+Alt+End for bringing up the password screen?

~~~
nikbackm
Yes.

------
vortico
This is related to an issue called root-phishing or superuser-phishing. You
can do this with the Windows admin password prompt, the MacOS prompt, or with
Linux sudo, as long as you can run code from a user account or edit a single
file.

    
    
        alias sudo='sudo ./somethingbad; sudo'
    

I'm surprised you don't hear about this that often. There is no perfect
solution, since any visual feedback the operating system can do to make their
prompt "official-looking" is possible by an application as well, unless the
operating system can display information the user would recognize that it not
accessible by the application. A perfect solution on iOS is to "minimize" the
application so that the home screen is shown and _then_ show the password
prompt. The user would immediately recognize the wallpaper and icons to be
theirs, which are two pieces of information unavailable to the application.
However, the application could still fool the user by displaying the box over
the application anyway.

~~~
vbezhenar
There are many solutions. First is requiring un-catchable keyboard shortcut to
enter the password. Something like "ctrl-alt-delete" for Windows (I'm not sure
if it's un-catchable, but you got an idea) or even better some unused key like
pause/break. User will be trained to press this shortcut and app can't
replicate it, so user won't be tricked. Second is using fingerprint. iOS
should just use fingerprint always instead of asking the password (an
exception is first boot or failed fingerprint). Now the case of failed
fingerprint might be exploited, but I think it could be solved too. Require
pressing of "home" button to acknowledge fingerprint. If fingerprint is real,
OS will ignore this press. If fingerprint is fake, OS will just close an app.

Unfortunately operating system developers are not considering this attack. But
they certainly can defend if they want.

~~~
michrassena
I think the idea behind ctrl-alt-delete is that it generates a non-maskable
interrupt that can't be hooked from user-mode. In days past, this sort of
thing was called a secure attention key.

[https://en.wikipedia.org/wiki/Secure_attention_key](https://en.wikipedia.org/wiki/Secure_attention_key)

And you're right, this needs to be a default part of any login handler. Why
don't we use it when logging into a Linux console? The login prompt could
easily be spoofed by a user-mode program.

~~~
caf
The Linux console does support a secure attention key that can't be trapped
and will kill any process which has /dev/console open. root can configure it
with /sbin/loadkeys.

Not sure how distributions tend to configure it by default.

~~~
yorwba
I just looked at the table with _dumpkeys_ , but I'm not sure what I'd have to
look for to identify that key.

    
    
      sudo dumpkeys | rg --only-matching '=.*' | sort | uniq
    

doesn't show anything that stands out, except maybe for Boot and Break. (But I
guess that's a line break?) What would the key do when pressed?

~~~
caf
The key will kill any process with the console open (which should then cause
login to respawn) and log the killed processes.

If you want to test it then this will set Ctrl-Alt-Esc as your SAK:

    
    
      echo "control alt keycode 1 = SAK" | loadkeys

------
smcl
For a while iOS would just seemingly randomly ask me to enter my icloud
password. I’m so used to this that without reading this article I would have
literally fall for this every single time.

~~~
josefresco
I have a _joke_ with my family that I am forced to enter iTunes password on at
least one iOS device - daily. We share one iTunes account, and when you enter
the password on one device, all the others prompt for a password when
unlocked. It's mildly frustrating when you have kids, and multiple iOS
devices.

The scenario goes like this: One of my kids' Messages app stops working
(thanks Apple!). I am forced to turn off/on Messages, and during the process
Apple asks for my password. Then, when I attempt to use my other iOS devices,
I am prompted for the same password ... on ... every ... device. Then, about
20% of the time the password does not "take" and I am forced to ignore and
attempt at a later time.

/rant

~~~
zippergz
An aside, but wouldn’t you be better off with each person having their own
Apple ID and using family sharing to share apps and such?

~~~
ballenf
There's one annoying omission from family sharing: no IAP are included. And
almost every kids game has one. Not talking freemium but just ones with one
free level that gets kids hooked.

~~~
yardie
That doesn't appear to be the case for us. We have sharing and my spouse and
son make IAPs frequently. For him, I'm alerted to authorize the payment.

~~~
ballenf
You can share the payment method, but family members can't benefit from the
"unlock" of the IAP and must each purchase it separately.

~~~
yardie
I believe that is set by the app creator so that users wouldn't try to load
the same subscription under multiple accounts. I'm speaking of the general app
purchases, and family subscriptions we haven't had an issue with.

------
mcphage
Once an OS trains it’s users to enter their password without thinking about
it, because of random (seeming) password prompts, they’re already fucked.
Apple screwed this up on iOS years ago.

~~~
twobyfour
Yup. And if you develop apps and test in-app purchases in their iTunes
sandbox, you will get these CONSTANTLY. Like, every time you change what
network your device is connected to.

~~~
jclardy
Yes. I hate testing in-app purchases, I will never do it on a device I
actually use because it becomes a nightmare, especially if it is a recurring
subscription. Endless password prompts.

------
seanwilson
I think OAuth and single sign on is great but I always thought OAuth had a
similar issue to this. You're on a random website, you click to login via e.g.
Google and then enter your Google password into the login dialog that appears.
It's asking wayyy too much from regular users to be able to tell if this is
safe or not. I'm really surprised there haven't been more phishing attempts
where a fake login is shown which saves your password.

It's an even worse issue in e.g. Android apps that use Google or Facebook for
logins as you can't tell what domain is serving the login prompt like you can
in a desktop browser.

~~~
soared
One of those recent widespread google docs attack used this strategy to get
into lots of business g accounts.

[https://news.ycombinator.com/item?id=14205432](https://news.ycombinator.com/item?id=14205432)

~~~
colemickens
That's rather specifically not the same attack.

One uses the normal OAuth flow and mis-represents a valid application identity
in order to get the user to grant permissions normally. The other flow, that
the grandparent refers to, redirects users to a phishing domain and steals
credentials.

------
Androider
I constantly have to verify my iCloud password, despite having 2FA and Touch
ID enabled. At least once a week on at least one of my three iOS devices. It's
such a constant chore I would probably fall for this phishing attack.

I believe it is because my email address is a relatively common
firstname@gmail.com, and people are trying to recover or guess the password.
Perhaps there's some misguided attempt on Apple's side to increase the
security if there's lots of failed attempts. I also get constant Facebook
recovery attempts (at least they have a "Didn't request this change?" link),
mortgage emails, bills, appointments, intra-family email threads, etc. I don't
think they're malicious, tons of people are just fundamentally unable to type
their email address correctly into a field.

------
iamben
Why not ask users to set a unique phrase to identify themselves when you set
up the OS? If this phrase isn't in the box that asks for a master password,
you know it's phishing. Hell, just put that IN the copy on the master password
box.

"If the words below do not match your unique phrase, do not enter your
password."

If I see "Green eggs and ham", I know it's safe to put in my password.

~~~
eli
It's a good idea, but a security solution that relies on users noticing when
something is absent is not exactly airtight.

~~~
blowski
No solution is airtight, but if it makes it better for 10% of users without
making it worse for the other 90%, it seems like a good idea.

~~~
zwily
My guess is that a large % of unsavvy users would put their password in that
field, making things much, much worse.

~~~
jclardy
Huh? How? Those users would be entering in their passwords in the dialogs
today.

Adding a visual indication of a secure dialog can at least help the power
users, while not changing anything for the ones that don't know the
difference.

EDIT: Oh sorry, I seen what you are saying now - entering password into the
phrase field. Instead, just make it an image that the user selects, or even
creates.

------
ecesena
On iOS the test of pressing the home button and see if the app goes in
background seems a pretty strong one.

Perhaps in a future Apple can make you press the home button as part of the
verification, so it’s kind of implicit.

~~~
jon889
Perhaps when you put your finger on the home button it would read your
fingerprint and authenticate you like that and the user wouldn't have to enter
their password into a box that might steal it..

I can spend thousands using just my fingerprint, but authorising my Apple ID
so I can buy a 99p app or login into iMessage requires my Apple ID password...

~~~
ecesena
It's already like that - I assume the phishing only works for people that
don't use fingerprint, or don't notice the difference.

------
silentOpen
To the author: the double quote characters in your phishing dialog are
straight ASCII " but the quotes in the official dialog are Unicode open/close
double quote characters.

~~~
Luc
Ok, but that's hardly the point...

~~~
marindez
I know Apple uses curly quotes for EVERYTHING so that raises an instant alarm
in my head.

~~~
dx034
In that case you're probably more secure than 99% of apple users. I don't
think more than 1% of iphone users would've noticed the difference.

------
DoodleBuggy
There are so many random popups in iOS to authenticate to itunes, app store,
facetime, icloud, etc that I am amazed widespread phishing strategies don't
already target them

------
pilif
Yes. This is the most horrible UX I have ever seen, especially from a company
as security-sensitive as Apple is. In my experience, none of the mitigations
given by the article are actually helping in some of the cases:

 _> Hit the home button, and see if the app quits:_

if the prompt was caused by some in-app purchase related framework having to
re-check something, then the app will quit and the prompt will go away.

 _> Don't enter your credentials into a popup, instead, dismiss it, and open
the Settings app manually_

if the prompt was related to that in-app purchase, the prompt will not re-
appear inside of the Settings app. If it's because of something else (no idea
what - nothing tells you), then it's still asynchronous and might or might not
appear after a random delay.

Anyways. Overall, Apple is slowly getting better at this, reducing the amount
of magic prompts, though during the beta period and after updates, it might
still happen here and then.

Apple, if you're listening: You need to fix this. Centralise this in Settings
and prompt users to go there. And do everything in your power to not having to
re-prompt the user.

Every time I'm seeing this prompt, I'm wondering where I'm being phished or
not, especially the really bad one that's not listing the Apple ID (my apple-
id is using an apple id specific email address I'm not using anywhere else, so
if I'm seeing the address, it's very, very likely legit).

~~~
adamlett
_This is the most horrible UX I have ever seen_

You must lead a very sheltered existence then ;-)

------
throwaway613834
> But, but, but, why is the . symbol within the ", is this all fake?

Fun fact for those who (like me) didn't know for a long time... technically
"gmail.com." is actually the domain name for Gmail. It's called the _fully
qualified domain name_ (FQDN), akin to an absolute domain name (as opposed to
relative to the current subnet).

~~~
BCM43
Do you have a source for this? I've not heard this before. The Wikipedia
article on FQDN doesn't mention ti.

~~~
throwaway613834
> Do you have a source for this? I've not heard this before. The Wikipedia
> article on FQDN doesn't mention it.

Actually it's right there in the Wikipedia article [1]...

 _The DNS root is unnamed, expressed as the empty label terminated by the dot.
This is most notable in DNS zone files in which a fully qualified domain name
must be specified with a trailing dot. For example,_ somehost.example.com.
_explicitly specifies an absolute domain name that ends with the empty top
level domain label._

[1]
[https://en.wikipedia.org/wiki/Fully_qualified_domain_name#Sy...](https://en.wikipedia.org/wiki/Fully_qualified_domain_name#Syntax)

------
greggman
This is also an issue with in app web browsers. AFAIK an in app broswer's data
can one way or another be completely accessed by the app containing the
browser.

as an example, Tinder requires Facebook login. To do this it launches a
WebView. it could be faking that view to get your Facebook credientials. it
could also just get them direct from the WebView .

I know tons of apps depend on WebViews but I kind of wish there was a solution
. maybe Apple only allowing the WebView to access certain domains and no 3rd
party domains and then requiring the app to actually launch safari not use a
WebView. Of course I suppose that doesn't help as the app can still display a
fake Facebook login.

~~~
scosman
Facebook changed their SDK login behaviour to open the Facebook app, or Safari
if it's not installed. If you see an in-app webview login for Facebook, you
are being phished. However, 99% of users wouldn't know to check for this.

------
Sir_Cmpwn
Dialogs owned by the OS should probably pull the drawer down and display in
there. The simplest way is not allowing the application to access some sacred
part of the UI, and putting system stuff there. Same thing web browsers do.

~~~
pilif
A phishing dialog could fake the drawer. Apps can and do regularly use the
full screen which is something web pages don't do and which will require extra
user confirmation for precisely this reason.

Denying apps full screen access is very detrimental to the overall UX so
that's not going to happen.

The other solution is to have apple never prompt for that password aside of
during the initial setup process after installing an update.

Then you could at least give the advice to never enter your Apple ID-Password
anywhere unless you've just re-installed the OS.

~~~
orbitur
There are other visual solutions: show the app switcher, or go to the home
screen and return when the modal is dismissed. I agree apps can fake some
things, but it's not an unsolvable problem.

~~~
Sir_Cmpwn
Show the app switcher is a good idea. It could make sense visually and would
have information that the phishing app couldn't get (the surfaces of other
apps).

------
dsacco
Okay, that’s pretty slick.

I guess lucky for me I always enter my password in the Settings app directly,
because I don’t know my password and the iPhone won’t let me go to a password
manager when it gives me this popup without warning.

~~~
drinchev
Only password outside of my password manager is the Apple one. Exactly because
I need it so often that it would be really big issue for me if I have to loose
30 seconds every time I want to enter it.

------
have_faith
Isn't this one of the oldest tricks in the book? the following story is
completely made up...

When I was in college me and a friend re-made the win2000 login sequence in
visual basic to play pranks on people. After typing username and password it
pretended to load and then just quit itself so the desktop would show so it
looked like everything was fine. We'd then go in and do the classic "take a
screenshot of your desktop, set it as you wallpaper and hide the icons".

Could apple just make a dialog style unique to OS level prompts? not
foolproof, but you can't customise os blocking dialogs from apps so you
couldn't replicate the behaviour if you tried to fake it.

~~~
raldi
If you had enough access to run your Visual Basic program, didn't you already
have enough access to change the wallpaper and hide the icons even without the
victim's password?

~~~
have_faith
We logged into the machine, ran the app, leave the computer, person A would go
up and "log in", except everything wouldn't be right as it's not their
account, so they just logged out and back in for real. All of the details were
saved on the schools networks drive for later shenanigans like the wallpaper
stuff. It was very basic.

------
wll
detect.location:
[https://github.com/KrauseFx/detect.location](https://github.com/KrauseFx/detect.location)

watch.user:
[https://github.com/KrauseFx/watch.user](https://github.com/KrauseFx/watch.user)

~~~
jtbayly
Without clicking, I have no idea what these links are or why you included them
in this conversation. Care to elaborate?

~~~
LeoNatan25
Other projects by the same person, demonstrating additional potential security
issues.

------
maxpert
I think fix is simple. Just show the icon of app showing the prompt as part of
prompt. I am surprised such apps made through from review process.

~~~
andrewla
That assumes that a phisher would use the system API for creating a prompt.
It's possible for them to draw a dialog that looks just like the system dialog
on top of the regular application chrome. Once Apple has trained a user that
it is ever okay to type this information in, the cat is really out of the bag.

------
rebuilder
Shouldn't this type of password be stored in the devices keychain, which can
be unlocked with the device's auth mechanism, and provides authentication
services without exposing the itunes password to app developers? That is,
authenticate user on device -> verify recipient of auth info -> send auth
message.

I must be missing something since no-one seems to be suggesting this.

------
discreditable
Android already has a decent fix for this. When a Google app needs a password
entered, it shows a notification. An example I run into is when Chrome wants
its Sync Passphrase. I remember long ago seeing something similar when I
changed my account password, but I haven't seen it recently so I don't know if
they're still doing it.

------
zaroth
At least with TouchID I think I've stopped having to ever type my iCloud
password into random popups anymore.

I'm sure there are still corner cases where it would want the literal iCloud
password but I don't remember the last time I saw the prompt, versus before
TouchID the random password prompts were pervasive and discomforting.

~~~
UnoriginalGuy
TouchID has been removed from the iPhone X.

~~~
zaroth
TouchID is replaced by FaceID which I assume likewise eliminates the vast
majority of password prompts?

~~~
seanwilson
Doesn't it have a password/pin fallback though?

~~~
nicky0
Yes, just like TouchID.

------
abalone
As the author notes, the App Store provides a measure of defense against this.
Apps that do this might get away with it at first but will eventually be
discovered and banned.

Plus 2FA also protects you from this. iOS has easy-to-use 2FA and is on a good
trajectory of mainstreaming it and driving adoption. I'm not sure his proposal
for defeating 2FA would work:

 _> even with 2FA enabled accounts, what if the app asked you for your 2 step
code? Most users would gladly request a 2FA-token and ask for it, and directly
pipe it over to a remote server._

I wouldn't give this much credence without a proof of concept. iOS throws up a
dialog when there's a pending 2FA request which consumes the code or cancels
the request, so that would prevent the app UI from intercepting it.

~~~
mcast
I'm not sure how sophisticated the App Store review process is now, but it
would be quite easy to grep the codebase for any UIAlertView with the word
"password" or "sign in" inside it (unless it did some sort of real-time
decrypting of that message).

Regardless, iOS should have a private alert view for inputting sensitive data,
similar to the Touch ID prompt. If the prompt is not even relevant to the app
container, it should also completely minimize the app view to prevent
confusion.

------
LeoNatan25
The only safe solution is for the popup to have a "Settings" button. Anything
else can be faked rather easily due to the fullscreen nature of iOS. Given
enough time and dedication, any overlay or "feel safe" icon can be faked.

------
hellofunk
The reactions I have regarding the urgency of this are:

1) Have there in fact been any known phishing attacks in Apple's App Store
using this method?

2) Wouldn't Apple's app review usually notice something like this before
allowing it into the store?

~~~
pilif
_> 1) Have there in fact been any known phishing attacks in Apple's App Store
using this method?_

no attacks are known. But that doesn't mean a thing. It's very easy to do
this, so you'd have to assume that it is being done.

 _> 2) Wouldn't Apple's app review usually notice something like this before
allowing it into the store?_

no. As the article says, this kind of functionality is incredibly easy to
hide.

~~~
bduerst
Re: 2)

What does Apple review when approving apps?

~~~
tomovo
They can do review-time checks of system calls that show the popup. Look for
keywords in the dialog ("password", "account", "ID" etc). At runtime, check if
a password entered in a dialog matches the user's Apple account password.
Suspend or remove suspicious apps from the Appstore and advise the affected
users.

------
bvrlt
Have you been able to get in touch with Apple about this or were you told to
just submit a radar? Do you have any sense if this is something Apple might
fix sooner now that it's getting some exposure?

------
staunch
The real problem is that apps can get data off your device too easily. An app
that phishes your password isn't actually dangerous until it uploads it to a
server somewhere.

Apple should provide an API that limits an app's internet access in severe
ways, preventing encryption, large uploads, etc. Unrestricted internet access
should be a permission that few apps are granted.

Apps would still find clever ways to exfiltrate data but that itself would be
something you could look for. Today, any app that has access to your data can
upload it to anywhere without suspicion.

~~~
tonyztan
Making apps request internet access privileges seems like a viable idea. Don't
limit encryption though - that's the opposite direction from where we want to
be. It is more important to secure the connections to our devices.

~~~
staunch
You could do TLS for the app, no need for the app to do encryption itself, is
what I meant. That way it's easy to inspect/restrict the data the app is
capable of sending out.

------
korginator
This is not a new problem, and the GlobalPlatform TEE trusted UI goes a long
way to address such a problem.

Though Apple does not officially support the GP TEE, the concept could be
borrowed. Trusted code running inside the secure enclave combined with a
hardware backed indicator for trusted user interactions driven by code in the
secure enclave can help.

This is pretty much how their fingerprint sensor data is protected, via direct
connection to, and control from the secure enclave so that none of the
fingerprint data enters a non-secure zone.

------
calvinbhai
krausefx: the warrior dev who unleashed his weapons on evils iOS app signing
and app store submission processes, now trains his guns on iOS privacy gotchas
:)

Thanks Felix for these works! Hopefully your work on pointing these issues get
the necessary attention from Apple soon!

I have hated those alerts for iTunes passwords so much, and always entered
password from Settings app. But never realized what a security nightmare it
can be for those who are not iOS/Devs.

~~~
krausefx
Thanks, really appreciate your comment. I'm trying my best to raise awareness,
and help Apple protect the user's privacy

------
grandalf
This attack has been obvious for quite some time, it's amazing that Apple
hasn't modified IOS to incorporate a trusted modal for password entry.

------
jakemor
Well written. I wrote a similar article over a year ago here —
[https://medium.com/@jakemor/how-someone-can-steal-your-
iclou...](https://medium.com/@jakemor/how-someone-can-steal-your-icloud-
credentials-642ec93e2352)

It highlights the same exact security issue. The solution is simple: only ask
for passwords in the SETTINGS app. Have the alert route users there.

------
IgorPartola
I remember seeing a research group that was working on creating an out of band
password prompt for desktop computers at NC State. Basically the OS had a
syscall to pause everything the kennel included and a separate module would
basically dim the screen and show the password prompt over what was currently
on the screen. I forget the exact details but it was neat.

~~~
yodon
Perhaps you're referring to Windows? (I'm not trying to be snarky, a lot of
people here genuinely don't use Windows)

System security related prompts have worked essentually as you describe on
Windows since 2001.

~~~
IgorPartola
I honestly don't remember which OS they used, but not this wasn't something
built into any existing OS already. The point was that the code that displayed
the password prompt was outside of the kernel and kernel control entirely. The
UI wasn't the important part, it was that the OS never got access to the
password in the first place.

I imagine if you had a password prompt LED on your device that could only be
lit up by the separate chip that does password prompts, that would help create
an off screen UI.

------
nicetransition
There was a fantastic article last year where Jake Mor exposed this issue,
totally nuts it took so long for iOS to fix this!

[https://medium.com/@jakemor/how-someone-can-steal-your-
iclou...](https://medium.com/@jakemor/how-someone-can-steal-your-icloud-
credentials-642ec93e2352)

------
raldi
Can anyone parse this sentence? I have no idea what it's trying to say:

 _Nope, actually, that 's how the system dialog looks like, the . is within
the "string notation, so I designed the phishing dialog to also include this
little, but very important design detail_

~~~
Fernicia
He's saying on native dialogues, when it lists your Apple ID email address, it
includes a full stop at the end. The address and the full stop both happen to
be in double quotation marks. Many phishers would place the full stop after
the quotation marks, or omit it entirely.

legit -> "bill@apple.com." not-legit -> "bill@apple.com"

But you're right, it's a terrifically difficult sentence to read.

------
bad_user
I never thought this kind of attack is possible on my iPhone — I don't know
why, maybe I was expecting Apple's OS to prevent it.

So I don't remember weird, unexpected password prompts, but I just changed my
password anyway.

The advice on recognizing legitimate popups is pretty good.

------
exabrial
OAuth, 2FA, a control panel to manage OAuth tokens, and decent app policies
fix this problem. A user should never have to enter their password other than
the first time they're setting up their phone. Very preventable.

------
blurryoutside
Easily? First you have to get your malicious app through the review.

~~~
rcruzeiro
And that's extremely easy. The App Store review is not nearly as thorough as
most people think.

------
arrty88
How does the phishing app know my apple ID email address already?

~~~
mmacvicarprett
AFAIK there is no way to obtain the apple id being used, as it would work as
an excellent cross-device persistent identifier. However many people would
just use their email address which you could get asking them to register,
connecting with facebook and other legitimate use cases.

------
f055
I remember having the same idea, but I always thought the password dialog is
distinct from any other dialog available to the app developers. Guess now it
all looks the same :P

~~~
infogulch
All apps have always had complete freedom to draw their UI in any way they
want. Look and feel is completely up to the developer. There's nothing
"special" about the design of system dialogs themselves, it's all just pixels.

~~~
giobox
I see your point, but it is a little bit misleading to say developers have
complete freedom to draw their UI any way they want. You can still have an app
rejected on UI grounds during review. Make an app with a crappy enough UI and
it can be rejected citing the "Substandard User Interface" rule in the App
Store guidelines. What constitutes the meaning of "Substandard" is of course
whatever Apple wants it to be.

------
beepzop
Not sure how feasible this is, but the OS could detect when you've typed your
password into a non-system prompt and present a warning or block of some sort.

~~~
kccqzy
That would be such an inconvenience to the people who re-use their passwords!

/s

------
EADGBE
> But, I have 2-factor enabled, I'm safe, right?

Apple _really_ pushes you to do this in iCloud. For the better.

------
pflats
I think the bigger safety against this isn't that Apple reviews apps, but that
submitting an app to the store requires money up front and some way for Apple
to identify the person behind the account. It's by no means foolproof, but I
imagine it redirects a lot of bad actors to easier attacks.

------
prodtorok
Could easily see this working on the mobile web as well

------
newshorts
What’s next? “How to make a phishing website look like a real website!”

I don’t get how this is an iOS problem, he basically just taught you what
phishing is and happened to use iOS as the example...

------
dingo_bat
Windows has this sorted, albeit in a super annoying manner: UAC
[https://en.wikipedia.org/wiki/User_Account_Control#/media/Fi...](https://en.wikipedia.org/wiki/User_Account_Control#/media/File:User_Account_Control.png)

~~~
dx034
In my opinion less annoying than the iOS password popup. I think in one OS
they appeared very often (Win 7?) but by now I only see them if I want to
execute as admin. And I'm glad how they're designed, it's hard to accidentally
click on them.

------
whipoodle
No, it's usually a Touch ID prompt these days.

------
jsjohnst
Apple does have one mitigation I’m surprised not to see listed. The keyboard
changes color when it’s a system dialog asking for your password. That’s not
something an App can do to my knowledge, but I could be wrong. Any idea why it
wasn’t mentioned?

~~~
Ajedi32
You sure about that? The screenshots in the article don't show the keyboard
being a different color with a legitimate pop-up.

~~~
jsjohnst
On my iPhone it does. It goes from a light grey (normal keyboard) to a dark
grey (system password entry keyboard).

~~~
intoverflow2
Try it in a few more apps it's the choice of the app dev so basically random.

Not that a user should have to know "only enter your password into the black
keyboard", which can also be faked mind.

~~~
jsjohnst
Yes, I know about UIKeyboardAppearance and how apps can influence that, this
isn't what I am talking about. When I say "system password" dialog, I am
talking specifically about requests for my iCloud/iTunes/phone password.
Unfortunately I can't seem to trigger it now, but I distinctly remember in the
past the keyboard looked slightly different than the dark keyboard theme.
Maybe I am wrong!

