Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Security about sending password in clear
Hello dear developers,
i have been concerned about sending the password in clear on user creating/resetting password.
I’m running a website with a really big number of author (simple writer privilege) and having all these password in in-boxes knowing that no-one will bother to change them makes me feel uneasy.
At the moment i’m the one who create users so i prefer to not use mem_self_register.
Have any idea of an alternative ?
I am thinking about a solution of sending a logging link in email with some nonce valid for only 48 hours. What would be the catch in term of security ? I know it’s far from perfect but it is not sensitive date. And the site needs as frictionless as possible login system (i had case with people not succeeding in logging …).
Furthermore, logged-in users post data through the public side, they are not accessing admin pages.
Is it possible to use the txp_discuss_nonce table to manage the nonce ?
Thank you for any hindsight :)
By the way if you want to check it out, this is the website lereacteur.info
Offline
Re: Security about sending password in clear
Yes, the login system Textpattern has is pretty sad. The public-side login is designed wrong, and resetting should need some work. On admin-side the login cookie contains the user account’s name, but otherwise the admin-side login system is properly done and isn’t vulnerable for anything. The admin-side is super-safe.
The public side login on the other hand; do not use it. It is not designed to protect anything valuable. That public-side session is weaker than any short password (making it the weak link) and the session is stored plain-text on the server. Public-side login neither expires and is vulnerable to replay attacks until you actually log out, rather than let the cookie to expire.
Keep in mind that some of those login plugins don’t resolve that. Most of them use the built in login system, and some add to the pain. For instance, it bet that some plugin doesn’t generate new sessions when you log in to prevent the admin-side login session from ending. That then again, is by definition a session replay vulnerability.
The session, login and password reset system will be reworked for Textpattern 4.6.0 and these issue will be, once for all, resolved.
planeth wrote:
Is it possible to use the txp_discuss_nonce table to manage the nonce ?
Those aren’t private, but instead meant for time based form expiration. You want values that are tied in to specific user account and are both stronger than any password could ever be, can not be read from the database and can be invalidated.
Basically, you will want to store hashed of reset keys in database, tied into the account and an expiration date for it. You can tie in the reset links to specific account and prevent collisions by using a value that is unique to the account, but can not be used to log in. In Textpattern such value would be the user_id. The reset hash can be a pseudo-random value constructer from some semi-unique seeds.
Offline
Re: Security about sending password in clear
Hi Jukka, thanks for the clarification.
Really looking forward to the reworked system.
Gocom wrote:
You want values that are tied in to specific user account and are both stronger than any password could ever be, can not be read from the database and can be invalidated.
What do you mean by cannot be read from the database ?
Gocom wrote:
You can tie in the reset links to specific account and prevent collisions by using a value that is unique to the account, but can not be used to log in.
Would this link be sufficient to log a user in without too much security issue ?
Offline
Re: Security about sending password in clear
planeth wrote:
What do you mean by cannot be read from the database ?
Quoting myself:
you will want to store hashed of reset keys in database
Just like with passwords, any type of access tokens shouldn’t be stored in plain text, but hashed, as long as its possible. Otherwise compromised database leaks the login sessions.
Would this link be sufficient to log a user in without too much security issue ?
The link takes you to password change screen. But yes, basically it would log you in. It’s not anything complicated; you don’t have to anything more than generate a pseudo-random value, hash it, store it in database with user_id and expiration date (or date created), and send a link to the user with a link containing the value and user_id.
Then on the return page validate the id and the value against the hash. If it comes green, return a form to change the password. User changes the password, you save the new password in, invalidate the reset token and create a new session for the user.
Last edited by Gocom (2013-11-05 12:27:13)
Offline
Re: Security about sending password in clear
Gocom wrote:
Just like with passwords, any type of access tokens shouldn’t be stored in plain text, but hashed, as long as its possible. Otherwise compromised database leaks the login sessions.
Ah, that’s make more sense to me !
Gocom wrote:
The link takes you to password change screen. But yes, basically it would log you in. It’s not anything complicated; you don’t have to anything more than generate a pseudo-random value, hash it, store it in database with user_id and expiration date (or date created), and send a link to the user with a link containing the value and user_id.
Then on the return page validate the id and the value against the hash. If it comes green, return a form to change the password. User changes the password, you save the new password in, invalidate the reset token and create a new session for the user.
Ok, i think i’m gonna implement this solution without taking to change password form (too much confusing for basic user)
Offline