04 Aug 22
PrestaShop: security vulnerability
PrestaShop, the company that gives name to the famous CMS (content management system) in open source, has reported a vulnerability […]
2FA and security
Security is the top priority everyone’s after when, as in our case, you are the line of defense separating your clients from potential attackers. In the world of computing, DDoS attacks are very frequent, but there are other kinds, and you never know which one is coming next. So, we need to strengthen all fronts, lock all the doors and seal all the cracks where malicious individuals might try to harm us.
Like many other companies, Transparent Edge gives their clients total control of the product through a control panel, to which you access with an authorized username and password. A strong password (with its proper length, letters, numbers, uppercases and special characters) is key so that you have an extra layer of security. However, there are still plenty of people using simple passwords. For these users in particular, but actually for everyone, we’ve recently added the possibility of enabling two-factor authentication (2FA). We want to make sure that the user, and no one else, can access it with its credentials.
The 2FA, or two-factor verification, is one of the most popular systems when it comes to reinforcing user authentication. When it’s active, besides the username and password, we have to add a six-digit code that changes over time. Surely, you’ve done this once or twice. What we want you to know is how we implemented this into our authentication system.
During the design phases of this feature, something was very clear. We were dealing with a wide variety of users with different ways of thinking, so 2FA couldn’t be something mandatory, at least not immediately, since our intention is to always make things easy for our clients. This is why we decided to add a new area in the user section, where each user could activate and deactivate the 2FA based on their own needs.
Precisely the possibility of enabling and disabling the 2FA was another self-imposed requirement, keeping flexibility always in mind. The last important detail during the design phase was the ease of activation. After two years using QR codes thanks to the pandemic, we decided to use these now common images, which are fully compatible with third-party mobile applications such as Google Authenticator or Authy.
With our requirements defined, we started working. The control panel uses -underneath- our own API, which is available to the public. So virtually, the users are constantly making REST requests to the API, although in a more user-friendly way. And the 2FA wouldn’t be an exception.
There were three endpoints or URLs that were enabled for all scenarios. The first one is the most obvious: an endpoint to handle POST and DELETE methods, related to the service’s activation. Through a POST request, there’s a unique key generated for each user, that is stored securely in our database, and the DELETE is used to invalidate said key and deactivate the service.
Although the key is all that’s required to add it to verification apps, in our design route was to offer a QR code, which is much more manageable. So through a series of libraries, we’ve converted the key into a QR code that also includes extra information about the service and the associated user. This way, we return the QR image and the key in the response to the request. And the user can store it securely in a trusted app.
This is a simple process. But, as we continued with the first few internal tests, we had a question. What if the user, for whatever reason, didn’t add the key to their app? Internally, the user may have been marked as a 2FA user and the key would be requested when trying to enter the control panel, but maybe they hadn’t saved it. So we decided to add two safeguards to address this issue.
The first one was to implement the GET method in the same endpoint as the previous POST and DELETE, so the user could retrieve their active key at any time. And to ensure that the key was saved in their app, they would be requested to introduce the 2FA code to complete the activation of the service, so we added a new endpoint that would verify the code.
Now we only need to apply the 2FA to our registration process in the control panel. With a system for user registration and an endpoint implemented for that, we had to delve into its internal workings, to interrupt the established registration with username and password, to check whether the user had a 2FA enabled or not.
In case they had it, the registration process is indicated through the use of special headers in the request, that must display and collect a box for the introduction of the code. Once received by the API, it verifies the user and allows access.
As you can see, it’s a very simple process, but it adds a security layer. Like everything in Transparent Edge Services, we are already considering some improvements for this, the 2FA. For example, company administrators should be allowed to see which of their users have an active 2FA, having this way more control over the security that their employees and co-workers apply.
Ricardo Amador is the Head of Development at Transparent Edge.
If Richi hadn’t been a telecommunications engineer, he would’ve been a voice-over actor. The question is, would he have been as good at it as he is with Python and Django?. Graduated from the Polytechnic University of Madrid, he also went to Sweden to specialize in intelligent embedded systems. Today, there’s no match for him programming APIs and designing software for the only Spanish CDN. An excellent handball player who’s plagued by injuries, he’s also one of those bikers that feel the road without showing off about it.
Compartir:
