back to article Apple's iOS password prompts prime punters for phishing: Too easy now for apps to swipe secrets, dev warns

Apple, we have a problem. A bug report filed Monday through Open Radar – which mirrors bug reports developers submit to Apple's private bug tracking system – suggests that password prompts in iOS apps can be misused to steal passwords and other secrets. In a blog post today describing the issue, developer Felix Krause, founder …

  1. benderama

    Different keyboards?

    We already get prompted with different keyboards from within apps. With the system already non-uniform I don't see how this will improve anything

  2. Anonymous Coward
    Anonymous Coward

    I just can't help but think it's missing a well coded password hint button.

    1. Adam 1

      elegant solution

      You've got to hand it to the LaserWriter manufacturer. They introduced a

      feature into their password hint that achieves the holy grail of both really helping legitimate users to recall their password and allowing the user to provably tell if the prompt is legitimate or fake.

  3. ThomH

    Or...

    The pop-up says "your credentials are required", tapping takes you from the app to something somewhere in e.g. the system settings, entering your password there takes you back to the app in question. Very hard to fake effectively, besides anything else because the status bar belongs to each application individually, so is part of the transition animation, but individual apps can't animate it individually, and impossible to fake flawlessly as the user will be able to tell if they press the home button.

    It's pretty much only in-app purchases that I can think of where you might be asked to enter your password within a third-party application, so the extra friction wouldn't be a constant hassle.

    1. Pascal Monett Silver badge

      You don't need to fake flawlessly - 90% of users will just go through and input a password, the same way PC users have been trained to click OK on any popup that keeps them from what they intended to do.

      Alerts, checks and information mean nothing when the user doesn't care anyway.

    2. Whitter
      Unhappy

      Overengineering

      Given that a huge swath of folks use the same password for everything, all you need to do is a write an app (or webpage) that requires a password and odds on you've now got it.

      1. Anonymous Coward
        Anonymous Coward

        Re: Overengineering

        Sadly I think you're probably right. I'll bet you'd get at least a quarter of people's Apple ID or Google Play passwords that way.

      2. phuzz Silver badge

        Re: Overengineering

        I know that my mum uses almost the same password for iTunes as for everything else.

        Fortunately though, she won't be caught out by this because she can never remember that password anyway ;)

  4. David 132 Silver badge
    Happy

    Gosh.

    "Apple, as expected, did not respond to a request for comment."

    Awww. Such touching optimism there. So adorably naïve. But hope springs eternal, eh?

    1. Anonymous Coward
      Anonymous Coward

      Re: Gosh.

      It's anyway always proper journalism - always give a chance to comment - if they don't, they can't complain much about what was written later.

  5. Anonymous Coward
    Anonymous Coward

    Level playing field?

    This is way worse than the android overlay problems that only affected older devices, only affected sideloaded apps that needed overlay permission,. Yet this seems have have been downplayed massively in comparison... Go figure...

    1. Lord Elpuss Silver badge

      Re: Level playing field?

      ”At present, the risk is theoretical. Krause said in an email to The Register he wasn't aware of anyone using this technique in the wild... ...a determined developer may also be able to conceal misuse long enough to see the app distributed.“

      Doesn’t sound like this is being downplayed, it sounds like it’s probably not causing harm yet but is something Apple should definitely look at because it’s an addressable risk factor.

      Fair reporting from el Reg. Well done.

  6. Pascal

    One way ...

    To truly differentiate system password prompts from application-generated password prompts (including fake password prompts) would be to include contents in the system login prompt that is selected by the used when creating their account, and is never visible to the App landscape under any circumstance.

    My bank for instance issues a favorite picture selected from a bank of hundreds along with a "personal saying" type phrase that was entirely typed in by me;

    After years of seeing the same picture and text on their login screen, I would say I am phishing-proof (*).

    It would be easy to implement by Apple / Google, and would mean the system login prompt is a "personal" thing that always has the small P.S. note "we'll never ask your password without showing those!"

    Then give it ~5 years for users to train themselves.

    (*) ok, so for varying degrees of "proof", but at least not spoofable unless a seriously bad leak already happened.

    1. Donn Bly

      Re: One way ...

      Actually, if I had your email address and was doing a targeted hack, all I would have to do is go to the login screen at your bank ahead of time and it would present me with your chosen image and personal phrase -- which I could then duplicate and present to you in a spoof.

      Making it more generic, all I would have to do is create a "man in the middle" proxy using a visually similar domain name that accepts your information and validates it against the bank -- querying the bank to get your site identifier and passphrase to echo back to you. Basically the same principle as a reverse proxy isolating backend systems in a DMZ from direct internet access. Once I got a valid confirmation I could display a "password error" and redirect you to the real site, and when your password worked the second time you would just pass it off as a typo and forget about it.

      Using user-defined site identifiers is certainly better than nothing, but it is far from "phishing proof". Always be vigilant. :-)

      Personally, I protect myself against phishing by having each of my banking sites bookmarked, and only visit them from the bookmarks and not manually entered addresses (that way I cannot possibly typo and end up on a site run by a typo-squatter) and never EVER by following a link in an email.

      1. Anonymous Coward
        Anonymous Coward

        Re: One way ...

        Not with my bank. You have to enter a username (not an email address) and then it goes to a different page that shows your image and asks for your password. Though where they fall down is they only gave about 20 images to choose from, so an attacker with a phishing page could just show one at random and fool 5% of people.

        Maybe instead of an image, just let you select a special code that has meaning to you. A series of letters or numbers that is shown along with the real Apple ID, iCloud etc. prompts to let you know "this is a real official password prompt, not some random app trying to hack you". You might select your anniversary, the name of your cat, whatever, even if it is something that could be guessed if someone knows enough about you (i.e. not something you'd want to use as a password) it wouldn't matter for this type of use. The writer of a bad app that made it past App Store review would have no chance of guessing it.

        Even if someone was shoulder surfing you and they saw it, NBD, unless you think they are going to turn around and write an app and install it on your phone to fool you into giving them your Apple ID password.

      2. Robert Carnegie Silver badge

        Re: One way ...

        For this solution on iOS, you wouldn't need to protect against web hacking the secret image that the system uses in its own dialogs, because it isn't being transmitted over a network.

        You might need to protect it from the phone's camera seeing a reflective surface in your room where the secret image can be picked up, but that's a different challenge. Maybe turn off the camera when the password dialog is displayed.

        Also, of course, there's the touchscreen / accelerometer problem.

  7. Lord Elpuss Silver badge

    Correct me if I’m wrong

    But why does Apple allow devs to mimic Apple prompts at all? Is it so difficult to include a message “The current application is requesting your password” in every non-Apple request box? Doesn’t seem like it would be too confusing for the user, and easy to implement too - a whitelist of genuine Apple prompts, and everything else requiring a pw (or to be safe, every prompt which obfuscates text in the manner of a password prompt) gets a warning header.

    Or even color them differently - Apple prompts get translucent grey background, non-Apple app-generated prompts get translucent blue, or translucent red if they are requesting a pw.

    1. Anonymous Coward
      Anonymous Coward

      Re: Correct me if I’m wrong

      Style UX over security.

      1. Lord Elpuss Silver badge

        Re: Correct me if I’m wrong

        Why? It’s not UX over Security, it’s UX supplementing security by clear communication to the user regarding what exactly they’re doing, and where.

    2. Anonymous Coward Silver badge
      Pirate

      Re: Correct me if I’m wrong

      The problem is that it's incredibly difficult to prevent altogether.

      With your scheme, what's to stop the app developer from drawing their own translucent background and prompt? (ie not using the system prompt, just mimicking it with a styled form)

      What it really needs is a header (or similar) telling the user which app has the foreground focus, but that would remove the full-screen functionality so doesn't happen.

      1. Anonymous Coward
        Anonymous Coward

        Re: Correct me if I’m wrong

        If they didn't allow apps any way to write into the status bar area on the X they could use that (turn it red during a password prompt) but they are allowing apps to use that area if they want. Assuming that apps can't control the front flash, they could flicker that, but I'm pretty sure apps that get access to the camera can control the flash.

        I still think the best way is to ask you to provide some sort of codeword like your anniversary or cat's name that will be presented in any official iOS password request, like a challenge/response. A random app won't have access to that codeword, so it wouldn't be able to look like the real thing. Even if it knew the name of your cat, your anniversary and other personal stuff it wouldn't know which of those things you chose, or if you chose nonsense like QWERTY.

      2. Lord Elpuss Silver badge

        Re: Correct me if I’m wrong

        ”With your scheme, what's to stop the app developer from drawing their own translucent background and prompt? (ie not using the system prompt, just mimicking it with a styled form)“

        1) Have a standard form API triggered when textfield.secureTextEntry = true (obfuscates text entry a la password entry. When no default Apple dialog box has been called, display a warning that the app is requesting a password and to be careful. Can be a banner/dropdown notification. Have an option where a user can disable this warning in future for this app (Trusted App) so you don’t end up with UAC-type annoyances.

        1a) As above, but triggered when a dialog box calls (and displays) the AppleID email address combined with asking for input and then obfuscating it. Show a warning that this ”might“ be dodgy and to be careful.

        2) In the vetting process, do a search for known Apple text strings and either forbid them, or flag them for manual attention (probably done already). Machine learning can pick this text up out of images and even concatenated images (have the vetting program call all linked images in an app and combine/permutate to stop nefarious types chopping the image up into smaller pieces (probably not done already). Only way to get round this would be to have a single-pixel image which is called repeatedly to ‘draw’ the text, so the vetting process can look for instances where a small image is called hundreds of times in a modal dialog box and flag that for attention too.

        3) Have a Secure Enclave agent running on the device where form text entry is compared to either the AppleID or the users’ password. Have the Secure Enclave warn when (say) three characters have been entered: “Looks like you’re about to enter your Apple password in a non-Apple dialog - are you sure?”

        I appreciate absolute security here probably requires a draconian approach which will alienate users; and like any security solution it’s a trade-off between safety and convenience. Difficult.

        1. Anonymous Coward Silver badge

          Re: Correct me if I’m wrong

          @Lord Elpuss

          As something of a BOFH myself, I can immediately think of ways around all of your proposed schemes.

          1) A password prompt can be mimicked with a text field and some scripting to replace typed characters with ·, so won't trigger your secureTextEntry routine.

          1a) Prompt user to 'enter your iCloud password' without showing the email address... probably 90% would fall for it.

          2) Download text strings from your servers, rather than embedding in the program.

          3) I would hope that the plain text password is not stored anywhere, but Apple may believe that their Secure Enclave is secure enough, so lets go with it. People re-use passwords all the time, so the annoyance will be too much for Apple to implement. Replacing the text field with a series of one-character fields and switching focus on key-up would almost certainly be enough for the defence systems to see it as different to the password.

          Having a non-controllable part of the screen that shows what program is requesting input would however be trivial. Unfortunately style overrides functionality.

          1. Lord Elpuss Silver badge

            Re: Correct me if I’m wrong

            @AC

            1) Yes PW prompts can be mimicked - but Swift allows for non-standard masking to be flagged (e.g. when text should be mirrored to screen, but isn't - or doesn't have focus). This could/should raise a warning flag during the vetting process.

            1a) If the prompt doesn't contain the AppleID email address, it doesn't look like the standard Apple prompt - which means it's not the focus of the article.

            2) Apple could still check for (imported) suspect strings at runtime using the app sandbox manager, but yes I agree this is a tough one.

            3) No idea on this. The multiple-input-field point is a good one though.

            I wonder if it's possible to monitor screen rastering at runtime to pick up what a prompt looks like irrespective of how it's coded, and flag it accordingly? This would mean that it doesn't matter how deviously the prompt is coded, if it looks like an Apple prompt it'll be flagged.

            PS Having a non-controllable part of the screen would preclude apps from running fullscreen, which is a non-trivial style issue. I can see why Apple wouldn't allow this. And triggering this area only when input is requested would simply mean 'input' will be disguised using any number of the points above.

  8. Valerion

    Oldest trick in the book

    I remember back in the 90s when I were a lad, writing a VB program to mimic exactly the network logon screen on the RM Nimbus PCs we had at school.

    Left it running on the computer the teacher normally sat it, told her I'd forgotten my password. In order to reset it, she logs onto my fake screen which gives her a cunningly programmed "Network error, please restart your computer" error and stores her details in a text file. I then handily remember my password, grab the text file from that computer, deleting it to cover my tracks, and then I had admin access over the whole school network.

    I'm not such a l33t haxx0r any more, sadly.

    1. Lord Elpuss Silver badge
      Joke

      Re: Oldest trick in the book

      Unfortunately you’ve just announced to the world that it was you - there can’t be that many school kids called Valerion...

    2. allthecoolshortnamesweretaken

      Re: Oldest trick in the book

      I dimly remember stuff like that (well, in concept anyway, it's not like there were a lot of GUIs around) from the 1980ies. You'd think by now, etc etc etc

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like