• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 37 subscribers
  • Views 3225 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Managing sensitive data guidelines with password resets in STAT

tim.rogers
over 5 years ago

During a recent internal review we noticed the MERC_EMAIL_MISC_QUEUE table stores the temporary password for users when a password reset occurs.  Are there any STAT users who have restrictions on sending unencrypted passwords via email or storing unencrypted passwords in a database? 

 

We understand the MERC_EMAIL_MISC_QUEUE table is included in the PURGE AGENT EVENT TABLES job but we identified other data\tables which are part of this purge that may be relevant to retain longer than the temporary passwords.

 

We are curiously hopeful that other STAT users have entered this discussion and could possibly share how they managed sensitive data guidelines with the STAT temporary passwords in clear text both in the email and database.

  • 0 over 5 years ago

    At first, you need Temp passwords in order to implement 'Reset Password' functionality to enforce Password History policy.

    I would recommend to involve Product Management. As far I' know, in past the tool Password Manager used to pass evaluation against "industry" general password compliance requirements which might include answers to your questions. The "industry" requirements used to be unforced by financial industry wand included things like: hacking internet exposed URL in DMZ via "http://.. code" substitute execution, one-way 128bit key encryption of Q/A according to government regulation etc.

  • 0 over 5 years ago in reply to Aidar.Karabalaev

    Thanks for the suggestion of a password management utility. 

    With the temporary passwords visible through the STAT table dump utility we were exploring the installation of a VPD to give use more flexibility with some of the database security;  there is some additional overhead to both approaches which is weighted against the risk.