Help please!

Anon

Hello everyone!
I need some help convincing the people above me on a certain issue because I'm lead to believe that they are going about it in the wrong manner. Here is the issue, we are using PHP4 session handling for a huge website which has 500,000 customers. We are expecting about 30% of these customers to actually do business through this website and of course have the base customers grow as well.

At any rate, what they are wanting to do is put the primary keys for users accounts encrypted using the Blowfish algorithm with two modifications on it and then putting the encrypted information in the url along with the session id. My big complaint is that you are going to have to encrypt and decrypt the user's information on every page of the application, in turn using a ton of cpu power. The only reason why they are going to be using sessions is to keep each user unique.

We run a huge Oracle database and I have suggested to put all the session information into that database and avoid using the encryption / decryption. However, they do not want to put any more hits on the database than possible because at some points of the day it becomes a little sluggish. Since I'm not a dba is it safe to assume that making the session handling via oracle wouldn't bog it down anymore than it already is?

I'm just trying to avoid having to write this encryption and decryption code that I know is going to slow the site down when we could just put the information into oracle and it would be safe and secure. Am I correct in assuming all of this? From what I have read I feel that this is a safe bet and is used all over the web.

Anyway, any comments/seggestions on this matter is more than welcome!

Thanks,
Jay Paulson

Anon

Ok, I think I am missing something here or you have answered your own question without knowing it.

Isn't the reason for using sessions so you can remember information across pages? Why would you need to pass any information in the URL if it is stored as a session variable? (if cookies are turned off PHP can send a session ID to retain knowledge of registered variables).

So... when a user logs in with username and password and you register those variables as session variables ALL of your pages would know those values if ALL those pages are using sessions without having to pass any extra parameters in the URL. If you want to register them as encrypted, then knock yourself out. Otherwise you would be ok by just setting it to their password value.

PHP 4.x.x has built in session handling, PHP 3.x.x has some add-ons that allow session usage (the name escapes me at the moment).

Sorry if I misunderstood your situation, but like I said, I think you have the solution already without realising it. Here is the manual page for PHP and sessions http://www.php.net/manual/ref.session.php

Tim Frank

Anon

hey Jay,
I may be the right one or may not have the most information to convince you. But at my works that how we do it. We obtain session id's, subnet masked IP's and just for th sake of easiness issue a cookie with the session id, only if the person is doing business directly and needs to hop computers (for the sake of security). And store all of them in the oracle database. We do backup twice everyday and havent had a single issue with the performance or load. We have the oracle running off RH6.2 box having RAID swaps. And also tape backup's. This also helps in the easy stats generation and also stats generation per company. this has been the way we were handling even before we used PHP. So, I dont see there would be an issue, sounds like u have people who are picky on issues.
Good Luck, again i may not the right one for this, but u might want to do more research.

Anon

Exactly my argument! 🙂 I don't remember if I said this or not in my original post but upper management here wants to be able to access the user's session information using other programming languages (why they want want this functionallity is unknown to me but they are upper management right?). Anyway, they thought that we should just pass all the session information in the URL and encrypt it when we pass it that way other programming languages can access the URL and decrypt the user's session information.

This is why I have suggessted putting the user's information in a database and then just passing the session id throughout the site. This way other programming languages can just get the session id and access the db and get the user information if they need too.. anyway i would like to know what you think about this.

Thanks,
Jay Paulson

Anon

Thanks for the feebback! Could you read the post that I just replied to and let me know what you think?

<http://www.phpbuilder.com/forum/read.php3?num=2&id=112205&thread=112144>

Thanks!
Jay Paulson

Anon

Jay,

Access from other programming languages would still be an option depending on how they were used. I mean PHP can execute external programs on the server, and if those programs take command line arguments then that is not really an issue. I'm not sure how else you are interacting with your webpages so other languages would come into the mix on each page?? If you needed to POST information to a C or PERL script, then that script would still get all the information from the POST header.

As you say, the only other solution that I would like is the database option. If you start passing information through URL's you have to be VERY sure that you have some sort of expiry or time stamping feature so somebody else couldn't just pass in the encrypted set of user details and gain access to those pages. (In theory that would be why you would use the session ID's as well of course 🙂

Do you have any idea which "other languages" need access to this "on the fly" data in a browser URL???

Tim Frank

Anon

Hi
Sorry i just stepped into my cube, after my management committe decided to meet me, but sure are they easier than yours. Sure would be a good idea when you try to encrypt into URL's and people not messing with the encryption.
We have data flowing across platforms and different web programming languages handle them differently for us. We have groups that use solely MSAccess and ASP's, and some with beans and JSP's, servlets too, and PHP with JSP and servlets too. My codes need to talk to 2 different programmin languages at least. This DB session pooling was a big help to me. I didnt have to write nasty codes to ensure my data would be hacked or not. I would like to just point our our simple design, so far worked effective for us.

We set the session data on the client side for multi url access, incase he doesnt want to log in and house all his information in a cache database (Oracle).
We have raid mirrors for these informaition depending on the number of access, a DBA would help the effectiveness by performance tuning the setup.
The multi URL, client cookie (restricted to our website only) get the session id and queryies our cache database. If the access is very less probable the wait time is around 7secs, else the wait time is less than a sec.
Once the they are authenticated the respective service is provided.

This is the simplest and so far effective. People cannot ge hold of the session information and access the database as our firewall would stop them. And the they would not have a clue where our cache db is hidden too. And the best of all is no crappy URL construction for the other departments. Which helps in better independance of departments. Some other person needs to interfere inbetween my code, hey read the cookie get the information do what u want and I will read the information from the database if u r passing me anything. Simple isnt it.

Good Luck.