#WordPress Login

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 2nd 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


CSP WordPress

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.


WordPress & CSP #GDPR #DSGVO

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.



CSP / DSGVO / WordPress

a true pain in the ass Part II

Getting WP installation in line with #GDPR / #DSGVO is a real pain if you are not willing to accept a B or even a B+ on your ratings.

Why are we doing this?
somehow forced by #GDPR / #DSGVO Art5.1.f Art25 Art32.2

Setting up Content-Security-Policy as we should do to get along with #GDPR / #DSGVO will break your WP-Installation as far as what we seen here so far. The List of not working stuff, ist long, and yes I can tell you really long, from non workin PlugIns over corrupted Themes to a not working default Editor. Sumed Up … a pain in the ass

So what will it gonna be?
After not feeling the vibe for trial and error on this topic we call it a day with an unsafe impelmented CSP but a full working WP installation.