Custom Password fields not encrypted

[abanchev]

Describe the bug
Password fields in custom Content Types are saved as clear text in the database. The default User type password field is working as expected.

Steps to reproduce the behavior

1. Install a new strapi
2. Create a new content type
3. Add a password field and save the content type
4. Add a new item in the content type list, and set a password.

Expected behavior
The database should have the password saved in an encrypted format. Instead we can read the password in clear text.

System

• Node.js version: 13.12.0
• NPM version: 6.4.14
• Strapi version: 3.0.0-beta.19.5
• Database: mysql, and sqlite
• Operating system: ubuntu

Additional context
Happens both when saving from the admin interface and when using the api calls in the bootstrap to generate the Content type.

[lauriejim]

Hello @Halfsoft !
Thank you for reporting this.
Ping @alexandrebodin about that.

[alexandrebodin]

Hi, The password field has indeed never been encrypted by default except in the users-permissions and admi models because there is custom code implemented to do it.

This field is more of a input type feature right now. You should customize your controllers to do the encryption on your own for now.

If we were to implement the encryption directly we will certainly need to put a bit of thoughts into it.

• Configurations
• How would this work with the APIs.

Can you share your usecse so we can improve this field ? Thanks !

[abanchev]

I think the description in the content builder should be fixed to specify that the field is not encrypted, but stored as plain text.
A better interface would be to have the hashing options in the Advanced Settings, so a hash function drop down that may be also set to NONE for people that don't need or want the hashing (and backwards compatibility).

My use case is nothing specific, i just created a Person content type that works as User, more or less, but without roles and with other custom fields.

[alexandrebodin]

Ok thanks. Yes i think we will need to provide a minimum of feature for it to make sense and allow disabling the encryption to be handled by the user itself if desired. WIll put this into our backlog :)

[amroakmal]

@alexandrebodin
Can you please clarify more what's needed in to be done in this issue?
Thanks!

[derrickmehaffy]

@amroakmal it's in our backlog for now so at the moment we don't have an implementation plan.

[alexandrebodin]

@amroakmal If you want to contribute here is a gist of it:

• Adding support for auto hasing with bcrypt like done in the users-permissions plugin.
• Allow to disable the auto hashing so it can be done manually (lifecycles) if the dev wants to use another method

[amroakmal]

@alexandrebodin

• So, what I understood in the first point is to hash the given user password using the bcrypt package/library.
  Is that correct? If so, please assign this to me, I'll try to make it.
• I didn't get the second point honestly.

Thanks so much in advance for your precious time.

[alexandrebodin]

A user might want to encode a password type with another method :) the goal is to allow to disable the auto hashing behavior once it is added so that a user can do sth else entierly (basically go back to how it is right now)

[bchill]

Indeed, I would also like to be able to use SHA256/SSHA512 passwords instead of bcrypt to make the profile info shareable with another service.