gdpr european-union data-protection data
GDPR account verification
<p>I am having trouble in deciding what information I should be recording in order to verify an account user in the event that</p>
<p><strong>a)</strong> the user is locked out of their account for some reason</p>
<p><strong>b)</strong> they make an erasure/portability request.</p>
<p>I can create a very bare bones system in terms of user data (ie. No name, no birthdate, no address info), but this leaves me with very little to work with in the event of scenarios a) and b) occurring.</p>
<p>I have read the question, <a href="https://law.stackexchange.com/questions/45012/identity-verification-prior-granting-access-to-personal-data-gdpr">Identity verification prior granting access to personal data [GDPR]
</a>  , but I take issue with the GDPR reference in the answer, where it states:</p>
<blockquote>
<p>Per Recital 64, you should use “all reasonable measures” to verify the identity of the data subject who requests access. However, you should not keep data for the sole purpose of being able to respond to requests. (Compare also the data minimization principle and Art 11).</p>
</blockquote>
<p>I have problems with this statement because if I don't store the name of my user, how can I possibly ever verify that it is the owner of the data who is requesting either i) erasure, or ii) portability of data?  The only way I could possibly envision this is by only offering the option to logged in users, but surely there must be an offline option as well, for users who no longer have access to the system?</p>
<p>So, what is the minimum gathered user details that I would need in order to satisfy a) and b) whilst still meeting GDPR?</p>

<p>This is less of a compliance question, and more of an infosec question. On one hand, you want to be able to restore access to an account to users who have lost their access. On the other hand, you must prevent unauthorized access e.g. from hackers. These factors must be balanced.</p>
<p>Whether you'll fulfil a data subject access request will generally follow the same criteria as deciding whether you'll reset someone's access credentials, so I'll mostly discuss identity verification in general.</p>
<p>Trying to validate names is generally pointless from a security perspective, since the name on the account might not be real, or because validation documents like scans from a passport can be easily forged. When a service has identity validation measures like requesting a copy of photo ID, or requesting a photo of you holding up a validation code written on paper, that doesn't actually help validating that the person requesting access <em>is</em> the account owner, but that the person requesting access <em>appears</em> to be a natural person, and now documents about their identity are on file.</p>
<p>A lot of information like names, birthdates, or addresses is also not at all secret and could be easily guessed by a malicious actor.</p>
<p>Most websites work by equating access with control over an email account. If you can receive a password reset code over email, you have access. In effect, this delegates the responsibility of account recovery to the email or OAuth provider.</p>
<p>So the issue is what happens when someone loses their email account, which is not entirely uncommon for accounts that are multiple years old.</p>
<p>One reasonable (and likely GDPR-compliant solution) is to deny access when someone loses their account. Quite a lot of services operate this way.</p>
<p>A milder form of this is to email the old address that someone is trying to take over the account, and turn over the account only if you have other evidence of ownership <em>and</em> there has been no reply over multiple weeks. Since this is part of an identity verification measure, I don't think the GDPR's normal 1 month deadline would apply. However, this approach is very risky: an attack can succeed through the mere <em>inaction</em> of the true account holder, and it would arguably be a data breach if you give access to the wrong person – safer for erasure requests only. Also, emails like “click here or we'll delete your account” look a lot like spam (I get a lot of those about alleged problems with my Paypal account).</p>
<p>A potentially more reasonable approach is to use questions about the account to verify ownership. When did they create the account? When did they last use it? Can they answer questions about non-public content of the account? (But don't let an attacker choose the questions!)</p>
<p>You see some older sites that ask the user to select a “security question” for recovery purposes. But this isn't a best practice – they are frequently the <em>weakest link</em> in an authentication system. If the user answers truthfully, the answer may be easy to guess or discover for an attacker. E.g. the infamous “what is your mother's maiden name” question is horrendously insecure in the age of Facebook. If the user provides a more secure answer, that is essentially just another password that's even easier to lose than an email account.</p>
<p>High-value accounts typically offer a secondary authentication method as a fallback. E.g. my bank can send me new access codes via physical mail. GitHub can optionally link a Facebook account for recovery purposes. But these measures would be overkill for most cases. Especially collecting a physical address for the sole purpose of offering account recovery would likely violate the GDPR's data minimization principle, though it may be fine when the user opts in with freely given consent.</p>
<p><strong>To summarize:</strong> what you're trying to do is extremely difficult, because you've need to balance different security aspects: keeping malicious actors out, and letting legitimate account owners in. Whereas I'd resolve that by <em>denying</em> any account recovery or subject access requests, other approaches exists with other risk profiles. The GDPR requires you to perform reasonable identity verification measures, but what is reasonable depends on the business context and is ultimately an infosec question.</p>
