Decrypt user password

Next topic

Author	Message
Piotrek Karaś	Wednesday 05 March 2008 10:47:25 pm Hello there, Is there any (especially built-it) method of storing user passwords that would make it possible do decrypt them? Of course other than plain text ;) I thought crypt would be it, but it uses a one-way algorithm, as other hashes... Thanks! -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Bruce Morrison	Thursday 06 March 2008 12:06:35 am Hi Piotrek If you can decrypt them and the code to do so is on the server you may as well store them in plain text anyway. It's more encoding then encryption. If this doesn't matter I guess you could use ROT13 or something similar. http://en.wikipedia.org/wiki/ROT13 There isn't anything built into eZ that would do this. The existing built-in methods are: /// MD5 of password const PASSWORD_HASH_MD5_PASSWORD = 1; /// MD5 of user and password const PASSWORD_HASH_MD5_USER = 2; /// MD5 of site, user and password const PASSWORD_HASH_MD5_SITE = 3; /// Legacy support for mysql hashed passwords const PASSWORD_HASH_MYSQL = 4; /// Passwords in plaintext, should not be used for real sites const PASSWORD_HASH_PLAINTEXT = 5; // Crypted passwords const PASSWORD_HASH_CRYPT = 6; See also: http://ez.no/doc/ez_publish/technical_manual/4_0/reference/configuration_files/site_ini/usersettings/hashtype Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Piotrek Karaś	Thursday 06 March 2008 1:29:38 am Hi Bruce, Thanks for the response! <i>If you can decrypt them and the code to do so is on the server you may as well store them in plain text anyway. It's more encoding then encryption.</i> Yes, I do realize that. But I believe encryption (or even good encoding) would still be a bit more secure than plain text. You may have a number of administration and/or backup scenarios when that's a additional precaution. When db gets broken into and the HTTP server doesn't... etc ;) Back to the issue, what I'm after is a solution that would automatically (with some key/method to it) notify users that they can take certain actions within eZ Publish installation, and that notification in some cases (for example new, imported users, who did not register themselves) should provide access details (login, password). Of course, I could always import users with randing passwords and make them follow the 'forgot password' procedure, but that would be highly discouraging when inviting users rather than forcing them to participate... ;) There's also a path, in which users have to register, but again - that seems equally discouraging. Any thoughts on that? Cheers, Piotrek -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Xavier Dutoit	Thursday 06 March 2008 1:47:02 pm Well, the forgot password on ez is hand down the most unergonomic way to retrieve a new password ever. Other than that, having a one usage only password and force the user to choose a new one after the first login is a nice option. It's been discussed a while ago on the ez dev mailing list. Haven't heard about it since then. Update, anyone ? X+ http://www.sydesy.com
Bruce Morrison	Thursday 06 March 2008 3:03:15 pm Hi Piotrek and that notification in some cases (for example new, imported users, who did not register themselves) should provide access details (login, password). I've had to do this with one site where the original site was converted to an ezPublish one. I ended up writing a script that read the CSV of user details, generated a random password (eZuser::createPassword) and sent a welcome email to the user that included the unencrypted password. I admit that mailing passwords is not the best way of doing it and these days I'd probably create a module view that worked in a similar way as the user/activate that prompted the user to set their password. @Xavier Well, the forgot password on ez is hand down the most unergonomic way to retrieve a new password ever. I agree it's involved but it's pretty standard isn't it? First login one time passwords and a bunch of other login options could be solved by adding workflow hooks to the user module, especially pre & post authentication hooks. If these were in place you could simply create a workflow to add the functionality. Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Piotrek Karaś	Thursday 06 March 2008 9:08:17 pm <i>Well, the forgot password on ez is hand down the most unergonomic way to retrieve a new password ever.</i> I agree, Xavier, that's why for now it's my last resort. <i>Other than that, having a one usage only password and force the user to choose a new one after the first login is a nice option.</i> I do not necessarily think of one usage password, even though that's another interesting case. For now, I need initial password setup, and users remain active in the system. <i>I admit that mailing passwords is not the best way of doing it and these days I'd probably create a module view that worked in a similar way as the user/activate that prompted the user to set their password.</i> Bruce, that's a good idea, by now the closest to what I need and what would be accepted. Actually, this could be bundled with a tool for importing users as inactivated, so that when an automatic notification is sent, the system sends simple invitation to active users and an activation link to inactive ones. Thanks for all the tips! Cheers -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu