Change /etc/shadow password interest?

[kali]

Any interest from the community?

I'm pretty sure I can use the VERY pretty integration already done for IMAP passwd change and use the chpasswd utility for changing system passwords for users (using /etc/passwd or /etc/shadow). Useful if users are local systems users (ie. home directories, samba, uw-imap etc.)

If there is interest - I'll get to this. Seems very straightforward (and secure!) given the work and bug fixes already incorporated into this and squirrel's mod.

[bozhe]

Kali,
I, for one, am quite interested. We also connect (currently) to a SquirrelMail installation on a redhat server.
Thank you, in advance, for any work that you do in this regard.

bozhe

[kali]

I have looked at the existing scripts (for "pretty" integration into RC) and the pw change scripts (from SM which are very good). Here's my problem - it requires changes to multiple RC files in order to gracefully add this tab to the preferences area, but is pretty doable.

This in turn, however, will require a new .patch for every version to patch. One of the really nice things that Squirrel did was to design a plug-in schema so that core code could change and plugins could stay the same. Early on, some of the plugins for squirrel also required new patch files for each and every version of the app (notably the nice icons patch) and that was just not long-term sustainable.

So - for now, I'm looking at just linking from the login page to a distinct change password page (ssl) or from within RC (add to footers) so that users are already authenticated and can pick up the $user attribute.

[matt2minger]

when u say default value for activation is 1. Do i need to alter something in the script or do u have a mysql code u can send me which i can alter to fit my domain because i can run it directly in phpmyadmin, becaue i think the problem is coming from mysql.

cheers matt

[Heritz]

Very interesting kali. Do you need support in PHP development? let me know, maybe I can give you a hand. Actually my server store the passwords in shadow files, like you said and I would like to let my users to change their password through RC.

PM me so I can provide you with my MSN or Gtalk.

[kali]

Hi Heritz - very nice offer.

I currently have it running quite successfully as a secure cgi script which just links from RC. Easy- no mod to RC while it's changing so much (other than the link). Would, of course, be "nicer" if it was a tab in preferences.... but unless I'm missing something, that will require a new patch for each released version.

What do you think?

[Heritz]

Ya well, you will need a "plugin patch" for each release. I am not a CGI expert, but if we can translate the CGI code and apply it to PHP we can create a really nice mod.

I really don't care about making a "patch" for each release, the changes will be minimal and this guys release a new version every 3 months or more, which is not that bad.

Actually there is an excellent patch that modify the password stored in mysql databases. It works if you configure your server to store the passwords in MYSQL DB; in our case, the passwords are stored in shadow files, encrypted with md5crypt which is kinda different.

The patch is already done, with the preferences tab and all that stuff. We can take that patch, use the template files, and work over the "main core" file to make it able to edit the passwords in shadow files.

cPanel has a CGI script that let you edit the password in the e.mail accounts. Are you using that script? I mean, we can use it to start browsing the commands.

[kali]

Changing passwords in MySQL is "easy" - as the PHP script already has defacto access to the database. Reason it is almost always a cgi to change shadow pw's is that you need root access to do so (which the web server, and therefore any PHP script, does not have - or at least should not have). So the cgi for this purpose is typically a setuid program which can then access/modify the shadow pw file.

Password changing itself is fairly trivial, as you can even call the system passwd utility via cgi - but again, you either need that user's credentials or root (the more usual approach).

[Heritz]

So, the solution for us is to use a CGI script. The thing is, using a CGI script under a secure conection will ask the user again for an username and password.

My question is, how are you validating the access to that script? I mean, if you don't secure it, anyone can access to the script and hack the accounts.

[kali]

Originally Posted by Heritz

So, the solution for us is to use a CGI script. The thing is, using a CGI script under a secure conection will ask the user again for an username and password.

Yes, that is correct. I've not really played with this, BUT - 1. that may not be a bad thing (verify username/pw to proceed) and 2. it would not be hard to pass that value to the script if one wanted.

My question is, how are you validating the access to that script? I mean, if you don't secure it, anyone can access to the script and hack the accounts.

At the moment that too is correct - although allowing access only via referral from RC is possible (I suppose). As to "security" - that is a tricky one. You suggest that allowing global access to the script is not "secure", but I don't see how that is any less secure than allowing global access to the webmail app itself which in turn allows access to the script. In either case - one needs an existing (and valid) id/pw pair to proceed.

The pw change cgi requires input of id - existing pw - and new pw (twice) to proceed. If it fails - it's logged, and takes it's time giving a new screen (to thwart rapid dictionary attacks). Personally - I see this as no different than having an SSH daemon listening and available to "the world".

Perhaps in more practical terms - I only have a reference to the pw change cgi from within rc and then it is a cryptic url (which as a link is easy - but is not easy to guess or scan from outside).