Message Icon:*
url email imgsrc image php hide code quote
English Nederlands 
alignleft aligncenter alignright bold italic underline linethrough   



Re: ImpressCMS - Security

by skenow on 2011/5/29 19:21:55

as far as what we do that others don't -
* randomize db table prefix
* separate sensitive data and place in trust path
* randomize the trust path directory name
* randomize the name of the secure data file
* integration with html purifier
* multiple password hash options, selectable by site
* admin warnings for practices not followed
* of course, protector module
Re: ImpressCMS - Security

by david on 2011/5/29 11:45:12

That sounds sensible to me.
Re: ImpressCMS - Security

by Madfish on 2011/5/29 11:39:30

Forgot to add: Session regeneration on login etc.
Re: ImpressCMS - Security

by david on 2011/5/29 11:09:16

On the subject of security - I think it would be a sensible idea to look at moving the cache and compile directories to trustpath.

I notice that xoopscube also had this approach as well - as per this very good ticket suggestion here:

The point about using a prefix is a very valid one, as it is possible I think to share trustpath over several sites on the same host (indeed, this is a possible way of achieving multi-site perhaps)
Re: ImpressCMS - Security

by Madfish on 2011/5/29 9:48:28

Positives: The trust path, use of salts (see Vaughan's posts about how it works), and the updated hash algorithm. Also, support for SSL login and full-site SSL. There's the alternative authentication mechanisms but I haven't used them much so I don't know whether these are security enhancements or just conveniences.

Negatives: I think we have the basics covered. Sending passwords in the clear irks me, but the fact is that it is difficult to address in an out-of-the-box install and as far as I know all major CMS still work that way. I'm still working on adding support for 2-factor authentication (using hardware token) with Vaughan.

I think adding password stretching would be a useful improvement to harden password hashes against offline dictionary attacks, but I'm still arguing the case for that one.