GDPR – Database – Pseudonymisation

  • Hello there friends!

    I had a chat today with my supervisor who attended a seminar for the upcoming GDPR changes etc so we can get in line with whatever is necessary to be compliant.

    A question came up though from him to me that I had no immediate answer as I guess it’s a matter of how WordPress and Plugins are handling everything at the moment (and of course on my hands to alter it to fit the needs).

    The thing is that with the GDPR Pseudonymisation rule ( https://en.wikipedia.org/wiki/General_Data_Protection_Regulation#Pseudonymisation ) as far as we can understand is to either split our data so if there’s a breach they can’t be cross-checked ( means have 2 databases for 1 installation, so 1 database would keep username/email and the other would keep phone, address. If 1 has a breach you can’t cross check the data and have a full scope of a users personal data ) or have extra values encrypted and not only the password. For example a phone number could be encrypted in the case of a user’s profile so on so forth.

    Is this a matter that should be discussed at some point to see what could / can happen?

    I’ve been all over since this morning reading only about the ‘opt-in’ compliance on submission forms etc etc but not a more technical view of the matter as of how database protection will get a bump towards this certain GDPR aspect ( if it is actually needed ).

    Of course if I understood correctly this is something that both WordPress and all the plugins that gather user data should comply as well etc in order to not break the ( so lets say both should encrypt some extra data by default to be fully compliant on Pseudonymisation ).

    Any ideas if that would be already possible, or something to be discussed in #core etc?

Viewing 3 replies - 1 through 3 (of 3 total)

  • As a developer and hosting provider, I’m studing this problem too.

    My conclusions are, that this rules are impossible to follow,
    and the only thing to do is to encrypt all drives (and backups) where we store sensible informations,
    to -formally- follow the rules but ignore the original goal of this madness.

    Hey thanks for your input, again though by encrypting all drives etc that’s something that could be an asset if there’s a server-side breach lets say? I can’t imagine how could we encrypt things and show them on a website normally without giving access to the keys…

    Meaning that the decryption key should reside on the server as well so it’s pretty much pointless. I seriously can’t understand how it would make it ‘safer’ if we had to encrypt everything + having the keys on the same spot.

    I’m not into security I just throw comments as of what I’m understanding.

    We are theorising to do this in a virtual environment,
    wich host have the keys, for startup-only purposes.

    In this way, if the data is stolen outside the facility,
    without keys the disks would be un-cryptable.

    Of course this doesn’t solve the software-side problems of security,
    and we had many problems with WordPress in the past.

    This is why we are developing a clustering software for WordPress,
    similar to WordPress Multiuser, that jails the websites inside …

    We would like to present this software in the next European WordCamp (Belgrade).

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘GDPR – Database – Pseudonymisation’ is closed to new replies.