coolsti

To the last poster, I have only developed for our intranet so I am not sure about what you mean regarding the disadvantages of sessions in another environment. I agree that it would be unexpected for co-workers to go around sniffing cookies to get a hold of passwords. But in my opinion it would be a very irresponsible thing to do to allow a password to go around as free text in a cookie anyway. In our case, the reason I am faced with this problem is because I have set things up so that WordPress login occurs with the company user’s main Windows server log in password. This is to ensure that the same password expiration policy is used throughout the company, so that the user needs remember only one password, and so that the authorization is centralized (block the user’s password on the main server, and the user is blocked everywhere). For this reason, it would be extremely dangerous to have this password out in the clear, intranet or not. The way I have it now, stealing a cookie from user “Bill” will allow access to Bill’s session, but at least the password is no longer included.

Hi “Just my $0.02”,
first let me say that my post was not a critic of WordPress. What I have seen so far is a fantastic piece of work, and would be very useful in certainly many areas, and that is exactly why I am interested in using it. It has many features already available that I don’t yet have in my own (in comparison rather simple) application.
It is just that I am 1) curious why things have been done this way, 2) possible implications on security and 3) whether people out there have successfully modified WP in the ways that would address the points I mentioned in my post. For example, a discussion with my company’s IT support concerning “what I need to do to allow my own PHP database applications to be placed on our corporate system” resulted in one very big demand: That basically ALL of the actual php code be placed AWAY from the documentation tree, and only minor stubs with require statements remain in the doc tree. So I really do need to know if and how WP can be modified to accommodate this, or I simply won’t be allowed to use it in our company (making my colleague indeed very sad, and maybe me too).
You say that WP was not created for intranets. What was it created for? Because certainly the level of security needed for an intranet is far less than the level needed for something that is accessible from anywhere on the internet.
Regarding the comment starting with “People are the weakest point…” , I agree with this, but I believe it is necessary to anticipate the irresponsibility or negligence of the common user and try to develop the software to cover as many situations as possible – of course within reason. For example, I know that there is a time out of the session cookie with WP, so this is ok. But I don’t think it is ok that a person can close his browser window without logging out, then have another user open a new browser window and find him/herself logged on as the previous user. This is a minor risk in a small company, more of a risk in a larger company, and even more in another environment where something might be accessed from an internet cafe while travelling. Because a person will forget to punch that logout button once in a while.
Anyway, please don’t take all this for criticism – it is merely professional curiosity: why did they do it that way instead of the other way?
Steve, Denmark