The story behind the new MODX package: PassChecker
We at Census presented our first public MODX package last Wednesday at the Dutch Summer MODX meetup in Hollandscheveld. A package which notifies a user when their password is a known to be a breached password. This package started of as a personally Saturday project, but we decided to take it further with the GDPR in mind. With this post we would like to inform you all about the decisions we made and how this package is working.
Why?
The whole of Europe and every company providing services for the European customers are very busy lately with implementing the General Data Protection Regulation (GDPR) into their organization. This gives lots of opportunities to think a bit further about the protection of personal data stored in our (clients) websites.
Image 1 is a model which is a simplified version of the responsibilities we have at Census for keeping the data secure. At the left we have the infrastructure we offer to our clients (webhosting, VPS and other cloud solutions). It’s pretty clear that the client is expecting us to maintain our servers, offer a SSL solution and provide them with information about important updates for the software that is being used (for example a MODX security update).
The situation on the right is not in our hands, we do not offer services to manage the network of the client’s private network. But then we also have a situation in between of those two, because we have to offer the client access to a manager panel like the MODX manager. This is done by providing the user the ability to authenticate with a username and password. But this raises questions, because who is responsible for that? And how can we advise a client on the security of the password which is being used? We can not simply ask a client for their password in order to check the weakness of it. And their are lots of discussions about the effectiveness of password requirements like a a minimum amount of numbers, capitals and/or special characters. Like here, here and here. The NIST recommends not to use any of those but check the password against a blacklist of ‘bad’ passwords.
‘If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed.’ ~ NIST, 2017. Digital Identity Guidelines 5.1.1.1
That is why this should be an automated process, nobody else than the user self should eventually know the password that is being used. But the user must still be informed about the usage of bad passwords.
What?
The goal is:
- Informing the user when their password is known in data breaches;
- creating awareness of their responsibilities;
- provide tips to the user to create a more secure password;
- and make it easy to change their password.
We came up with this notification, see image 2, which will be shown once a user has signed in with a breached password. It blocks the user from performing their original task. Information is presented about the results of the password check. Moreover the pop-up primarily focuses on changing their password, because this is the final result we are looking for.
How?
Meanwhile you might starting to feel a little uncomfortable about the thoughts of sending passwords to an external service in order to check it against known breaches. That is why it is important to look at the implementation of the package.
The external service we use is called the HIBP Password API. And it is managed by the security specialist Troy Hunt, which maintains ‘Have I been Pwned’. On this website you are able to check your email address against a numerous amount of breaches. You can also subscribe for notifications when your email address of even you companies domain is found in a new breach, really recommended!
Specifically we are using the Password Range API. This works by hashing the password to a SHA1 hash, taking the first five characters and send it to the API range endpoint, as shown in image 3. This means the full SHA1 hash stays on the server and is not accessible by the external service.
The result contains a list of all hashes of breached password starting with the provided five characters. We use this to find the ending hash of our password. If found we load the resources to show the notification until the user either changed their password or ignored the warning.
This process takes place after a user signs into the MODX manager. Since the passwords in MODX are hashed with bcrypt before saving, there is no way to check existing passwords, which is a good thing! The plugin for checking the password is using the OnManagerAuthentication event, which provides the password entered by the user. Since the provided password is not hashed yet we can use it to perform the check.
Where?
Hopefully you’re looking forward to give this package a try. You can download the package free from the MODX extras repository. Please let us know if you have any questions, extra ideas or comments.
Next?
The package will only provide the user with a clear and trustworthy message if it is provided in their native language. We also think it is important to provide this package with an extra bit of transparency. Therefore we will publish the Source code on Github in the near future. This will make it possible to check the source code an contribute with extra features and translations! The package is licensed under the MIT license.
About Census
We are a software company specialized in the technical development of websites, webshops, API’s and other (business)applications. We use MODX as our main CMS for our clients. Please check our website for more information or our contact details.
