Standard password recovery involves sending a password reset mechanism to the user; either to email, sms or telephone call. However, if a phone has been stolen the thief has full access to these services, making the use of such a service not especially secure.

Memorable questions etc are not ideal, because they can be guessed (especially as the thief theoretically has access to Facebook where such data can be found).

Biometrics are not really there yet either (not all phones have fingerprint records) and facial recognition is easy to game.

What is the best option for providing password recovery for a mobile application, working on the assumption that the thief has access to the users other services?

  • 1
    That's why you should lock your phone.
    – ThoriumBR
    Commented Sep 14, 2015 at 12:23
  • You seem to criticize all the existing solutions (which no one said they are perfect). May be it is time you invent us a new one :)
    – user45139
    Commented Sep 14, 2015 at 12:25
  • @Begueradj my question is kind of around whether the solutions I've listed are the only existing ones, of if there is another mobile-specific option that I have overlooked.
    – JonW
    Commented Sep 14, 2015 at 12:30
  • 3
    Most online services allow you to kill existing logins. If you do this after changing your password, you will effectively lockout the thief. That said, this solution requires active participation by the user and cannot be implemented by the site. Commented Sep 14, 2015 at 15:29
  • 1
    Most phone OS's also have the ability to lock or wipe a lost phone.
    – schroeder
    Commented Sep 15, 2015 at 3:31

4 Answers 4


If you consider that a device is compromise, you cannot do anything that relies on sending information to the device. This includes 2 factors authentication (SMS, or app) and emails.

The only option you have left is to base the account reset on the user knowing something (master password, security questions), or meeting face to face with said user (provided you can authenticate him physically). Alternatively, standard post-mail could be used if you have your client's address validated.

Today's applications do no bother to do this, since the client are always virtual and the only thing that ties someone to his account is his email address. This is why portable device protection are necessary for the user and there is nothing more a service provider can do to avoid this.

  • Fair points, although the client isn't always virtual - which would be the case for banking apps for example, when the app performs a function digitally than can also be achieved 'in real life' at a physical branch, for instance (which would meet the 'face-to-face' option you refer to).
    – JonW
    Commented Sep 14, 2015 at 13:09
  • @JonW in the case of a physically identifiable client, you can also send them a letter with the recovery information.
    – M'vy
    Commented Sep 14, 2015 at 13:10

I absolutely loath security questions; guessable by bad guys in many cases, as you said, and users (including myself) forget them more often than some might expect. Other secret-keeping options would certainly work in principle. You could provide a generated recovery key at sign-up that users could enter into a web site or app at reset time, or make them come up with a five or six digit PIN themselves to unlock your phone app (which would include a link to a reset option that would satisfy one factor when activated), though you'd half to design and pen test the app unlock code to harden the heck out of it (if only phones had TPMs) and the security of it would be dependent on the strength of the PIN the user chose. But of course those problems are going to be in the mix with any kind of secret-element-based system that acts a lot like a password. Maybe generating a memorable but suitably random passphrase on sign-up in lieu of a recovery key..

But really, if we limit ourselves to a recovery process that doesn't involve something close to another password/PIN/passphrase/key, or biometrics, or separate-equipment-- those little one-time-code tokens sure can still be useful in 2015-- then you could go with the common method of having the user actually talk to a customer service agent and answer very specific verification questions drawn from whatever user data you're holding for them. Obviously, your reps better be well-trained to be properly thorough to thwart social engineering here, too. A more secure mechanism--if you have the user's name and address--would be to verify identity the way the U.S. Post Office does when you go to change your mailing address online: have a verification service (or roll your own) charge the user a small fee--say, $1. That forces the resetter to enter a valid credit/debit card number plus an associated valid billing address, etc. you can then match that validated name and address up with the user's information you have on file. If security is really, really important and immediate reset & access isn't, you could even go further and instead of verifying and resetting immediately you could verify and mail or FedEx a key to the validated address (with the user paying for the faster delivery if he or she chooses that route, of course), as others have suggested. Or you could make the user go get their identity verified by a notary (in the U.S., anyways). Or....

Anyway, a lot depends on how you come out on the balance of the importance of security vs. the importance of avoiding user inconvenience and letting the user regain access as quickly as possible.


The options i could think were :

install the anti-theft apps ,some of the apps which would help you to control the screens and lock,manipulate the user sessions of browsing history too,if you were using android service like android lost might help u

logout the sessions and if possible keep some antitheft services on ur phone and lock your phone over the internet

other solutions would trick the thief to click over the malicious link sent by you and control your device,if the device was connected through wifi you could fetch the location of wifi and lock down the theif

last option might be injecting payload like this and hack ur own phone

  • This is more advice for what an individual user can do to protect themselves (although I'd like to think they lock their phone when not in use which would mitigate much of the risk!) but I'm more concerned with what we, the app designers / developers can do with the whole password retrieval process itself.
    – JonW
    Commented Sep 14, 2015 at 15:07

The most simple solution is using the phone number and/or the email address that are not stored on the device. They could be your family's ones or a backup email which is not logged in unless emergency case. You should encourage user to do that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .