Site and Server Security

Re: we need to integrate new password algorhythm ASAP

  • 2008/3/11 16:59:11
  • Will

This all seems so nostalgic... I could swear this has been discussed and ignored before.

@vaughn, hilarious.

Report
Topic


Re: we need to integrate new password algorhythm ASAP

the new password branch in svn uses 2 salts to hash the password with and then the final password +2salts is hashed using sha256.

it's basicly (broken down)

$pass_plain = 'plaintext_password'; $pass_salt = $userSalt.md5($pass_plain).$mainSalt; $final_hash = sha256($pass_salt);



that's a very basic description.

each of the salts is 64 characters long they are added to the pass_plain which is md5 before adding the salts.

then sha256 the result.

basicly sha256 is now hashing a 160 character password.

i don't think that can easily be bruteforced or decrypted. lol

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!
Report
Topic


Re: we need to integrate new password algorhythm ASAP

Good idea. Suggest also adding a password salt to make hash cracking more difficult when users choose a weak password, as no hash algorithm can protect against dictionary attacks.

I looked into this for xoops a while back. I could be (badly) wrong, but it looked like a new algorithm could be substituted in directly without any large code changes. The main issue was what alternative hashes are widely shipped with php.

The salt could be set in the installer, and also shouldn't require much changes beyond that.

If you want to know the truth do not listen to what people say. Look at what they *do* and you will know their heart.
Report


we need to integrate new password algorhythm ASAP

i just provided an online demonstration of an exploit in xtorrent module to it's author.

in the demonstration i obtained his admin uname, password hash & email address.

scarey? well not as scarey as the fact it took 2 seconds, yes 2 seconds to decrypt the md5 hash back to plaintext.

i then logged in using the decrypted plaintext pass.

i created a custom block from admin, with info of the demo.

http://www.unseen.org.au/

i have not done anything serious to the site, and the owner does now accept that sql injection is a major cause for concern. & he is aware of my access.

really if it took 2 seconds to decrypt the hash to plaintext and login, then we really need to push the new password encryption branch into 1.1 ASAP. in fact it's a security necessity..


Attach file:


png  snapshot3.png (0.00 KB)

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!
Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

Ok I see it now. We know what we are doing - that's important. Thanks

Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

  • 2008/3/7 4:21:35
  • Will

require '../../mainfile.php' is not dynamic. This string forces the script to look in the document root.

it would need to match your location.

in the case that you position your mainfile.php in your subroot

require '../mainfile.php'

in the case that your mainfile is in your trust_path

require XOOPS_TRUST_PATH '/mainfile.php'

etc., etc.

I am sure that GiJoe would encourage moving tha mainfile into the XOOPS_TRUST_PATH.

Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

oops, this does not work for one php script of D3 modules': the "module_icon.php" under XOOPS_ROOT_PATH/modules/<d3_instance_name>/ . As of it, D3 instance images (module_icon.png) will not show up.

Note: module_icon.png is dynamically created by module_icon.php (using gd). The module_icon.php reads

<?php $xoopsOption['nocommon'] = true ; require '../../mainfile.php' ; if( ! defined( 'XOOPS_TRUST_PATH' ) ) die( 'set XOOPS_TRUST_PATH into mainfile.php' ) ; $mydirname = basename( dirname( __FILE__ ) ) ; $mydirpath = dirname( __FILE__ ) ; require $mydirpath.'/mytrustdirname.php' ; // set $mytrustdirname require XOOPS_TRUST_PATH.'/modules/'.$mytrustdirname.'/module_icon.php' ; ?>

Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

Very clear now. Thanks

Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

If there's a certain type of server problem - which disables php running as code - then the variables of mainfile.php can be visible.

This way - the values are not as easily available in the event of this problem happening.

Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

Thanks Will.

What is the advantage of this to the solution of the current icms installer that move away MySQL info from mainfile.php? (I believe it's credited to xoops-tips.com)

Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

Definately a good idea to look at for 1.1.

Report


Re: Turkey is on the road again

Thanks for the warning!

Report


Turkey is on the road again

Just to inform you all.

Today I found the entries as shown in the pictures below in my 'log' (Php-Stats).
I've blocked all 3 IP's but will probably block the whole IP-ranges from Turkey soon. Note that 1 IP belongs to Amazone...
I am glad I got Protector installed.
For sure that more XOOPS websites are under attack at the moment.





Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

I almost forgot.

I set chmod permissions on the trust_path and mainfile_path folders to 750 just like public.

As far as permissions for owner and groups on the two folders outside of public. I set those to the account.account

Then all three of the mainfiles are set to 444.

I do need to check with the host about the 444. They might want to keep the chmod 644 like the rest of files...

I 'll post back if thats what they recommend.

Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

Now that was a killer post dude! Perfect...

I now have a trust path and a different mainfile path out side of public. This install is the tightest I have ever been able to get this software. I feel like a proud poppa...

Ty Will

Report


Re: Impresscms Trust_Path Permissions? chmod owner & group...

  • 2008/2/10 12:58:34
  • Will

This isn't a web accessible folder, and if you are seriously worried about your trust path... hide it.

how?

Easy make a duplicate of your mainfile.php and hide it below your root folder.

Open public_html/mainfile.php

and replace it with the folowing.

<?php if (stristr(htmlentities($_SERVER['PHP_SELF']), "mainfile.php")) { Header("Location: index.php"); die(); } include("/path/to/your/new/mainfile.php"); ?>


^^I strongly believe in placing config files below the webroot, and in essence that is exactly what mainfile is.

Now you can name and place your trust path wherever you like it via your uber protected mainfile.php.

Report


Impresscms Trust_Path Permissions? chmod owner & group...

Hello, I just installed the impresscms_1.0_rc.tar.gz for the first time. On a server running php with a handler called suphp.

My question is related to the trust_path of impress and the correct permissions the folder needs to be set at.

All the impress files are chmod 644 and folders are chmod 755 inside of the public_html directory. Except for the mainfile which is set to chmod 444

Also in order for the cms to work the owner and group permissions need to be set as well. This is called chown in the server management world.

The layout of those are

chown account.account -R /home/account/public_html/

This gives all files and folders a setting of
owner = account & group = account

and

chown account.nobody /home/account/public_html/

Make sure your public_html folder is set to
owner = account & group = nobody

-----

Like I said above this post is related to the impress trust_path folder.

So what would be the correct permission for this folder to have the most secure environment possible? Meaning what should the chmod, owner and group be set to prevent hackers?

Thanks for your time...

Regards

Report


Re: Php handlers like suphp as related to .tar.gz file ownership (chown) and permissions (chmod)

Installing impresscms on a server with the suphp handler enabled.
_______________________________________

Using Putty or WinScp Custom Commands (chmod)
Logged in under root or accountname
-----
Warning:

cd to/correct/dir/first

#1

chmod -R 755 *

Changes all files and folders to 755 First
All I do is right click public_html and run from winscp

You can paste in winscp custom command and check the remote command box. Save it

#2

find -type f -print0|xargs -0 chmod 644

Searches for all non-folders and chmod them 644
All I do is right click public_html and run from winscp

You can paste in winscp custom command and check the remote command box. Save it
______________________________________


Using Putty Only from Root (chown)
-----

chown account.account -R /home/account/public_html/

chown account.nobody /home/account/public_html/

______________________________________

Last step go back and make sure your public_html folder is still set at default.

chmod 750

______________________________________

Server security is the name of the game.

I will be posting a little later about setting up your trust_path in impresscms. These are pretty tight settings. So it should be interesting.

Report


Re: Php handlers like suphp as related to .tar.gz file ownership (chown) and permissions (chmod)

I have tested and tested this every way I can think of. Root and account owner makes no difference. impresscms.tar.gz all files and folders are 775 uncompressed. Xoops.tar.gz all file and folders are 777 uncompressed.

What is used to make these releases?

Report


Re: Php handlers like suphp as related to .tar.gz file ownership (chown) and permissions (chmod)

Quote:


Dave_L wrote:
Files in a .tar.gz always have permissions. When extracting the contents of a .tar.gz, I think it works like this:

If the current user is root, the permissions are preserved. If the current user is not root, the permissions are overridden by the umask setting. tar has options for modifying this behavior.

Of course, this only applies to Linux.



Im am going to go back and check this tonight to confirm what you said. I cannot remember if I checked both ways on upload and when uncompressing the archive. Meaning as root and as account holder.

If this rings true then the only thing needed would be to update docs. For us newbies... Should be something to the effect never use root to upload or uncompress the archive.

Which looking back now might be something every server admin knows anyway. But doesn't cover us back yarders we learn by mistakes...

Thanks for the post and the idea...

Can this topic be moved to the server security forum? I think it might be better in that section. Which I did not see when starting this topic.

Report