Author: Stefan Lechner

username or email flanked with 2FA #GDPR

As a matter of fact there is more to do than type in a username and a password to achieve a getting some kind a close to #GDPR compliance feeling or recomandation. Strongly I get a feeling that state of the art #GDPR will be soon a real pain in the ass for all of us using software for making things happen. Think about it!

Be honest to yourself, is protecting a login with username and password enough in in these days? Sure not, so use a 2^nd factor for authentication and get yourself and your clients some kind of a state of the art protected feeling.

As far as I’ve seen it here #WordPress allows you to choose between your username and your email for login. Well there is no easy way out unless you use some kind of LDAP services to manage that struggle. On the other hand you can force your users to write their usernames for 429 login applications down, cuz they will not memorize it, or let them use their email and their email only for login. Always supported or flanked by a 2FA.

The only thing you have to do is, temper a little bit with the code in your child-themes.

The file you have to edit is functions.php

still painfull but in the end its not working well

Content-Security-Policy HTTP response header helps to reduce XSS risks on modern browsers by declaring, which dynamic resources they are allowed to load.
The Content-Security-Policy header allows to restrict how resources such as JavaScript, CSS, or pretty much anything that the browser loads.

What types of attacks does Content-Security-Policy help reduce?
Content-Security-Policy was first designed to reduce the attack surface of Cross Site Scripting (XSS) attacks and further on also to protect against other forms of attack such as Click Jacking.

Referring to Recital 83 GDPR, Security of Processing GDPR, when you touch personal data processing there is no way out of
trying everything to set security up to state of the art. Of Course always taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected.
Always have a look at GDPR Art5.1.f, Art25, Art32.2 too.

So a guess out in the wild, WordPress will still be used and serving content with script-src ‘unsafe-inline’ and ‘unsafe-eval’ till someone is gonna fix this without breaking that whole CMS.

and yess if you read the ticket top down and have a look on the timestamps … yes its a pain in the ass

not to mention that there is something called #GDPR and something called state of the art

so as far as I’m concerned we can live with a B whatever rating because
there is no other way round without breaking the whole thing.

Link: https://core.trac.wordpress.org/ticket/39941