|
Author
|
Message
|
|
H-Works Agency
|
Monday 04 July 2011 10:40:45 am
Hello everyone, Is there a problem about login users only with their password_hash ? Is there security problems using this approach for login apart from someone retrieving the password_hash ? Which is not a real problem as it concerns login/password couple too. Thanx for any help.
EZP is Great
|
|
Steven E. Bailey
|
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
|
|
H-Works Agency
|
Tuesday 05 July 2011 10:00:35 am
Hello Steven, Let me explain my self better. What i am trying to do is making an "autologin" view like this : /custom/autologin/$PASSWORD_HASH Inside this view a sql query search for a matching user with this hash and grant access if founded. My question is : Is this secure enough ? Ok someone has access if the password_hash was stolen but this can happen with a login/password too. If this approach is wrong what variable should i put in my autologin link to identify registered users ? Thanx in advance.
EZP is Great
|
|
André R.
|
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
|
|
Steven E. Bailey
|
Tuesday 05 July 2011 2:26:24 pm
Well, with that approach, all I have to do is write a script to generate random hashes and eventually I'll be logged in as a user. I'd bet that with that approach I'd be logged in as a random user within a day. Of course, that depends on how many users you have, etc. I suppose you could set up a fail2ban script to parse the apache log files to lock someone out after too many failed attempts.. but, that's a lot of overhead. But, otherwise, what would prevent me from writing a script to just keep banging on your machine - going through proxies of course - until I'm logged in? The thing is, if you have a user, then you can code for - if someone attempts to log into this user X number of times, silently fail. With a hash... there's really nothing you can do... you can't go by IP address if someone is using TOR and proxies. There's nothing you could go by. On the other hand, if it's an intranet and one branch is coming from one ip you'll end up having false positives. I guess, if your /custom/autologin/$PASSWORD_HASH also has an input field with the username, that it can cross reference to the hash... that would allow you to break if the username is hit too many times - but then, if someone has to do that, they may as well just do the username/login - unless of course there is a good reason not to. Edit: change a can... to a can't go by IP...
Certified eZPublish developer
http://ez.no/certification/verify/396111
Available for ezpublish troubleshooting, hosting and custom extension development: http://www.leidentech.com
|
|
Gaetano Giunta
|
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
|
|
Gaetano Giunta
|
Tuesday 05 July 2011 3:28:26 pm
"
... 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
"
Breaking news: eZ Publish haz salt! Can I haz cheesburger? HashType=md5_site in site.ini Now, maybe we could have this on by default, with a salt generated at random by the setup wizard, to get dictionary attacks definitively off the map. Anyone feeling like they have spare time for a pull request? :-)
Principal Consultant International Business
Member of the Community Project Board
|
|
H-Works Agency
|
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
|
|
Steven E. Bailey
|
Wednesday 06 July 2011 4:13:27 am
"
Breaking news: eZ Publish haz salt! Can I haz cheesburger?
"
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.
Certified eZPublish developer
http://ez.no/certification/verify/396111
Available for ezpublish troubleshooting, hosting and custom extension development: http://www.leidentech.com
|
|
Gaetano Giunta
|
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
|
|
H-Works Agency
|
Wednesday 06 July 2011 10:57:27 am
I have another option to reach my final goal is to be able to login users in another siteaccess with the loginUser() method. Is it possible ?
EZP is Great
|
|
Steven E. Bailey
|
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
|