We have a web application which requires users to log in with username and password. We have a password reset feature for users which more or less successfully follows the guidelines outlined by Troy Hunt in this article, with 1 major exception, we have a weak link:

We have an admin portal with a feature which generates a temporary password and displays it on the screen to the Admin was added, with the understanding that this is to be read out over the phone, rather than emailed. To be clear, an admin also has the ability to request a password reset email on behalf of user (and sent to user's registered email), but this is never used.

We have plenty of users who are not very computer literate, and some of them struggle to create/reset a password by themselves (despite the password requirements being clearly signposted before the user enters the new password). To make their job easier our guys have taken to using this temporary password to reset the password themselves to variations on the same common password and reading this out over the phone. I feel this is an unacceptable security risk.

I've tried to convince them that if any admin can reset a password we can't truly identify a user. A user would have carte blanche to say "It wasn't me" to any action they carry out after an Admin has set their password, but they're not convinced that this outweighs the extra difficulty they would face. I've tried to convince them that resetting the password of anyone who asks to the same generic password makes accounts much easier to compromise, again no dice.

I've thought that a legal argument may carry more weight (UK based so GDPR may be a factor) but I don't have the knowledge to explain why (if?) this would be in breach.

Another alternative may be to compromise on something else (perhaps reduce password complexity requirements, although I don't feel they are onerous now) to mitigate the impact of removing this feature.

My colleagues and management are not at all versed in IT security. How can I convince them that this is not an acceptable state of affairs, and carries risks for them personally and for the company? Alternatively, are there any reasonably secure compromises I could offer?

  • Can I define my own password once a password is set by an admin?
    – schroeder
    Commented Jan 5, 2018 at 13:48
  • Yes you can change your password, although I'm sure many don't.
    – Slappywag
    Commented Jan 5, 2018 at 13:49
  • True, but it makes a difference. Giving weak temporary passwords vs forcing users into weak passwords. Your management can easily say that there is little value in strengthening temp passwords.
    – schroeder
    Commented Jan 5, 2018 at 13:56

1 Answer 1



GDPR does apply in the sense that user passwords fall under the "personal data" section and needs to be properly handled in line with the reasonable business need to process the password. That gives your company a lot of interpretive wiggle room.

Risk Assessment: Impacts

As an IT professional, it is not your duty to beat people over the head with "best practices". It is your job to know best practices and to understand their impact, and then to communicate the risks involved in taking any direction.

but they're not convinced that this outweighs the extra difficulty they would face

It is entirely possible that they are correctly assessing this. They may not be, but consider the possibility that they are, and prove the correctness of their assessment. Is the data and the service of such low value that user experience has a higher value? If so, then they are correct.

we can't truly identify a user

Do you need to? What is the impact if you can't? If the impact is low, and you ultimately do not need to, then they are correct.

makes accounts much easier to compromise

Does it matter if the accounts are compromised? How much does it matter? Again, if it does not matter, then you will not find a way to convince anyone of the value of your point of view because it has no value.

The passwords being handed out are technically "temporary passwords" and I can't imagine any management team wanting to spend any amount of time or energy strengthening this process. There is just so little value.

Risk Assessment: Likelihood

But what if the value is proveably high and they still are not taking your point of view seriously?

I suspect that the people you are talking to are doing their own risk calculation in their heads. Risk is often defined as the relationship between likelihood and impact (risk = likelihood x impact). If you can show the high impact, but they still assess the risk as low, then they are probably thinking that the likelihood is low.

  • "We trust our admins."
  • "Our customers are not savvy enough to try to hack the system."
  • "We are not big or important enough for hackers to be interested."
  • "We have not been hacked before."
  • etc.

If this is true, then you have an uphill battle because you are fighting against emotion, psychology, and cognitive biases. You are also fighting something that is conceptual and very difficult to calculate objectively. InfoSec Risk is notoriously difficult to assess (I have done a number of talks and papers on the subject).

Unfortunately for your customers, all it can take is one bad incident for management to flip their understanding of likelihood. That's why penetration tests and security audits can be useful. They can act as simulated events than can help quantify likelihoods.

Risk is a Management Decision

As hard as it is to hear, risk is a management decision. If they decide, with all your information, that the risk is low, then that's that. If you believe that the risk is still high, then start planning for how to mitigate the risk when it happens so that you can protect both your company and your customers, but know that you will likely not get time or budget to develop those mitigations. You will look very good if you have a pre-made solution, though, when bad things happen.

Your Job

In short, if you want to convince them of the risks, then you need to define the risks in terms that they understand. It might take some time to get to know what they value, but that becomes your job; understand the risks yourself and learn how to communicate risks to those who do not understand. This is the true burden of information security.

  • You've absolutely nailed the likeliness arguments - those 4 were all given, and that's where my problem lies. I don't think anybody is massively disagreeing on impact, just their perception of likelihood. My problem could probably be more succinctly written as "How do I overcome these 4 (false?) perceptions of likelihood?"
    – Slappywag
    Commented Jan 5, 2018 at 14:00
  • @Slappywag lol, there's a reason I was able to come up with those 4 in particular; they are universal. And if you were to post that revised question, I have volumes of material that I could post in response, unfortunately. There is no easy solution.
    – schroeder
    Commented Jan 5, 2018 at 14:02
  • @Slappywag as I wrote, you can 1) simulate the likelihood with testing, or, 2) modify the likelihood based on the impact assessment with the idea that the data/service is valuable enough to others that they have an incentive to try to break the system 3) have a frank discussion about the insider threat angle. If you have a grumpy admin, what would be the cost to reset all the user passwords that the admin knows?
    – schroeder
    Commented Jan 5, 2018 at 14:05
  • And the more I consider it, you've got me thinking that perhaps I have a set of ideological blinkers on here, in aiming for 'Best Practice'. Thank you, this answer is a great kick off for further thought for me. Will leave accepting the answer for a day or two, to see if I get anything else.
    – Slappywag
    Commented Jan 5, 2018 at 14:18
  • 1
    @Slappywag glad to have been of help - those ideological blinkers are the result of the "curse of knowledge" and we all need outside perspectives to see past them
    – schroeder
    Commented Jan 5, 2018 at 14:21

You must log in to answer this question.

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