Tuesday 05 July 2011 8:19:10 am

Let me see if I understand this correctly... you want to use the password hash instead of a password? 

Is there a reason you want to do this?  I can't think of any reason to do this.

I mean, if it's an intranet where all users are trusted users, o.k. then.  But, then you're still making a security trade-off for convenience...

The whole point of the hash is to make the password not easily readable as plain text - if anyone has (or gets) access to the database, they'll have access to the hashes - which if you use the hashes as a password is essentially storing it in plain text.  May as well just use HashType=plaintext then - well, you would maybe confuse some not particularly bright hacker (http://stackoverflow.com/questions/533965/why-is-security-through-obscurity-a-bad-idea).

If you're the only sysadmin and no one else can get to the database and you trust that no one is ever going to get to that database - then fine... still it's a security risk.

Not that hashes for bad passwords are much security either.  It doesn't take long to go through a dictionary and generate hashes to compare.

Actually, ezpublish should have a login option to use an ini supplied salt...  that way someone would have to hack the database and the file system to get the password from a hash - or replace the hash in the database with something valid.

Certified eZPublish developer
http://ez.no/certification/verify/396111

Available for ezpublish troubleshooting, hosting and custom extension development: http://www.leidentech.com

Tuesday 05 July 2011 2:12:57 pm

>Ok someone has access if the password_hash was stolen but this can happen with a login/password too.

Not correct, if you expose hash login by url you expose your self much more for brute force attack as well as having zero protection if hash from db is stolen.

What is the use case for this exactly?
I would probably have done something similar as user activation, where you have a separate user hash in a separate table, and make sure it can only be used once and preferably within a certain time limit.  Preferably also with a key in the url as well and a secret salt so that hash can only be used for a certain user, as well as hash in db not being the same as in url.

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Tuesday 05 July 2011 3:22:54 pm

One more thing: using POST instead of GET for authenticating users is also very important.

- GET params are left in the apache logs and in the logs of all proxies in the chain browser-server. Good luck keeping those safe

- in http protocol get requests are idempotent, ie. they change no state. So bots spiders and other random robots are allowed to follow any link they find using GET calls. So you are encouraging in fact the world to try to bruteforce your passwords at least on the on the theoretical level...

- ...but on on the practical level too: using nefarious js on an end user browsers that sends a get request to the server and it keeps trying random hashes until it does not get back a bad-password page, all without telling the user of course is hacking 101 - heck, even I could probably write that script. So you actually allow distributed pen-testing for everybody...

Principal Consultant International Business
Member of the Community Project Board

Tuesday 05 July 2011 3:33:28 pm

Thank you for all those informations, i understand now why its not a good idea to do it that way.

The aim of all this was to insert into the confirmation email not only the login/password but a clickable link that would instantly logged users in the website without having to re-enter their login & password.

The problem is if i make a parallel user activation process with a limited life time hash how this link could be reusable ? Because the only benefit of this link is if its reusable.

EZP is Great

Wednesday 06 July 2011 9:55:33 am

Yeah, I meant a random salt.  The site name is not going to be hidden most of the time... and a salt that ain't secret is (mostly) useless.

Just to be precise: the parameter used as salt is called SiteName but it has actually no relation to real site name. You can just make it a random long string.

And you can use chown and chmod to make site.ini only readable to apache process. That's generally a good idea, as it also contains password to connect to the db.

Last thing: known salts are still useful. They make usage of precomputed dictionaries useless. Knowing the salt the attacker can start to calculate hashes of probable login/password pairs and test them, but it's still gonna take a much longer time than using off-the-shelf dictionaries where little calculation is necessary.

Principal Consultant International Business
Member of the Community Project Board

Thursday 07 July 2011 5:28:31 am

Just to be precise: the parameter used as salt is called SiteName but it has actually no relation to real site name. You can just make it a random long string.

And you can use chown and chmod to make site.ini only readable to apache process. That's generally a good idea, as it also contains password to connect to the db.

Last thing: known salts are still useful.

Yes, on all counts.  I never realized SiteName could be anything - when I last looked at it I thought it had to be the actual SiteName.  I guess I'll be changing some HashTypes now.

Certified eZPublish developer
http://ez.no/certification/verify/396111

Available for ezpublish troubleshooting, hosting and custom extension development: http://www.leidentech.com