gdpr data-protection database
Is password reset to a known default value GDPR compliant?
<p>I am working in a project where there are two procedure to change user password :</p>
<ol>
<li><p>The more common technique, in which user click on &quot;change password&quot; button (or &quot;forgot password&quot;). Then user has to insert it's login and new password. Procedure will check if the login match to an actual user and if so send to him a confirmation email (with a confirmation link)..</p>
</li>
<li><p>Admin users are allowed to reset password of any user, if so the password is reset to default (no mail and no confirmation, same default value for every user)</p>
</li>
</ol>
<p>I am concerned about GDPR compilance of this second method, because potentially admin can reset a target user password, and then snoop into the account. From my understanding a GDPR compliant application have to prevent data leakage to technicians</p>

<p>The GDPR does not provide specific rules about password resets. However, the GDPR contains a general obligation for the data controller to implement “appropriate technical and organisational measures” (TOMs), see Art 24 + 32 GDPR. What is appropriate depends on the “state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity”.</p>
<p>A password reset functionality is complicated from a security perspective. On one hand, such functionality is really good because it ensures availability of the service for the user. On the other hand, such features can provide a backdoor to the service, undermining security goals such as confidentiality and integrity. These aspects must be balanced, and there is not necessarily one correct balance for every scenario. What the one-person IT department of a small company does can reasonably be different from what a multi-million user social network does.</p>
<p>TOMs do not have to be purely technical – they can also include organisational aspects, for example training for customer service employees, and occasional checks to ensure that customer service staff doesn't abuse their access.</p>
<p>But nevertheless, TOMs must be measured against the state of the art.</p>
<ul>
<li>Password reset by sending a time-limited one-time reset link with a cryptographically secure nonce to an email address is a state of the art method, assuming that no 2FA/MFA is involved.</li>
<li>In some contexts, having customer service staff assign a new, random, one-time password could also be appropriate, for example if implementing a more secure workflow would be prohibitively expensive. Then, organizational measures would be more important.</li>
<li>Failing to notify the account holder that someone requested a password reset is not state of the art, and represents a possible security risk. The data controller is required to defend against such risks!</li>
<li>Resetting the password to a fixed default value is a very grave security risk, since it could aid unauthorized account takeover by a third party. It is unlikely that such a password reset approach could be GDPR-compliant.</li>
</ul>

<p>GDPR does not actually enter into the technical details of how data is secured.</p>
<p>If it comes to that, the regulatory agency (or the judge if you challenge its decission) will decide if you have been negligent in handling your data.</p>
<p>Here, I guess it will matter a lot of other things, like:</p>
<ul>
<li>Which kind (and value) of information are you protecting.</li>
<li>Which is the actual procedure (if the user must physically go to the admin desk, show his ID, and the he is given a terminal to change immediately the password it would not be the same that if it were just a &quot;Forgot my password&quot; link).</li>
<li>...</li>
</ul>
<p>And in any case it depends of what data you are securing, if it is not Personal Identifiable Information GDPR does not apply at all.</p>
