The "password" auth system stores password as plaintext!

[crazyscientist]

A comment in #222 gives instructions on how to create a user for local authentication (aka. password auth system). This instruction is shared in #244. Also, #268 encourages people to use the password auth system.

There is just one problem: The password is stored as plaintext in the database.

Example:

>>> from helios_auth.models import User
>>> u = User.objects.create(user_type='password',user_id='nemo@example.com', info={"name": "Andreas", "password": "my-secret-password"}, admin_p=True)
>>> u.user_id, u.info
('nemo@example.com', {'name': 'Andreas', 'password': 'my-secret-password'})

[benadida]

Yes, in plaintext, by design. I know this sounds scary at first, but consider the following:

• the password is randomly generated by Helios, not selected by the user, so it's not going to be reused anywhere else.
• it's per election, so it's valid only for casting a single vote.
• it has to be sent to the user by email.

Put all of those together, and there's little value and a good bit of cost to hashing/bcrypting these passwords.

If they were broad-purpose user-selected passwords, that would be a very different story.

[crazyscientist]

Thanks for the quick reply.

Having spent only a few hours with the UI and source code I have noticed two different "user" models:

• Voter, which also stores a plaintext password and seems to be the model you are referring to.
• User, which is the model used for admins and election organizers.

For the Voter model, which is used for authentication during the voting process, your design choices make perfect sense to me.

But the password stored in the User model, which is used for the log in of admins and election organizers, is not a one-time password. Storing it as plaintext might be considered a bit risky.

[benadida]

Hi @crazyscientist you're right about where it's stored, but to be clear password-type users are never election organizers / admins. I agree with you that, if they were, that would be a more problematic design.

[crazyscientist]

password-type users are never election organizers / admins

While this is true for the publicly available service, which only offers Google and GitHub, for a self-hosted server this might not be true. It only takes two env. variables to force the server to use password-type users.

PS: Sorry for dragging you into this discussion. My original intent was only to share my discovery with people inclined to host their own service and disable 3rd party authentication services.