Background information

In the HR industry, data protection in SaaS (Software as a Service) mode is essential. Several years ago, we adopted a continuous improvement process in this area.

Below, you will find all the latest updates Lucca has made to the platform and its applications.

Password protection

Best practices for hashing and password storage are as follows:

  • Use a slow and irreversible hashing algorithm
  • Make hashing unique by salting passwords
  • Do not accept ‘simple’ passwords

We chose a tried and tested hashing algorithm known for its slow encryption setting. Because the passwords are irreversible, the encrypted password (hash) stored on our platform cannot be used to recover the original password. Consequently, if these data are stolen, they cannot be exploited directly.

We salted the process. Adding salt means adding our own key. The hashing algorithm is proven of course, but without the salt, password hashes can be exploited using ‘rainbow’ tables. These tables make it possible to compare stolen password hashes with previously generated hashes. Adding salt makes our password hashes unique.

Lastly, we tightened our requirements in terms of password complexity. Instead of simply requiring a certain number and variety of characters, we calculate the password’s complexity using a library integrated into Lucca. This system makes it possible to show how strong the chosen password is when it is entered. That said, a minimum of 8 characters is still required.


Email encryption

There is a secure version of each protocol. Some are better known than others.

  • HTTPS for HTTP: this is your web browser’s main job
  • FTPS or SFTP for FTP: this protocol is used to transfer files for automated imports or exports
  • SMTPS or SMTP TLS for SMTP: this is the secure version of the protocol used to send emails

We have been using secure versions of FTP and HTTP protocols for several years. However, the secure version of SMTP is less known and some of our clients (4%) are incompatible with it.

We changed SMTP servers so we can adapt to each one, depending on the requirement level. In fact, our new SMTP server negotiates the highest level of mutual encryption with the client’s email server. Once communication is established, we send the emails through this secure channel. For clients who are not equipped, emails are sent unsecured.

When this was implemented, it also improved our reputation with anti-spam systems.

Setting up a WAF (Web Application Firewall)

The application firewall is a protection that allows you to shield yourself from SQL injection attacks. This attack remains no.1 on OWASP’s vulnerability classification.

The WAF makes it possible to analyse incoming requests and block attacks. It took time to refine the WAF’s configuration to reduce the rate of false positives (blocking normal use) while keeping optimal protection. The WAF is configured as a whitelist.

It takes us less than 5 minutes to detect an SQL injection attack.

Sending cookies in HTTPS only

We implemented a recommendation from a security audit report after this audit took place on our platform: blocking cookies from being transferred when the transfer is unsecured. On the first call, it is common for the user to not enter the ‘s’ in httpS://

If they already visited the website, they probably already have session cookies.

A session cookie is information needed for a web application to work properly. This information is stored on the user’s computer by their browser and sent to our server upon each exchange.

This exchange is secured if the HTTPS protocol is used. However the cookie was not sent securely on the first call. From now on, cookies are not included in unsecured exchanges.

To learn more, here is a link to OWASP’s explanation of the problem.

Clickjacking protection

Clickjacking is an attack that involves integrating one site into another, using an iframe, masking the subsite address.

We used OWASP’s recommendations to protect our clients from this type of attack by prohibiting our applications from being integrated into iframes. Beforehand, we identified and contacted all clients affected by this type of integration.

To learn more, here is a link to OWASP’s explanation of the problem.

Page content

Was this article helpful?
0 out of 1 found this helpful