Junior Member
I've got s couple of suggestions, both come from the new WordPress 2.5 series. (taken directly from the wordpress blog post regarding 1.5)
[b]Secure cookies[/b]
Cookies are now encrypted based on the protocol described in this PDF paper. which is something like user name|expiration time|HMAC( user name|expiration time, k) where k = HMAC(user name|expiration time, sk) and where sk is a secret key, which you can define in your config.
Link http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf
[b]Salted passwords[/b]
We now use the phpass library to stretch and salt all passwords stored in the database, which makes brute-forcing them impractical.
Link: http://www.openwall.com/phpass/
Perl Module: http://search.cpan.org/%7Ezefram/Authen-Passphrase/lib/Authen/Passphrase/PHPass.pm
These are two ideas that I believe can keep zenPhoto in front of other photo gallery software in terms of security.
[b]Secure cookies[/b]
Cookies are now encrypted based on the protocol described in this PDF paper. which is something like user name|expiration time|HMAC( user name|expiration time, k) where k = HMAC(user name|expiration time, sk) and where sk is a secret key, which you can define in your config.
Link http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf
[b]Salted passwords[/b]
We now use the phpass library to stretch and salt all passwords stored in the database, which makes brute-forcing them impractical.
Link: http://www.openwall.com/phpass/
Perl Module: http://search.cpan.org/%7Ezefram/Authen-Passphrase/lib/Authen/Passphrase/PHPass.pm
These are two ideas that I believe can keep zenPhoto in front of other photo gallery software in terms of security.
Member
I haven't looked at ZP's use of cookies yet, but I doubt any sensitive information is stored in them. At least, I would hope not. I would rather see everything stored in a session table than cookies.
As far as brute forcing passwords. It takes a long time to brute force an MD5 hash. At least a few hours for a traditional six character password. Is it really worth it to change the password system?
As far as brute forcing passwords. It takes a long time to brute force an MD5 hash. At least a few hours for a traditional six character password. Is it really worth it to change the password system?
Member
Cookie encryption is quite useful regardless of how much is stored in the cookie or the session table -- the encrypted cookie protocol prevent replay attacks. Stealing a cookie and then being able to appear as the original, authenticated, owner is a much bigger problem.
Unsalted passwords are certainly a risk. Stored dictionary attacks means a good portion of passwords would fall in seconds.
Unsalted passwords are certainly a risk. Stored dictionary attacks means a good portion of passwords would fall in seconds.
Member
Member
Probably not, but it all depends on the value of what you are trying to protect.
People often re-use passwords, so compromising a ZP password may give an attacker access to other accounts for other things they have elsewhere.
If someone was able to hijack an admin's session, they would be able delete entire galleries, view protected or unpublished content, or upload undesirable content. A probable attack vector would be a cross-site script -- given the way people modify the theme templates, it not unlikely they could introduce a vulnerability that stores or display unscrubbed comments, for example. Or a target site may be exposed through other software on the site, like a forum.
I don't think the odds are high of either attack, but they aren't zero, either. Not to mention the negative effect on ZP's reputation if a high profile site were to be successfully defaced or destroyed in such a way.
People often re-use passwords, so compromising a ZP password may give an attacker access to other accounts for other things they have elsewhere.
If someone was able to hijack an admin's session, they would be able delete entire galleries, view protected or unpublished content, or upload undesirable content. A probable attack vector would be a cross-site script -- given the way people modify the theme templates, it not unlikely they could introduce a vulnerability that stores or display unscrubbed comments, for example. Or a target site may be exposed through other software on the site, like a forum.
I don't think the odds are high of either attack, but they aren't zero, either. Not to mention the negative effect on ZP's reputation if a high profile site were to be successfully defaced or destroyed in such a way.
Member
By the way, dictionary password attacks work by guessing the password. So no matter of "protection" will prevent that attack from working if you have selected a weak password.
A brute force scheme can only give you something that will work as a password for zenphoto. There is no reason to believe that the same generated code will work on other sites.
A brute force scheme can only give you something that will work as a password for zenphoto. There is no reason to believe that the same generated code will work on other sites.
Junior Member
Member
"that dos not hinder my experience" aye, there's the rub. Extra security comes with extra inconvenience.
I think I do understand security pretty well. For instance, under my direction the Burroughs Operating System was granted a DOD C2 security rating--the first ever commercial OS to get that certification.
Security is invasive. Security good enough to do anyting needs a lot of things.
First, your local site must be physically secure. If you allow access to it, all bets are off. If you let malicious software access your system all bets are off.
Second, the network must be secure end to end. This means you need to run (at least) SSL.
Then you can worry about the software on the other end of the connection.
Are you worried about someone hijacking your admin cookie? Have your browser refuse cookies? The cookie will not be stored, so no one can retrieve them from your (presumably unsecure) system. You will then have to login for each session, but that is the price of security.
You can refuse other zenphoto cookies too, if you wish. You will need to enable gallery sessions on the gallery options tab. I am not sure what value this provides you as these cookies contain things like search parameters. But things will work and you will be inconvienenced only by the session maintenance.
Do all of these things and zenphoto will be quite secure. Don't do them and there are potential attack venues.
Did you know that it is not too hard to pick most door locks? Better locks just take longer. Prudent people with something to lose install alarm systems. But even these are reasonably easy to circumvent. What you are really doing with all this is making it more attractive for the perpetuator to go somewhere else.
Computer software security is similar to this. Why would anyone hijack your zenphoto server for nefarious purposes when it is so much easier to hijack someone's personal computer to for the same purpose. It would be much easier for me to place a keystroke monitor on your system than to brute force crach the zenphoto password encryption.
I think I do understand security pretty well. For instance, under my direction the Burroughs Operating System was granted a DOD C2 security rating--the first ever commercial OS to get that certification.
Security is invasive. Security good enough to do anyting needs a lot of things.
First, your local site must be physically secure. If you allow access to it, all bets are off. If you let malicious software access your system all bets are off.
Second, the network must be secure end to end. This means you need to run (at least) SSL.
Then you can worry about the software on the other end of the connection.
Are you worried about someone hijacking your admin cookie? Have your browser refuse cookies? The cookie will not be stored, so no one can retrieve them from your (presumably unsecure) system. You will then have to login for each session, but that is the price of security.
You can refuse other zenphoto cookies too, if you wish. You will need to enable gallery sessions on the gallery options tab. I am not sure what value this provides you as these cookies contain things like search parameters. But things will work and you will be inconvienenced only by the session maintenance.
Do all of these things and zenphoto will be quite secure. Don't do them and there are potential attack venues.
Did you know that it is not too hard to pick most door locks? Better locks just take longer. Prudent people with something to lose install alarm systems. But even these are reasonably easy to circumvent. What you are really doing with all this is making it more attractive for the perpetuator to go somewhere else.
Computer software security is similar to this. Why would anyone hijack your zenphoto server for nefarious purposes when it is so much easier to hijack someone's personal computer to for the same purpose. It would be much easier for me to place a keystroke monitor on your system than to brute force crach the zenphoto password encryption.
Member
But both the suggestions for salted passwords and encrypted cookies would make ZP more secure, and they'd be transparent to the user. Better security is not always more invasive. Replacing mediocre security with something that does the same job the same way, but better, is transparent and should be done.
If it's easy to to hijack a session cookie because the cookies are unencrypted and some wanna-be hacker discovers that some theme is vulnerable to XSS, then you can bet that a bunch of scripts kiddies are going to do it merely because they can.
If it's easy to to hijack a session cookie because the cookies are unencrypted and some wanna-be hacker discovers that some theme is vulnerable to XSS, then you can bet that a bunch of scripts kiddies are going to do it merely because they can.
Member
Member
Each could probably be made work both ways for backwards compatibility, or it could just part of a more major version change (like 2.0) and include a more explicit migration, like resetting passwords.
The salt is probably the slightly less useful option of the two -- looking at the existing code, the username is concatenated with the password already. While not nearly as random as a salting method, it does add to the length a fair bit.
The salt is probably the slightly less useful option of the two -- looking at the existing code, the username is concatenated with the password already. While not nearly as random as a salting method, it does add to the length a fair bit.
Member
So, I guess, the situation is if you use strong usercodes and strong passwords there in not much of an issue. Seems like that would be the best approach. If you feel strongly about this, submit a feature ticket and we will let the client base voice their opinion as to it this is the place to sepend the scarce zenphoto development resources.
Maybe you should research the amount of computing power / time it would take to brute force crack the user/password encryption. Add that to the ticket so people will have a fair evaluation of the risk.
Maybe you should research the amount of computing power / time it would take to brute force crack the user/password encryption. Add that to the ticket so people will have a fair evaluation of the risk.
Member
I am assuming, by the way, that the cracker has no access to the enctypted value. If you are supposing he does, present the scenerio wherby he got it. My guess is that zenphoto security will be like a fortress compared to the access controls that let someone access the computer. Remember, physical security is key to any security. If you don't have it, you have nothing.
Member
I ran one site where the hosting provider was a little lax in keeping the cPanel updated with fixes. Intruders were able to install arbitrary files -- they used it to install a phishing page to harvest logins and passwords, and sent out emails directing bank customers to that page to log in.
If an attacker can install arbitrary pages on a server -- by any means, not just through ZP -- then they could *easily* grab the contents of the zp-config file, and have access to the ZP database. Then getting a dump of the stored passwords hashes is easy. That said, if they can gain that access, they can do what they want with you website.
But, as I said earlier, the ZP system is pretty good as-is. By combining the user ID with the password, the length means that brute-force and rainbow table attacks are unlikely to succeed. Currently downloadable rainbow tables (which would break passwords *very* quickly on average PCs) are approaching 8 characters for md5 hashes, so the combined length will be beyond that in the vast majority of cases. Salt adds to the length, which would help strengthen short username/password combos. A dictionary attack is still feasible, but certainly only effective against common or weak passwords, or simple derivatives of them.
Do I think ZP really needs salting added? No, not really, but it would help. But I also think you've made some very incorrect assumptions in your reasoning.
Assuming the attacker has no access to the encrypted value is the exact wrong assumption. The point that salting and using stronger encryption methods is based on the assumption that the stored passwords could be compromised. If you want to assume total physical safety of the stored passwords, then you would just store them clear. The reason for salting and hashing is that the actual passwords will remain secure even if the stored values are compromised. An attacker may be able to compromise the security of one site, but they won't gain any additional information.
If an attacker can install arbitrary pages on a server -- by any means, not just through ZP -- then they could *easily* grab the contents of the zp-config file, and have access to the ZP database. Then getting a dump of the stored passwords hashes is easy. That said, if they can gain that access, they can do what they want with you website.
But, as I said earlier, the ZP system is pretty good as-is. By combining the user ID with the password, the length means that brute-force and rainbow table attacks are unlikely to succeed. Currently downloadable rainbow tables (which would break passwords *very* quickly on average PCs) are approaching 8 characters for md5 hashes, so the combined length will be beyond that in the vast majority of cases. Salt adds to the length, which would help strengthen short username/password combos. A dictionary attack is still feasible, but certainly only effective against common or weak passwords, or simple derivatives of them.
Do I think ZP really needs salting added? No, not really, but it would help. But I also think you've made some very incorrect assumptions in your reasoning.
Assuming the attacker has no access to the encrypted value is the exact wrong assumption. The point that salting and using stronger encryption methods is based on the assumption that the stored passwords could be compromised. If you want to assume total physical safety of the stored passwords, then you would just store them clear. The reason for salting and hashing is that the actual passwords will remain secure even if the stored values are compromised. An attacker may be able to compromise the security of one site, but they won't gain any additional information.