We're currently looking to implement a secure AD password self-reset feature for our users. Our scenario is to manage people who forgot their password, not those who want to change it. Our users are usually based on remote locations and most of the time don't have access to a VPN. Our first thought was to provide a web-interface where users must authenticate using their username and an authentication factor which could be:

  • A private question/answer;
  • An OTP sent by text message to a user's pre-registered mobile phone;
  • An OTP included in a password reset link sent to a user's pre-registered private email address (e.g. Gmail).

But due to organizational constrains, we cannot rely on text messages to send an OTP, and we don't consider the question/answer to be secure enough. So we are left with the private email option, which still concerns us because:

  • The email provider or the email account could be compromised;
  • The email provider will be able to associate an email with our organization (which can be an issue sometimes);
  • We consider it would open the door for phishing attacks - going against our communication to users saying that they should never, ever open a link that pretends to come from the organization on a private email address.

So is there a way to allow users to reset their AD password without using text messages or private emails, and without using a commercial (paying) solution?

2 Answers 2


The problem is that when a user has forgotten his password, you need a special procedure. Private question/answer is generally seen as a poor way, because users generally do not remember what they asked first, whether it was upper case or lower case... and if they can remember it without risk, then anybody that knows about them could answer too... Anyway you say you do not find that secure enough.

But if you want something else, you have to find a other channels. Common ones include a secondary mail address (said differently a secondary authentifiable identity) => something you know and text message on a mobile phone (something you have) - and I can hardly imagine others. Ideally, if your security requirements are medium to high, you could combine both:

  • when a user has forgotten his password, he asks for a reset procedure (on a HTTP semi-public page - no authentication here)
  • you send him one unique token on his private mail (no link in order not to break the anti-phishing com...)
  • you send him a second unique token on his phone with a text message
  • when he has got both, he connects on the reset page, types his id, the 2 tokens and the new password he wants - the password should be typed twice to avoid typo

That way if either the mail of the phone have been compromised, or if one of the messages are intecepted, an attacker would not have enough information to reset the password. But I must admit that users could find that complex...

  • I know this may sound a bit over-paranoid, but even if we only send an OTP to the user's private email address, without any link, we would really like to avoid doing anything related to passwords/credentials with an external private email. Is that way too paranoid?
    – ack__
    Nov 2, 2016 at 15:35
  • @ack__: If you protect no more than the list of books in a school library, it is over-paranoid. If you security needs require a two factor way for resetting a password, I would use it. High level security would require a human authentication, for example to show an identity card in a military base... Nov 2, 2016 at 15:42

Whatever you choose, you should consider multi-factor authentication to make it more secure, considering it's the domain password for your company domain. As doing biometric in your scenario appears more difficult (though it could possibly be an option through smart phones, but not all users will have a smart phone with a fingerprint reader), you can go with something you have and something you know.

Practically this could be a question-answer and an OTP with a well-known algorithm, like HOTP or TOTP. Many mobile apps can be downloaded on pretty much all mobile platforms for the purpose of generating standard OTPs, and users only have to enroll by loading their secret into the app, mostly by reading a QR code for automatic setup.

This way, while a mobile device has its own risks (malware may be able to steal the OTP, somebody may get hold ofthe device temporarily, etc., the usual stuff), the user would still have to know the answer to something.

Having said that, many users hate security questions. Also they are not very secure as you said, but maybe having that together with an OTP mobile app would satisfy your requirements.

For the copany domain password, well... I'm not sure I would do this though, it's still a relatively high risk I think. Maybe you should just have support on the phone, with say phone numbers on record for IT stuff, and when somebody calls that they forgot their password, IT could call them back on the given number for authentication (and you could go further to make sure if this is not enough). Obviously this may not be feasible in many cases, just a thought.

You must log in to answer this question.

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