From: Aaron H. <aa...@me...> - 2001-10-11 18:58:07
|
Are any of the timout functions in the UserManager classes (cachedUserTimeout()) implemented? They do not seem to be used anywhere. Also what is External ID used for? For an I was planning to map - User.name = email address User.SerialNum = User.SerialNum (= primary key of DB) User.ExternalID = employeeID (I know its Alpha so thats why I think the functions are not used) Thanks, -Aaron =================================================================== As Isaac Newton would say now: If I see further than others, it is because I stand on the shoulders of giants too dumb to patent their discoveries. (Gregory Palast, http://www.observer.co.uk/ ) |
From: Chuck E. <Chu...@ya...> - 2001-10-11 19:16:50
|
At 02:56 PM 10/11/2001 -0400, Aaron Held wrote: >Are any of the timout functions in the UserManager classes >(cachedUserTimeout()) implemented? >They do not seem to be used anywhere. > >Also what is External ID used for? For an I was planning to map - >User.name = email address >User.SerialNum = User.SerialNum (= primary key of DB) >User.ExternalID = employeeID > >(I know its Alpha so thats why I think the functions are not used) You're correct that the timeouts are not used. They are mostly important for sites that have a huge number of users. More moderate sites could rely on WebKit session timeouts instead (assuming you are using WebKit). So far UserKit users haven't felt the burden of 10,000 simultaneous users so no one has implemented the time outs. The idea behind externalId is that you could safely use it externally to refer to a user. Safely means that 1. it would be hard for someone to guess (and therefore impersonate another user) and 2. would not reveal private information about the user. This basically means an opaque, lengthy randomized id. I believe UserKit already provides that. And here's an example application of it: If the user chooses a "[ ] Remember me" checkbox when signing in, you would store their externalId in an indefinite cookie. Using their employee id for this would be bad for several reasons. 1. If I get access to someone's machine I can discern their employee id by looking at their cookies. 2. If I already know their id, I can impersonate them by editing my cookies file. 3. If ids are easily guessed (perhaps they are consecutive) I can easily impersonate random employees. -Chuck |
From: Chuck E. <Chu...@ya...> - 2001-10-11 20:22:29
|
At 03:29 PM 10/11/2001 -0400, Geoff Talvola wrote: >At 12:14 PM 10/11/01 -0700, Chuck Esterbrook wrote: >>The idea behind externalId is that you could safely use it externally to >>refer to a user. Safely means that 1. it would be hard for someone to >>guess (and therefore impersonate another user) and 2. would not reveal >>private information about the user. This basically means an opaque, >>lengthy randomized id. I believe UserKit already provides that. >> >>And here's an example application of it: If the user chooses a "[ ] >>Remember me" checkbox when signing in, you would store their externalId >>in an indefinite cookie. Using their employee id for this would be bad >>for several reasons. 1. If I get access to someone's machine I can >>discern their employee id by looking at their cookies. 2. If I already >>know their id, I can impersonate them by editing my cookies file. 3. If >>ids are easily guessed (perhaps they are consecutive) I can easily >>impersonate random employees. > >That reminds me of something I meant to bring up a while ago. Session IDs >are currently not very random. Only the last 5 digits are actually random >-- the rest of it is just the current time expressed as a string. > >This could be a security hole in that it makes it not too hard to guess >the session ID and take over a session. > >Any ideas how this could be made more random? One idea is to construct >the session ID by taking the existing session ID, concatenating it with a >big blob of random characters perhaps generated at Webware install time, >and run it through md5 or sha and spit out the hexdigest. This will end >up with a string that should be unguessable unless the guesser has access >to the original blob of random characters. > > >-- > >- Geoff Talvola > gtalvola@NameConnector.com > >_______________________________________________ >Webware-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webware-devel |
From: Aaron H. <aa...@me...> - 2001-10-11 21:39:47
|
Relying on session timeouts seems to be a a problem in using UserKit, at least with the UserManager.activeUsers() method. If a user logs in and thier session invalidates how does the UserManager know that they lost thier session? Technically they are not logged in becuase next time they hit a page they will be asked to login again as a new user. BUT the function active users will report them as an active user? Is there a hook somewhere for my code when a session is destroyed? I see where the task is setup to sweep the session in application, but I don't want to touch that. I usually put the user object in the session store, this way an function like activeUsers could be called against the sessions rather then the userManager. I like the idea of a the User cache in the manager, my app will initially have 1500 users, but I imagine only 50 or so will use it regularly. Thanks for the help, -Aaron ----- Original Message ----- From: "Chuck Esterbrook" <Chu...@ya...> To: "Aaron Held" <aa...@me...>; <Web...@li...> Sent: Thursday, October 11, 2001 3:14 PM Subject: Re: [Webware-devel] UserKit > At 02:56 PM 10/11/2001 -0400, Aaron Held wrote: > >Are any of the timout functions in the UserManager classes > >(cachedUserTimeout()) implemented? > >They do not seem to be used anywhere. > > > >Also what is External ID used for? For an I was planning to map - > >User.name = email address > >User.SerialNum = User.SerialNum (= primary key of DB) > >User.ExternalID = employeeID > > > >(I know its Alpha so thats why I think the functions are not used) > > You're correct that the timeouts are not used. They are mostly important > for sites that have a huge number of users. More moderate sites could rely > on WebKit session timeouts instead (assuming you are using WebKit). So far > UserKit users haven't felt the burden of 10,000 simultaneous users so no > one has implemented the time outs. > > The idea behind externalId is that you could safely use it externally to > refer to a user. Safely means that 1. it would be hard for someone to guess > (and therefore impersonate another user) and 2. would not reveal private > information about the user. This basically means an opaque, lengthy > randomized id. I believe UserKit already provides that. > > And here's an example application of it: If the user chooses a "[ ] > Remember me" checkbox when signing in, you would store their externalId in > an indefinite cookie. Using their employee id for this would be bad for > several reasons. 1. If I get access to someone's machine I can discern > their employee id by looking at their cookies. 2. If I already know their > id, I can impersonate them by editing my cookies file. 3. If ids are easily > guessed (perhaps they are consecutive) I can easily impersonate random > employees. > > -Chuck > > > _______________________________________________ > Webware-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-devel |
From: Geoff T. <gta...@na...> - 2001-10-11 19:30:11
|
At 12:14 PM 10/11/01 -0700, Chuck Esterbrook wrote: >The idea behind externalId is that you could safely use it externally to >refer to a user. Safely means that 1. it would be hard for someone to >guess (and therefore impersonate another user) and 2. would not reveal >private information about the user. This basically means an opaque, >lengthy randomized id. I believe UserKit already provides that. > >And here's an example application of it: If the user chooses a "[ ] >Remember me" checkbox when signing in, you would store their externalId in >an indefinite cookie. Using their employee id for this would be bad for >several reasons. 1. If I get access to someone's machine I can discern >their employee id by looking at their cookies. 2. If I already know their >id, I can impersonate them by editing my cookies file. 3. If ids are >easily guessed (perhaps they are consecutive) I can easily impersonate >random employees. That reminds me of something I meant to bring up a while ago. Session IDs are currently not very random. Only the last 5 digits are actually random -- the rest of it is just the current time expressed as a string. This could be a security hole in that it makes it not too hard to guess the session ID and take over a session. Any ideas how this could be made more random? One idea is to construct the session ID by taking the existing session ID, concatenating it with a big blob of random characters perhaps generated at Webware install time, and run it through md5 or sha and spit out the hexdigest. This will end up with a string that should be unguessable unless the guesser has access to the original blob of random characters. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Ian B. <ia...@co...> - 2001-10-11 19:49:13
|
Geoff Talvola <gta...@na...> wrote: > That reminds me of something I meant to bring up a while ago. Session IDs > are currently not very random. Only the last 5 digits are actually random > -- the rest of it is just the current time expressed as a string. > > This could be a security hole in that it makes it not too hard to guess the > session ID and take over a session. Well, if you also used IP number in the session, you'd make it much more secure. Potentially a malicious snoop could intercept the HTTP requests and get the cookie, no matter how random. But it's considerably more difficult to get the cookie and impersonate or intercept the IP address. Simply guessing the session ID wouldn't provide anything, either, since again it's quite hard to fake an IP address effectively. The only disadvantage is for people on dialup, if they redial they will probably get a new IP address and will have to start a new session, even if they never closed their browser. A more complete solution might be, in secure situations, to have some way of intercepting a good session with a bad IP, and require relogin to restore their old session. Or, right now, you store their IP number in their session, and give a warning if it changes. Then if there's an imposter online at the same time as the real user, the real user will keep getting warning messages and hopefully realize something's wrong. Actually, now that I think of it, all of this is easily doable without changing Session itself, but just how you use it. Ian |
From: Geoff T. <gta...@na...> - 2001-10-11 20:39:53
|
At 01:29 PM 10/11/01 -0700, Chuck Esterbrook wrote: >Okay, so I'm curious how you would actually guess a session on my server? >You need to get a number between 0 and 99999 AND you need to know the >exact date, including second, that the session was created. > >You say that "only the last 5 digits are actually random" but that doesn't >mean the other 14 digits are negligible. They're not. I'll go ahead and >give you the year, month and day, but where are you going to come up with >the correct hour, minute, second AND a 5 digit random number? I could write a program that keeps on trying random session IDs with the date/time part of the session ID set to a couple of minutes ago, so the session is likely to still be around. It might take hundreds of thousands of tries but it would eventually find a valid session ID, especially on a site that gets a lot of traffic and therefore has a lot of new sessions getting created all the time. I'll admit that this is near the bottom on the list of things to worry about. But if your site contains sensitive information that someone might go to the effort of breaking into, it would make sense to think about it. Especially if you're already securing the site with SSL, then the session ID would become the weak link in your security. A much more likely annoyance is that someone could just flood the server with requests, making the site grind to a halt. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Ian B. <ia...@co...> - 2001-10-11 21:05:52
|
Geoff Talvola <gta...@na...> wrote: > I could write a program that keeps on trying random session IDs with the > date/time part of the session ID set to a couple of minutes ago, so the > session is likely to still be around. It might take hundreds of thousands > of tries but it would eventually find a valid session ID, especially on a > site that gets a lot of traffic and therefore has a lot of new sessions > getting created all the time. OTOH, if you have a lot of traffic, the security for the bulk of those users probably isn't a big deal. Maybe Hotmail has to worry about this (a bit), but few other sites. Usually there's only a relatively small number of people who have enough privileges to matter much. Simply distributing the passwords to large numbers of users is very insecure anyway. Self-registration implies that the user has built their privilege up after registration -- usually by creating some sort of content afterwords. This is how I'd classify Hotmail. Things like credit card numbers -- easy to put on the site, highly privileged -- should really be deleted anyway. I still can't believe my fucking bank thinks my social security number is a good enough form of authentication. Or worse, just the last four digits. It's a goddamned disgrace. So while we might think "except for banks, this should be good enough" banks think even less security is good enough. Ian |