Jonathan Vanasco wrote: >> Sounds an awful lot like mod_auth_tkt to me, or am I missing something? > > Its like mod_auth_tkt in design , but not in function > > mod_auth_tkt does apache auth via cookies and apache - i need to support > a non-cookie and non-apache environment > > this is meant to offer a security layer when doing a form style login > via Flash or Javascript over an insecure connection - so that a user > password is never sent in the open > > i'm in the midst of writing the corollary flash and js libraries too > > maybe mod_auth_tkt can support that via specific calls ?
Well, what normally happens is that the username/pw go over the connection and the server side code (Perl) turns it into a mod_auth_tkt formatted ticket via whatever method it wants to. That's then sent back to the client as a cookie. In your case you can skip the server trip and just create the cookie with your Flash/JS libraries. But there is a big security whole there if you skip the trip to the server (whether or not you use mod_auth_tkt). In order for the Flash code or JS code to create a ticket using a shared secret that secret needs to be downloaded to the client. Now you might be relying on Flash's binary format to protect said secret, but I wouldn't. Sending a user/pw combo on an insecure connection is not as bad as sending your shared secret out into the open on the same insecure connection. The first compromises that user's account. The second compromises every users account. -- Michael Peters Developer Plus Three, LP
