2

We have an IBM z/OS system that I am part of the administration team on which we often have to reset users' passwords. (forgotten, too many violations etc).

We do this my choosing a new password and assigning it to their id. We then email the user with their new password.

I know this is bad but am uncertain how we can improve the process?

My current idea is to provide a website which can produce a public and private RSA key pair, have them send us the public key which we then use to encrypt their new id and which they can then decrypt with the relevant private key.

What is the recommended process for systems whereby passwords resets are a manual process and the new password must be given back to the user?

Edit:

The OS is z/OS, the security system is ACF2 and changing a password is done via a CLI-type interface, where an authorised user simply issues a 'change' command with the userid and the new password in cleartext.

the email informing the user of their new password is done via internal mail, but will often be sent internationally. The user will have to change their password upon first use.

2
  • Why not use the usual 'Reset password' - website based approach? Is it required that users may not choose their own password? Even so, you could still simply send them a one-time link to a web page which displays the new password to them. Preferably with 2FA enabled.
    – FMaz
    Commented Feb 21, 2017 at 15:05
  • @Krazor The OS does not support this, although there may be 3rd party add-ons to allow this functionality. I did look, but found nothing. changing a password is done via the equivalent of a CLI command.
    – Steve Ives
    Commented Feb 21, 2017 at 15:07

2 Answers 2

3

Based on discussion in the comments, I would suggest a

one-time link, that links to web page displaying the new password to the user.


Some upsides of this:

  • Transmitting the actual password happens (/should happen) in HTTPS.
  • The password is only ever exposed in the browsers cache and server-side. (This means that future breaks on a clients device will not leak the password)
  • You can use further authentication methods on the web page, which will ensure that the new password is kept secret.
6
  • thanks. you mention a one-time link - would that be something like a Secret Note website?
    – Steve Ives
    Commented Feb 21, 2017 at 15:18
  • I'm not sure what a secret note website is, but probably yes. A one-time link is a link to a resource which gets destroyed after being served for the first time, therefore rendering the link invalid.
    – FMaz
    Commented Feb 21, 2017 at 15:21
  • How do you get the one-time link to the user in a secure fashion?
    – Steve Ives
    Commented Feb 21, 2017 at 15:36
  • 1
    That depends on what kind of security you need vs. the usability you intend to provide. Google, Amazon, Facebook all do it via E-Mail. If you would use a code-sms etc. that would further increase security. For maximum security (and an absolute minimum of usability) I'd also resort to PGP or the like. Keep in mind that your users might not be as techie after all.
    – FMaz
    Commented Feb 21, 2017 at 15:54
  • 2
    No. Yes, it's insecure in the sense that either way the information in the email is not completely protected. However, the risk of having the password be known vs the risk of having access to the one-time page is different. One, if the intended user AND an attacker get the password, then you may never know. However, if the intended user tries to view the password after an attacker already has, then they will (hopefully) request another password reset, which limits the attackers window of attack and the usefulness of knowing the password.
    – you786
    Commented Feb 21, 2017 at 16:55
0

I was recently working at a company where we had a similar problem. We still emailed passwords to users, with the caveats that we always:

  • Required the password to be changed on first login. This prevents a later snooper from being able to use the passwords they found in the email.
  • Reset passwords only on request. This, combined with following up with them via internal chat, helped ensure that they would log in quickly, reducing the time that the emailed password was valid.

This isn't an ideal system by any means, but it reduces some of the most major risk factors with very little technological work.

1
  • Your first point does not meet ops requirements. See discussion in the comments :)
    – FMaz
    Commented Feb 21, 2017 at 17:14

You must log in to answer this question.

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