0

I have a software where we can show order invoice information by typing in the order number and buyer email. Now the thing is that I need to hide the sensitive order information like:

Name Surname
Address 11
Germany

as example I want to hide this data and show it as:

N*** S******
A****** **
G******

I think that showing the exact number of letters and numbers by just replacing them with asterisks is not quite safe, but I want to make sure if it's not breaking the laws of GDPR.

  • For what purpose do you need to retrieve the invoice info? Either name + address is necessary for that purpose, or it shouldn't be shown at all. I don't quite get what benefits it has in this context to redact part of the name. – amon Nov 20 at 8:42
  • If the user itself is logged in into the software and it's his own invoice - he sees the whole information without any asterisks. If you open the invoice and system doesn't authenticate you - it shows the information with hidden characters. Actually my client decided this functionality and I just wanted to make sure if this is a correct way to hide the data. – The50 Nov 20 at 8:53
  • 4
    For what purpose should unauthenticated users see part of other people's invoices? That's not necessarily illegal but it really raises some questions. If this is a website, and the invoice URL contains a large random identifier that serves as a secret access token, this might be all right. Otherwise, showing a "please log in to view this invoice" interstitial would be more clearly compliant. In general, I don't see how this redaction would be legal as showing the data just seems unnecessary. In GDPR-speak: this violates the data minimisation principle. – amon Nov 20 at 9:18
3

The GDPR is wide in scope, and flexible in application. Therefore it is not possible to give an absolute yes/no as to whether masking text with asterisks is or is not lawful.

We can gain a deeper insight by looking at the GDPR itself. Firstly, the definition of processing (Art. 4 lit. 2):

any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction

As mentioned by amon, the principles relating to processing of personal data (Art. 5) are highly relevant, insofar as the activity constitutes processing. In particular, purpose limitation:

[Personal data shall be] collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes

...and data minimisation:

[Personal data shall be] adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed

I would argue that making available the personal data on an invoice is processing. There are two separate operations:

  1. Making the data available to authenticated users; and
  2. Making the data available to non-authenticated users

The purpose of making it available to authenticated users may be different to the purpose of making it available to non-authenticated users. Again acknowledging amon, the necessity of making the data available to non-authenticated users must be examined, as too must the means by which a non-authenticated user gains access to an invoice: are they using a URL that contains a token of some kind? Is this unique in some way? It could be that the presentation of a token itself constitutes authentication and thus authorisation to view the entire invoice, in which case further redaction may not be necessary if there is a clear necessity to disclose the entire contents to such a user. Whether the token expires or is limited to a certain referrer would be part of complying with the integrity and confidentiality principle and Art. 32 (Security of processing) by implementation of technical measures.

When considering pseudonymisation and anonymisation, you will note that the redaction of name and address data from a certain view of the invoice, while nevertheless displaying the invoice number, constitutes pseudonymisation, since it would be possible with unfettered access to the remaining data, to determine the name and address from the invoice number, but not for the non-authenticated user whose view is redacted. In such a case, I fail to see how or why the replacement of a string with the same number of asterisks, or starting with the real character is secure or even practical, when the entire field could simply be replaced with a fixed-width string of asterisks or other filler, thus providing the user with no right or necessity to view the personal data with no further insight into what the personal data may or may not be.

  • Thank you for your answer. I forgot to mention about the access to the invoice itself, sorry about that. Yes, the invoice page is accessed by the URL with special hash code. This URL is available only after the order is created as well as from SMS message you get right after the order creation. We need to hide this invoice information in case someone who isn't the buyer gets this URL. Now I am starting to think that it's better to not show any sensitive information at all. Without using any asterisks or any symbols. – The50 Nov 20 at 11:39
  • BTW my client just responded that this symbol hiding is necessary for user if he isn't authenticated yet, but he opens his own order. So if client sees his initials - he understands that this is his order. I don't really see the logic in this, but it's what the client wants. – The50 Nov 20 at 12:09
  • 2
    Honestly, I'd just reveal the data and ensure the hash is secured. Make it expire. Make them log in after it expires. Send them another SMS. There are so many ways to implement security. Don't make the number of asterisks the same as the real string, it defeats the purpose of obfuscation. – Sam_Butler Nov 20 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.