User password encryption


We are using a basic strapi for the back-end of a web-app we developed. We have to encrypt the password before sending to the api due to corporate security regulations. Is there a way to add this to user-permissions plugin of strapi?

Instead of sending the password as cleartext, we’d like to encrypt it in our app before sending to strapi. Then decrypt on strapi and save it with strapi’s encryption.

Otherwise it’s creating a vulnerability to send the password as cleartext.

Hope I could explain it well. :pray:t2:


System Information
  • Strapi Version: 4.0.7
  • Operating System: Ubuntu
  • Database: sqlite
  • Node Version: 16.13
  • NPM Version: 8.5.2
  • Yarn Version:


You need to modify the file in node_modules/@strapi/plugin-users-permissions/server/controllers/auth.js and paste it into a new location inside your project. In this file, inside the “callback” function, lives the code you need to modify for change the way you login to “/api/auth/local”. Once modified, you need to overwrite the file inside the node_modules on the same path. With a simple “postinstall”: “cp -r path/of/your/local/file node_modules/path/to/the/same/file” script inside the package.json you’ll make it. Greetings for someone who wants to edit the strapi-admin package in the same way without achieving it yet :frowning: .

1 Like

Hi, thanks for your answer. I didn’t want to edit any package in node_modules so I kind of hacked as double encrypting the password both on front end and back end. It let us pass the security test but definitely not the ideal solution as one can still login using hashed password.

That’s just not true, that’s what HTTPS is for, it encrypts data in transit, don’t reinvent the wheel and just make sure your site is HTTPS only with HSTS and things like this

If your encryption key is public on the frontend, there is no point in encryption. If you generate it on the server and send it unencrypted, do you think the attacker who managed to also read the password in transit is not gonna have access to this key? Effectively you’d need to reinvent TLS which is a big feat for no added benefit, since transit attacks have become almost extinct since HTTPS is widespread

Instead attackers try to gain access to endpoints (either server with penetration or client via XSS) and they can get unencrypted data once they have access to those endpoints, whether you encrypt the data or not