3

Need your suggestion on this.

Consider We have a mobile application and massive number of users. We want to implement secure password reset functionality with the consent of user experience.

Assumption - Here we all assume that hacker has stolen the phone of victim hence traditional password reset implementation will certainly not work as:

  • If We send password reset OTP on phone, hacker has victim's phone already. Hence no use.
  • If We send password reset token, hacker has victim's phone where in majority case email id is linked and opened in the phone. Hence no use.

Current implementation - If someone requests password reset request, we give them new password after 24 hours. We keep this time window so that if user's phone is stolen and hacker sends password reset request, then user must be able to report us within 24 hours so that hacker does not do any malicious activity from his/her account.

Problem - We need to reconstruct this implementation by assuming two thing in advance that user's phone is stolen and hacker has sent reset password request to us and user has not reported us that his/her phone is stolen in 24 hours. How can we identify achieve this task without identifying that the user is legitimate or not and still user's account remain secure?

Couple of Solutions:

  • We start providing hardware tokens (RSA token, VASCO token) to our users so that even if phone gets stolen, to reset and use new password hacker will have to physically access these tokens to login. (Problem - It is impossible for us to provide 500000 of hardware tokens for our users.
  • Trusted numbers - While registering, user adds two trusted number which is stored in our database. With the reset password request, we provide password in two separation on those trusted numbers and user can access application by combining those. (Problem - User experience becomes tricky and unacceptable)
  • While registering we provide some security questions( not traditional questions of birth date, mother's maiden name etc.) such as select 1 out of 4 colours. Select 1 out of 5 food etc. While reset password we provide them these questions to answer as hacker wont be knowing these all. (Problem - If I register now and I forget pin after 1 year, I wont be remembering these answers, only case in which I remember these answers is if I took a screenshot of those answer while registering it which is again a concern in stolen phone)
  • Backup code - We provide backup code unlike google while registering and user will have to add those in order to reset password. (Problem - Most of the cases, user takes screenshot of backup codes or stores in notes application which is again a concern in stolen phone)

Apart from these, We need other suggestions through which we can implement some solid solution and still user experience tries to remain smooth.

We completely agree that security and user complexity are inversely propositional. If we want to implement bulletproof security, user experience will go bad. However I want answers from the community if there is a way we can do it.

Suggestions are appreciated.

  • One regular bank in Germany actually gives their customers (optional) hardware tokens on request. Even for their free bank accounts. I doubt that they are really expensive. I suggest to offer your users this option, so they can avoid a cumbersome other method like some of those you've mentioned yourself. (Or others, e.g. validating a code in a local office, that they were given via a smartphone-app). – Martin Fürholz Jun 3 '17 at 6:50
1

My suggestion is to pass the buck to the big guys: throw out your custom implementation and use something like OAuth to have your users sign in with google or facebook -- just like StackExchange!

If you must keep things the same: why do you assume password resets are always due to hackers? Have you measured why password resets occur? I'd bet most of them are due to users simply forgetting their passwords (i.e. I think you're starting with bad assumptions and you're going to degrade the experience for the majority of users while only protecting a small percentage of users).

  • We are not always starting this with bad assumption.This is what we think to harden our security to next level. If we use 0auth and phone is in stolen hand, then hacker can click on 0auth and assign permission to use application with facebook. – FrOgY Jun 3 '17 at 4:50
  • But why do you need to harden your security? – drewbenn Jun 3 '17 at 4:53
  • If there is a good mechanism through which we restrict attackers and our users remains same with acceptable use experience, why not to implement. Its financial application hence we always try to improve our security with best practices. We do follow best practices now but this is just in beginning phase if we can implement this we may go ahead with this. – FrOgY Jun 3 '17 at 4:58
  • Ahh. I always succumb to scope creep, too :) I suspect the cost of covering your customers' losses due to hackers would be cheaper than the cost of developing a solution combined with the cost of losing users who were turned off by the extra steps, but that's for your business manager to decide. When you're thinking of possible solutions, start with the three factors themselves (who you are, what you know, what you have) and think about which ones you can use to distinguish users from attackers (for example have them come in to a local office to reset their password). – drewbenn Jun 3 '17 at 5:11
1

Hardware tokens are expensive and often an expensive option. As a business decision, it may be possible to ask the user to bear the cost (give a list of compatible tokens and any initialization steps) - thus making it a viable option both cost-wise and logistics-wise.

Trusted numbers are also fallible (users forget to update recent contact info) You could remind users to confirm their recent numbers every once in a while (pop up like Google / Twitter / others do.. "Is this still your backup number?"). You could simply notify the user at both the primary and secondary numbers / email addresses - thus covering the risk of loss of covering of one device/number/email address. I think asking for confirmation from the alt-number/address is too big a barrier to be effective security.

Security questions, backup codes - are the least desirable for the reasons you pointed out yourself.

The key here is to use an auth-factor that is unlikely to be stored in (and hence lost with) the device. You need to dig deep into your knowledge of / relationship with your customers to identify this. e.g., some banks requires a physical address proof document to be sent to them for address change requests. Back office verifies this.

Of the three standard factors (what you know, what you have and what you are), only the first one seems handy in this scenario. It must not be a static info (like Date of Birth), or easily available info (something on FB profile).

One possibility: Ask for the approximate amount of (or a store name of) a recent transaction to go forward. Or when the last payment was made. Something of the sort that the app/BackEnd would know, and the user would not so easily forget, but not outside the system.

  • One possibility suggestion from you - Ideally this wont be possible as this application deals with bitcoin where prices are fluctuating every hours/minutes. Ideally it takes 1/2 days to receive bank account statement and probably if prices goes up and down customer may miss the opportunity to buy/sell/withdraw. Hence even in our existing flaw we want to remove 24 hour time window. – FrOgY Jun 3 '17 at 8:47
  • Perhaps I wasn't clear. I was referring to a "transaction that your app/system would know". It could be a bitcoin / altcoin transaction. e.g., "when did you last send bitcoin from your wallet (to an external wallet)?" or "what was the approximate quantity of bitcoin/altcoin that you last sold?" The answer should have a wide range of possibilities (so no easy guesses), and a reasonably (subjective, yes) approximate answer could be accepted. – Sas3 Jun 3 '17 at 9:53
  • 1
    The problem is that, as you know bitcoin is like internet controlled by us and maintained by us. Hence every transaction is public in blockchain and bitcoin. Considering your scenario, if hacker is a user of my application too, he has knowledge that the victim sent how many bucks to whom and when as everyone get to see transaction of one another. Hence hacker will also know these answers in order to reset password. – FrOgY Jun 3 '17 at 10:10
  • True. Well, we keep looking for alternatives then. :) – Sas3 Jun 3 '17 at 10:18
1

I think your best bet are your options 3 and 4.

Security question

I'm not a big fan of security questions. Personally, I never remember what answers I gave to these. You rightly disregard mother's maiden name and birth date as too easy. Your suggestion of choosing from foods, colors etc isn't such a bad idea in general: There is research that states that people's preferences are fairly stable over time, so that if they choose a certain food now, the likelihood that they'll choose the same food image in two years time is high, even if they don't exactly remember their choice. The problem with the idea is that choosing one out of five gives an attacker who knows nothing a very high chance of success with randomly choosing images, even if you chain three such questions (1 in 125, which is trivial - if you have 500000 clients, a determined attacker might manage to break into about 5000 of your client's accounts). And with every additional question, the chances that a legit client will answer one of them wrongly increases.

You could also have security questions that open up a large number of possibilties, the answer to which is stable, such as "the last four digits of your driver's license number" and "the ISBN number of your favorite book" and so on. Depending on how many possibilities this opens up, you'd also have to let the user answer two or three of those (the last four digits of your driver's license number will only open up 10000 possibilities, which means that with 500000 clients, 50 of their accounts will be compromised by a determined attacker even if he only makes one attempt per client).

Backup code

You could provide this as a QR code which can be printed out and filed somewhere. Ideally, if you have a postal address for your clients, you could send this via regular mail. This would be much cheaper than a hardware security device (but still incur costs for mailing a letter).

Postal mail password recovery

In fact, if you actually have a postal address for your clients, you could just do password recovery via regular mail.

Don't disregard solutions that involve phone possession

You're assuming that an attacker who steals your client's phone automatically gains access to whatever recovery system you set up that involves the phone. While this might be mostly true in theory, I'd say that in practice phones aren't stolen primarily in order to gain access to someone's digital identity. Most likely, a phone thief won't be interested in the data that sits on the phone (apart from maybe looking at the picture gallery). So if you make possession of the phone a part of your recovery system, that does add security for most clients.

  • I like the idea of security question with unorthodox questions such as ISBN number or driving license number etc.. It decreases user experience complexity at a same time security level remains good in this pre-assumed scenario. – FrOgY Jun 3 '17 at 15:18
0

we can do one thing here, Every time when I am login with the application I can surf that application only as a guest user (not with fully access) ya i can ses all updates all new notifications offers etc., I can see my all stuff and all, well now if I wanna do a transaction OR want to transfer money OR get money in my wallet OR want to change my details, So For that First, I need to login with my account, and after I need to generate OTP no. and after that, I need to answer the security question (which used in signup time). so this is three-way security. and after the transition is done, I am logged out automatically.

again same process goes on..

  • OP is asking about 'forgot password', not about initial log in. – MiaoHatola Jun 3 '17 at 11:48
  • @V1Ru5, There are not 3 protections in your implementation. Here we assume that phone is stolen hence, 1. Hacker will only receive OTP here 2. It has been already discussed that why we do not want to go with security questions because if I signed up and forget my PIN (which i use regularly) after 1 year, how I come I will be able to remember security question's answer which I setup 1 year ago. Hence people will start taking screenshots of answer which they provide while registering and we again consider is a flaw. Hence this is not best security solution. – FrOgY Jun 3 '17 at 15:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.