search

RestyaPlatform / board

Trello like kanban board. Based on Restya platform.
http://restya.com/board/
Open Software License 3.0
2.03k stars 382 forks source link

Password sent by email #1189

Closed PenguinzPlays closed 3 years ago

PenguinzPlays commented 7 years ago

As an information security guy, this is horrible practice. Highly recommend removing this and just telling the user the admin changed their password.

ghost commented 6 years ago

+1

charlie-hotel commented 5 years ago

Imagine my horror when coming to report this to find out that this has been sat here for two years. This is a critical bug, sending your users' passwords in plaintext puts them all at risk. I highly recommend that all administrators remove the ##PASSWORD## variable from this email until this issue has been resolved.

Once again, this is not an enhancement, it is a show-stopping, critical bug.

charlie-hotel commented 5 years ago

^ above action unintentional, not really sure how that happened

sridhar391 commented 5 years ago

@virtualcharlotte We are storing the password with encryption and if you have clicked forgot password, the new password will be generated and that new password only sent through mail, not the original password

charlie-hotel commented 5 years ago

The fact that you think that this is okay is absolutely baffling.

The moment that you send a password in plaintext over email, it is compromised. E-mail goes through various hops on its way to its destination, and you cannot guarantee that an e-mail will reach its destination without being read by someone that isn't the intended recipient.

You might say, "but Charlotte, my e-mail is encrypted with SSL/TLS!" - and you'd be misguided. You can't guarantee that every step will be secure. You can't guarantee every hop is going to respect it, and you can't guarantee that that e-mail will be encrypted at rest at the other end.

This practice is okay for sending a temporary password only, but this isn't that, you're sending off the user's actual password, I assume just before hashing and salting it to put it in the database. This is absolutely awful. You can't expect that your users are going to be practicing good password hygiene and security - users will always surprise you with the level of idiocy they can pull out of their hat. It is down to you to take care of your users, and you're not doing that.

I will be pulling this software out of production and switching to an alternative. Your attitude toward this issue is just horrendous, and it makes me wonder about what other corners you've cut in regards to security.

charlie-hotel commented 5 years ago

I should add - I came across this after resetting my own password from the admin panel - on further investigation it looks like you send an autogenerated password in the case of a 'forgot password' reset - this would be okay on its own, but if you decide to change your password after that (as you should!), you use the completely insecure change password function, which then sends your user-generated password as plaintext too! So you have negated all of the security benefits of using an autogenerated password, nice one.

This leaves you with a Sword of Damocles hanging over your head - do you stick with your completely exposed, autogenerated password, which only compromises your restyaboard account? Or do you change your password, immediately compromising the new password?

https://www.troyhunt.com/lessons-in-website-security-anti/

charlie-hotel commented 5 years ago

URLs that result in the leaking of plaintext passwords:

https://boardURL/#/users/[UID]/changepassword <- this one is the real nightmare scenario

Change password functionality at https://boardURL/#/users

rrjanbiah commented 5 years ago

@virtualcharlotte Thank you so much for explaining the issue clearly and patching it.

rrjanbiah commented 2 years ago

Additional notes about the issue for those who're coming here directly.

Previously, the admin can reset a password for another user. When he enters a new password for another user (in the admin panel), that user will receive that in his email. This behavior was similar to that of GitLab at that time (few versions before https://subscription.packtpub.com/book/application-development/9781783986842/1/ch01lvl1sec15/logging-in-for-the-first-time An e-mail will be sent to the given e-mail address. This e-mail will contain the new password for this account.) and was preferred by many instances IT administrators. That was the reason for delaying the fix.

Thanks again to the contributors for the strong push.