Menu
▾
▴
slashcode-development
|
From: Brian A. <br...@ta...> - 2001-01-25 08:00:40
|
Is there any reason why we are randomly generating a number still in sessions to use it as the session ID? It could easily be an autoincrement. For that matter the cookie basically isn't really needed any longer for sessions. It could all be done in the database now that we don't use that cookie for any sort of authenication. This isn't a priority but it is a waste of code at the moment. -Brian |
|
From: Chris N. <pu...@po...> - 2001-01-25 15:03:48
|
At 13:39 -0800 01.24.2001, Brian Aker wrote: >Is there any reason why we are randomly generating a number >still in sessions to use it as the session ID? It could >easily be an autoincrement. Since the session was being put into the cookie, and that was what authenticated you, a sequence of any kind would be dangerous. Guess the right number and be authenticated as that admin. >For that matter the cookie basically isn't really needed >any longer for sessions. It could all be done in the >database now that we don't use that cookie for any >sort of authenication. This isn't a priority but >it is a waste of code at the moment. Yes, since we no longer put it in the cookie, there is no longer a need to make it random, I believe. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
|
From: Nathan V. <na...@th...> - 2001-01-25 18:18:11
|
On Thu, 25 Jan 2001, Chris Nandor wrote: > At 13:39 -0800 01.24.2001, Brian Aker wrote: > >Is there any reason why we are randomly generating a number > >still in sessions to use it as the session ID? It could > >easily be an autoincrement. > > Since the session was being put into the cookie, and that was what > authenticated you, a sequence of any kind would be dangerous. Guess the > right number and be authenticated as that admin. Even a random number could be guessed by brute force, which is why most session management includes a checksum including the client ip and a secret value known only to the server. Chapter 5 in the O'Reilly mod_perl book (Stein and MacEachern) covers this in detail, especially p 213 and following. Have you considered using the Apache::Session module? It seems to be a good interface for generating unique session ids that are hard to spoof, though I haven't used it yet (I rolled my own on the one project I've used them for so far). -n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathan Vonnahme na...@th... senior web developer third sector technologies http://enteuxis.org/nathan http://thethirdsector.com ~~~~~~~~~~~~~~~~ global = useless ~~~~~~~~~~~~~~~~~ |
|
From: Chris N. <pu...@po...> - 2001-01-25 18:33:15
|
At 09:12 -0900 01.25.2001, Nathan Vonnahme wrote: >On Thu, 25 Jan 2001, Chris Nandor wrote: > >> At 13:39 -0800 01.24.2001, Brian Aker wrote: >> >Is there any reason why we are randomly generating a number >> >still in sessions to use it as the session ID? It could >> >easily be an autoincrement. >> >> Since the session was being put into the cookie, and that was what >> authenticated you, a sequence of any kind would be dangerous. Guess the >> right number and be authenticated as that admin. > >Even a random number could be guessed by brute force, which is why most >session management includes a checksum including the client ip and a >secret value known only to the server. Chapter 5 in the O'Reilly mod_perl >book (Stein and MacEachern) covers this in detail, especially p 213 and >following. Yes, it could be guessed, but that is almost impossible. You'd have better luck actually guessing the admin's password, because the password doesn't change periodically, and the session cookie does. >Have you considered using the Apache::Session module? It seems to be a >good interface for generating unique session ids that are hard to spoof, >though I haven't used it yet (I rolled my own on the one project I've used >them for so far). Well, in our new system, session IDs are not used for security anymore, they are only used for tracking the acivity of an author (how long they have been logged on and what story they are working on and such), so I don't think that's necessary. The only way an author/admin is logged in, anymore, is by his regular username and password, and the user cookie that goes with it. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
|
From: Nathan V. <na...@th...> - 2001-01-25 19:07:12
|
On Thu, 25 Jan 2001, Chris Nandor wrote: > Well, in our new system, session IDs are not used for security anymore, > they are only used for tracking the acivity of an author (how long they > have been logged on and what story they are working on and such), so I > don't think that's necessary. The only way an author/admin is logged in, > anymore, is by his regular username and password, and the user cookie that > goes with it. Whoah, I didn't realize usernames/passwords were stored in the cookies. Cookies are (in theory) interceptable since they're sent over the net in clear text (unless you're using ssl), so Bad Guys could steal your cookie and learn your password and log in as you and do Bad Things. The method outlined in the eagle book and implemented in Apache::Session doesn't have this problem, and is suitable, e.g., for ecommerce or other privacy-sensitive session tracking. Now, maybe it's not essential for slash to have this level of security/privacy, especially in the interests of speed, but there are more secure ways of doing it. Also, it would actually save the authentication database lookup, I think...but would require an MD5 computation. -n |
|
From: Chris N. <pu...@po...> - 2001-01-25 19:20:05
|
At 10:01 -0900 01.25.2001, Nathan Vonnahme wrote: >Whoah, I didn't realize usernames/passwords were stored in the cookies. >Cookies are (in theory) interceptable since they're sent over the net in >clear text (unless you're using ssl), so Bad Guys could steal your cookie >and learn your password and log in as you and do Bad Things. This is the case now, in Slash. In bender, we use md5 hashing to store the password in the cookie. So the password itself is not there. Yes, the md5 hash could be stolen, so someone could copy your cookie and log in as you. And yes, this can all be worked around with SSL, which is why bender has SSL support, so admins can choose to use https. I am not opposed to other methods; the cool thing is that all of this is done in Slash::Apache::User, and is invoked in your Apache config. You can write a separate authentication module and plug that in to your Apache config instead. I imagine we will work toward having several different authentication modules. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
|
From: Nathan V. <na...@th...> - 2001-01-25 19:32:16
|
On Thu, 25 Jan 2001, Chris Nandor wrote: > This is the case now, in Slash. In bender, we use md5 hashing to store the > password in the cookie. So the password itself is not there. Yes, the md5 Oh. I was thrown off by my $cookie = $uid . '::' . $passwd; (Utility:pm line 1129) because I didn't know that $passwd was already hashed. > hash could be stolen, so someone could copy your cookie and log in as you. > And yes, this can all be worked around with SSL, which is why bender has > SSL support, so admins can choose to use https. A good solution. > I am not opposed to other methods; the cool thing is that all of this is > done in Slash::Apache::User, and is invoked in your Apache config. You can > write a separate authentication module and plug that in to your Apache > config instead. I imagine we will work toward having several different > authentication modules. Nifty! Maybe we'll write one using Apache::Session, it'd actually be good for one site we're working on, and especially for any site combining slash with commerce (in an amazon-esque way?), where privacy of regular users is important and they don't need to use https for everything. -n |
|
From: Chris N. <pu...@po...> - 2001-01-25 19:44:42
|
At 10:26 -0900 01.25.2001, Nathan Vonnahme wrote: >Nifty! Maybe we'll write one using Apache::Session, it'd actually be good >for one site we're working on, and especially for any site combining slash >with commerce (in an amazon-esque way?), where privacy of regular users is >important and they don't need to use https for everything. Very cool. Keep us informed, if you can; we have not tried to plug in other authentication modules yet, and I imagine it might not be seamless, but we want it to be. We took a big step toward making it seamless by moving the getUser code to Slash::Utility, though (we renamed it, too, and I forget the new name right now, but it is the code to basically set a user up before saving it to the object you get when you call getCurrentUser()). -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
|
From: Brian A. <br...@ta...> - 2001-01-25 20:06:28
|
Chris Nandor wrote: > Very cool. Keep us informed, if you can; we have not tried to plug in > other authentication modules yet, and I imagine it might not be seamless, > but we want it to be. We took a big step toward making it seamless by > moving the getUser code to Slash::Utility, though (we renamed it, too, and > I forget the new name right now, but it is the code to basically set a user > up before saving it to the object you get when you call getCurrentUser()). I have the authentication code somewhat working as a C module for Apache right now. It doesn't generate the data needed for getCurrentUser() but does do the actual authentication and sets SLASH_USER (and REMOTE_USER for that matter). I have some sites that are halfway between running bender and homegrown code at the moment, and this made my transition a bit easier. -Brian |
|
From: Brian A. <br...@ta...> - 2001-01-25 20:00:32
|
Chris Nandor wrote: > Well, in our new system, session IDs are not used for security anymore, > they are only used for tracking the acivity of an author (how long they > have been logged on and what story they are working on and such), so I Basically how long they have been looking at a story (which eventually times out). Basically, know the bar on the bottom of the admin.pl page that states what people are looking at? Well, that is what it does. > don't think that's necessary. The only way an author/admin is logged in, > anymore, is by his regular username and password, and the user cookie that > goes with it. Right. The session table is updated whenever an admin hits a page on the server. So it does get updates fairly frequently. The cookie right now is pretty much worthless. Session is just basically a way to keep the table nice and normalized at this point. -Brian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X