Thread: Re: [Phplib-users] Basic authentication
Brought to you by:
nhruby,
richardarcher
From: Peter K. <su...@si...> - 2002-02-01 06:00:50
|
Hello Chris, here some ideas on your problems: > 1) Get the user name in the combined web server log. (I use apache, and > have not had any luck with other methods.) This is lower priority. I do not understand the phrase "... in the combined server log" ? > "single signon" capability -- that is, they logged in at the other site, and > the URL needs to contain the information that they logged in with. As you > know, the standard URL form is something like: > > [protocol]://[username]:[password]@host.domain.name:[port]/document_path I never ever would send passwords in an URL - very good opportunity for hackers! My plan (not realized yet!) to provide a single-sign-on: On server A there is a user database. On another server B the user U calls a page first time. B recognizes, that U isn't logged in and redirects the URL to a log on page at A. The URL must contain information that this request comes from B. U logs on. A opens a session with phplib and redirects the URL back to B including the session-id. B uses a tool like XML/RPC to establish a connection to A and reading the user information required. Instead of XML/RPC you may force A to write a file with the necessary user information and B can do a simple fopen. Further actions depend on your demands: If you do not use session variables, all is perfect. Every page on B can check if the user is still logged in at A. Or you have a phplib at B also to check that. This is a raw outline. In fact you have to do some more customizing. E.g. the server A must not give access to the user-files mentioned from other servers than B ... Sounds complicated, I know. But its very secure (I hope so at least ;-)) Peter Kursawe www.learn4use.com |
From: Brian P. <bp...@ct...> - 2002-02-01 17:37:12
|
Yeah it's really easy. You just stuff their user_id into a cookie after verifying their username & password. I can send code samples if anyone needs a little help. BPopp -----Original Message----- From: Tarique Sani <ta...@sa...> [mailto:ro...@sa...] Sent: Friday, February 01, 2002 11:17 AM To: Carl Youngblood Cc: 'phplib-users' Subject: Re: [Phplib-users] Basic authentication On Fri, 1 Feb 2002, Carl Youngblood wrote: > What I would really like to see is the added feature of a "remember me" > checkbox on the PHPLIB logon page so that users could have the option of not > continually typing in their password everytime they visit my site. I'm sure There already is a way :-) Checkout pre_auth() in the auth class You just have to implement (read override) it whatever way you please Cheers Tarique -- ========================================================== PHP Applications for E-Biz : http://www.sanisoft.com The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com ========================================================== _______________________________________________ Phplib-users mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phplib-users |
From: Carl Y. <ca...@yo...> - 2002-02-02 19:21:50
|
Yeah, I would like some code samples if you don't mind. I added code to my auth_validatelogin() function to set the cookie with the userid in it, but that didn't seem to be enough. Does this not work when you are using the GET method of session ID propagation? I would assume that, as long as the userid cookie gets set, even if the session IDs are being propagated with cookies, it should work. THanks, Carl ----- Original Message ----- From: "Brian Popp" <bp...@ct...> To: "Phplib (E-mail)" <Php...@li...> Sent: Friday, February 01, 2002 10:42 AM Subject: RE: [Phplib-users] Basic authentication > Yeah it's really easy. You just stuff their user_id into a cookie after > verifying their username & password. I can send code samples if anyone needs > a little help. > > BPopp > > -----Original Message----- > From: Tarique Sani <ta...@sa...> [mailto:ro...@sa...] > Sent: Friday, February 01, 2002 11:17 AM > To: Carl Youngblood > Cc: 'phplib-users' > Subject: Re: [Phplib-users] Basic authentication > > > On Fri, 1 Feb 2002, Carl Youngblood wrote: > > > What I would really like to see is the added feature of a "remember me" > > checkbox on the PHPLIB logon page so that users could have the option of > not > > continually typing in their password everytime they visit my site. I'm > sure > > There already is a way :-) > > Checkout pre_auth() in the auth class > > You just have to implement (read override) it whatever way you please > > Cheers > > Tarique > > -- > ========================================================== > PHP Applications for E-Biz : http://www.sanisoft.com > > The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com > ========================================================== > > > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users |
From: Chris J. <ch...@ch...> - 2002-02-03 03:44:17
|
I'd be interested in seeing your code, also, Brian. Why not post it to this list, if it's not too lengthy? ..chris ----- Original Message ----- From: "Carl Youngblood" <ca...@yo...> Yeah, I would like some code samples if you don't mind. I added code to my auth_validatelogin() function to set the cookie with the userid in it, but that didn't seem to be enough. Does this not work when you are using the GET method of session ID propagation? I would assume that, as long as the userid cookie gets set, even if the session IDs are being propagated with cookies, it should work. THanks, Carl ----- Original Message ----- From: "Brian Popp" <bp...@ct...> > Yeah it's really easy. You just stuff their user_id into a cookie after > verifying their username & password. I can send code samples if anyone needs > a little help. > > BPopp |
From: Kevin F. <fre...@ip...> - 2002-02-01 19:02:45
|
I would say that you use the IP address of the user coming from A to B and some secret known only to A and B to encrypt the data and append it to the URL. When you get the forwarded link from A the users "should" still be using the same IP address. You can then decode the user account info and added it if needed to B. Then proceeded with logging the users in with the passed information. The Idea could also be expanded to include a dynamic piece of information that is also used in the key and sent in plain text to detect any URL hacking. Kevin Fredrick Software Technician Walter E. Helmke Library Indiana University - Purdue University Fort Wayne 260-481-5445 http://www.lib.ipfw.edu/ >>> "Chris Johnson" <ch...@ch...> 02/01/02 01:48PM >>> 1) "combined server log" is just the style of server log being used on my Apache webserver. 2) My problem with the authetication is that I do not control the source server in any fashion. In other words, users will signon to server A owned and operated by another company with which my company has an agreement to provide services. They will click on a link to go to my server B. We want them to be able to do that without signing on again. We will register users coming from A to B in our user database on B, so we know who all valid users are. I just need a way to know it IS a valid user coming from A. Thus, I need to tell the programmer at company A how to specify the user to my server at B via the URL in such a fashion that it is secure and I can reliably know they are authenticated at A and who they are. I'm using HTTPS for all connections, so it's only the URL I'd really have to worry about being hacked. All other data should be encrypted, should it not? ..chris ----- Original Message ----- From: "Peter Kursawe" <su...@si...> To: <php...@li...> Sent: Friday, February 01, 2002 12:01 AM Subject: Re: [Phplib-users] Basic authentication Hello Chris, here some ideas on your problems: > 1) Get the user name in the combined web server log. (I use apache, and > have not had any luck with other methods.) This is lower priority. I do not understand the phrase "... in the combined server log" ? > "single signon" capability -- that is, they logged in at the other site, and > the URL needs to contain the information that they logged in with. As you > know, the standard URL form is something like: > > [protocol]://[username]:[password]@host.domain.name:[port]/document_path I never ever would send passwords in an URL - very good opportunity for hackers! My plan (not realized yet!) to provide a single-sign-on: On server A there is a user database. On another server B the user U calls a page first time. B recognizes, that U isn't logged in and redirects the URL to a log on page at A. The URL must contain information that this request comes from B. U logs on. A opens a session with phplib and redirects the URL back to B including the session-id. B uses a tool like XML/RPC to establish a connection to A and reading the user information required. Instead of XML/RPC you may force A to write a file with the necessary user information and B can do a simple fopen. Further actions depend on your demands: If you do not use session variables, all is perfect. Every page on B can check if the user is still logged in at A. Or you have a phplib at B also to check that. This is a raw outline. In fact you have to do some more customizing. E.g. the server A must not give access to the user-files mentioned from other servers than B ... Sounds complicated, I know. But its very secure (I hope so at least ;-)) Peter Kursawe www.learn4use.com _______________________________________________ Phplib-users mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phplib-users _______________________________________________ Phplib-users mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phplib-users |
From: Michael C. <mdc...@mi...> - 2002-02-02 19:07:46
|
On Fri, Feb 01, 2002 at 02:02:30PM -0500, Kevin Fredrick wrote: > I would say that you use the IP address of the user coming from A to B > and some secret known only to A and B to encrypt the data and append > it > to the URL. Forget the IP address, a shared secret is fine if the encryption is good. > When you get the forwarded link from A the users "should" > still be using the same IP address. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sorry to be so blunt, but this is absolutely wrong, and I want to save someone the time of going down this road only to have to redo their code when the find it doesn't work. Many large ISP's, AOL among them, run all port 80 traffic through a proxy farm. The IP address of the request rarely remains consistent across page views. Here's an example of me surfing my site through AOL: 64.12.96.166 - - [02/Feb/2002:12:58:45 -0600] "GET /services.php3 HTTP/1.0" 200 5479 64.12.96.78 - - [02/Feb/2002:12:58:49 -0600] "GET /contact.php3 HTTP/1.0" 200 5822 64.12.96.103 - - [02/Feb/2002:13:01:12 -0600] "GET /aboutus.php3 HTTP/1.0" 200 6511 Name: cache-mtc-ah01.proxy.aol.com Address: 64.12.96.166 Name: cache-mtc-ac09.proxy.aol.com Address: 64.12.96.78 Name: cache-mtc-af02.proxy.aol.com Address: 64.12.96.103 Michael -- Michael Darrin Chaney mdc...@mi... http://www.michaelchaney.com/ |
From: Kevin F. <fre...@ip...> - 2002-02-04 15:29:08
|
We actually ran into this problem. If the page content is dynamic or new content AOL users will request the page one or more times. Once for the browser, second time for the proxy system, and a third for the AOL spider. To overcome this problem we added a trust value to our authentication system. If the request for a restricted page or application comes in, the IP address is checked against the current session data. If there is a mismatch the current request is treated as not trusted. No password changes, no submitting of forms, etc. If they do match then the session is treated as trusted and the user can access the Web site functions. This same method could be used to detect more then one login from one or more computers to the same account. We have been using a version of this type of authentication system for about 4-5 years. We currently support about 15,000 users on-campus and off-campus via AOL, @Home, UUNET, AT&T Worldnet, and a number of other local and national ISPs BTW: This also gets you out of having to ask the user to closes AOL or another ISPs custom browser and used the installed IE or Netscape to access your site. On HTTP connections AOL users are: AOL Spider: spider-*.proxy.aol.com 152.163.195.208 AOL Cache: cache-*.proxy.aol.com 64.12.96.166 AOL User: *.ipt.aol.com 172.131.132.99 On HTTPS connections AOL users area: AOL Spider: spider-*.proxy.aol.com 152.163.195.208 AOL User: *.ipt.aol.com 172.131.132.99 Kevin Fredrick Software Technician Walter E. Helmke Library Indiana University - Purdue University Fort Wayne 260-481-5445 http://www.lib.ipfw.edu/ >>> Michael Chaney <mdc...@mi...> 02/02/02 02:11PM >>> On Fri, Feb 01, 2002 at 02:02:30PM -0500, Kevin Fredrick wrote: > I would say that you use the IP address of the user coming from A to B > and some secret known only to A and B to encrypt the data and append > it > to the URL. Forget the IP address, a shared secret is fine if the encryption is good. > When you get the forwarded link from A the users "should" > still be using the same IP address. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sorry to be so blunt, but this is absolutely wrong, and I want to save someone the time of going down this road only to have to redo their code when the find it doesn't work. Many large ISP's, AOL among them, run all port 80 traffic through a proxy farm. The IP address of the request rarely remains consistent across page views. Here's an example of me surfing my site through AOL: 64.12.96.166 - - [02/Feb/2002:12:58:45 -0600] "GET /services.php3 HTTP/1.0" 200 5479 64.12.96.78 - - [02/Feb/2002:12:58:49 -0600] "GET /contact.php3 HTTP/1.0" 200 5822 64.12.96.103 - - [02/Feb/2002:13:01:12 -0600] "GET /aboutus.php3 HTTP/1.0" 200 6511 Name: cache-mtc-ah01.proxy.aol.com Address: 64.12.96.166 Name: cache-mtc-ac09.proxy.aol.com Address: 64.12.96.78 Name: cache-mtc-af02.proxy.aol.com Address: 64.12.96.103 Michael -- Michael Darrin Chaney mdc...@mi... http://www.michaelchaney.com/ _______________________________________________ Phplib-users mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phplib-users |
From: Chris J. <ch...@ch...> - 2002-02-13 02:44:12
|
So, revisiting this issue a bit further: If my "single signon" business partner who wants to send their users to my secure site running PHPLIB without forcing their users to log in again did the following, would that be sufficient? They have proposed that they create a form on their page such that when the submit button is clicked, they will POST the data to me and pass the username and password. Since both sites are SSL (HTTPS) encrypted, the POST'ed data should be secure. I should then just be able to do an automated, behind the scenes login using their name and password, right? It seems too simple! I'm always sceptical when it seems that easy. Anyone see any flaws in this? Thanks, ..chris |
From: Tarique S. <ta...@sa...> - 2002-02-13 03:20:38
|
On Tue, 12 Feb 2002, Chris Johnson wrote: > secure. I should then just be able to do an automated, behind the scenes > login using their name and password, right? Yes - you can use preauth() for this > It seems too simple! I'm always sceptical when it seems that easy. Yes I guess so BUT I would like to hear from more people Cause I am also going to do something similar soon (as in 'today' ;-) Tarique -- ========================================================== PHP Applications for E-Biz : http://www.sanisoft.com The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com ========================================================== |
From: Justin W. <jw...@sa...> - 2002-02-13 05:43:33
|
Today @ 8:44pm, Chris Johnson typed.. > So, revisiting this issue a bit further: > > If my "single signon" business partner who wants to send their users to my > secure site running PHPLIB without forcing their users to log in again did > the following, would that be sufficient? > > They have proposed that they create a form on their page such that when the > submit button is clicked, they will POST the data to me and pass the > username and password. > > Since both sites are SSL (HTTPS) encrypted, the POST'ed data should be > secure. I should then just be able to do an automated, behind the scenes > login using their name and password, right? > > It seems too simple! I'm always sceptical when it seems that easy. One somewhat undesirable practice is to put the password plaintext in the webpage. Granted, it's SSL so only that person should see it, but even so, most web services never ever let the user see their own password. You never know what could happen to your cached pages, or who may have temporary access to your browser. Isn't there an MD5 alternative? or maybe you're already doing that and that's what you're talking about. Justin > > Anyone see any flaws in this? > > Thanks, > ..chris > > > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > _______________________________________________________ 2 common misconceptions 0) Pain is bad. 1) Omniscience necessitates predestination. |
From: Peter K. <su...@si...> - 2002-02-13 08:38:40
|
Hello Chris, > They have proposed that they create a form on their page such that when the > submit button is clicked, they will POST the data to me and pass the > username and password. I don't understand how they will do that. Do you/they mean it like that: 1. user gets a loginform and enters username and password, press submit ("validate me!"). 2. the login server must process the login 3. the login server validates login and shows a new form to the user with his/her username and password in hidden fields and a new submit button ("go to the application!") 4. user presses the submit button and comes to your server This is possible to implement. And it is secure as long as you trust in the users. Because in this setting the user can fake the login server in building a form like that in 3. without having logged in really. Or --- do you/they mean like that: 1. and 2. (as above) 3. login server validates login and sends username and password directly to your server via POST???? I don't know how to perform that. It may be possible, but I don't know how. Peter Kursawe |
From: Chris J. <ch...@ch...> - 2002-02-13 22:04:07
|
Maybe what I'm doing is not clear enough. I work for the Acme Company. We have an SSL-encrypted website that uses PHPLIB Auth authentication to provide some services to our clients. The Bravo Company also has an SSL-encrypted website for their customers. Many of the Bravo customers might want to use the Acme services. So my company, Acme, has struck a business deal with Bravo, to provide access to our services. However, Bravo wants their users to only have to login once -- that is log into the Bravo website. Somewhere inside the Bravo website, they want to put a link to our (Acme) website. They want their users to be able to click on that link and end up in our website, without first having to type a username and password as our current customers do. That is, Bravo customers are "pre-authorized" by virtue of coming from Bravo and having signed in there first. We, at Acme, will of course have a list of those usernames and passwords from Bravo for the Bravo customers who want to access Acme. I'm looking for a way to securely identify them. I can think of all kinds of complicated ways to do it. But it seems like a simple SSL form might be all that's needed. That is to say, on the Bravo web page, Bravo simply adds a link like this: <FORM METHOD=post ACTION="https://securesite.acme.com/bravopreauth.php" > <INPUT TYPE="hidden" NAME="username" value="BRAVO-USERNAME"> <INPUT TYPE="hidden" NAME="password" value="BRAVO-PASSWORD"> <INPUT TYPE=submit VALUE="Enter Acme"> </FORM> This has many advantages, _IF_ it is secure enough. 1) Minimal programming on my part for the Acme Pre-Auth. 2) VERY minimal HTML changes on the part of Bravo for the Post FORM. 3) Bravo does not use PHP. Bravo may, in fact, have next to no technical resources to do this work, thus the easier for them, the better. One-time tokens for encryption, as suggested later by Layne Weathers might just break the "tech effort" bank. I'm not worried about future applications NOT using SSL. Everything we do is encrypted (it's health care data). I can ASSUME that if I get a value username and password, I can give them access, IF this scheme prevents anyone from eavesdropping and gathering username/password pairs. If Bravo or a Bravo customer screws up and lets an unauthorized person have access to a username/password (e.g. by leaving themselves logged in, or other means), then it's not my or Acme's problem. As far as we know, the user is authorized. I'm still trying to poke holes in this because it seems too simple. But on the other hand, it appears all data is being sent SSL-encrypted, so it is as safe as SSL, which should be good enough for this application. (we don't make nuclear bombs :-) Make sense? ..chris ----- Original Message ----- From: "Peter Kursawe" <su...@si...> To: <php...@li...> Sent: Wednesday, February 13, 2002 2:38 AM Subject: Re: [Phplib-users] Basic authentication Hello Chris, > They have proposed that they create a form on their page such that when the > submit button is clicked, they will POST the data to me and pass the > username and password. I don't understand how they will do that. Do you/they mean it like that: 1. user gets a loginform and enters username and password, press submit ("validate me!"). 2. the login server must process the login 3. the login server validates login and shows a new form to the user with his/her username and password in hidden fields and a new submit button ("go to the application!") 4. user presses the submit button and comes to your server This is possible to implement. And it is secure as long as you trust in the users. Because in this setting the user can fake the login server in building a form like that in 3. without having logged in really. Or --- do you/they mean like that: 1. and 2. (as above) 3. login server validates login and sends username and password directly to your server via POST???? I don't know how to perform that. It may be possible, but I don't know how. Peter Kursawe _______________________________________________ Phplib-users mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phplib-users |
From: Brian P. <bp...@ct...> - 2002-02-13 17:00:42
|
I would go ahead and have them encrypt the username and password somehow before posting it. SSL should protect it from being intercepted, but you never know when you might want to use this same signon process somewhere else, in a non SSL environment. If you go ahead and expect encrypted data, you won't have to have two separate check's in your preauth, one for encrypted, one for not. An MD5 of the password and an agreed upon token would probably be adequate. This is purely hypothetical, but something similar should work I think (?) : Remote partner generates: $password = url_encode ( md5 ( $password . "magicword" ) ); and then links to: "http://www.yourphplibsite.com?username=$username&pw=$password" Then in YOUR auth_preauth() you'd have something like: global $username, $pw; $sql = "SELECT * FROM auth_user WHERE username='$username'"; $db->query ( $sql ); if ( $db->next_record() ) { $dbuid = $db->f ( "user_id" ); $dbpassword = $db->f ( "password" ); $pw = url_decode ( $pw ); if ( $pw == md5 ( $dbpassword . "magicword" ) ) { return $dbuid; } } return 0; -----Original Message----- From: Chris Johnson [mailto:ch...@ch...] Sent: Tuesday, February 12, 2002 8:44 PM To: php...@li... Subject: Re: [Phplib-users] Basic authentication So, revisiting this issue a bit further: If my "single signon" business partner who wants to send their users to my secure site running PHPLIB without forcing their users to log in again did the following, would that be sufficient? They have proposed that they create a form on their page such that when the submit button is clicked, they will POST the data to me and pass the username and password. Since both sites are SSL (HTTPS) encrypted, the POST'ed data should be secure. I should then just be able to do an automated, behind the scenes login using their name and password, right? It seems too simple! I'm always sceptical when it seems that easy. Anyone see any flaws in this? Thanks, ..chris _______________________________________________ Phplib-users mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phplib-users |
From: Layne W. <la...@if...> - 2002-02-13 17:43:06
|
> I would go ahead and have them encrypt the username and > password somehow before posting it. SSL should protect > it from being intercepted, but you never know when you > might want to use this same signon process somewhere > else, in a non SSL environment. If you go ahead and expect > encrypted data, you won't have to have two separate check's > in your preauth, one for encrypted, one for not. An MD5 of > the password and an agreed upon token would probably be > adequate. This is purely hypothetical, but something > similar should work I think (?) : > > Remote partner generates: > > $password = url_encode ( md5 ( $password . "magicword" ) ); This would not be secure at all for a non-SSL environment and I would prefer a better method even for an SSL environment (cacheing, etc). If I can see the md5 of the password and token, I don't need to see any more. This is the problem that the Challenge Response Crypt extension of Auth was designed to solve by ensuring a unique token with each login attempt. With a two-server system, I would want to set up a library of tokens that both servers know about, sort of like a spy's code book. I would probably start with a list of at least a few million unique random tokens. Each user should only be allowed to use each token once, otherwise we're back to the problem above. The remote server would pull a token from the list and send the offset to that token along with the encrypted password. Your server would double check the offset against the user to ensure that this attempt was unique and then check the login for validity. However, we also need to prevent the remote server from using up tokens that are never used - I'm sure that the users will not click to your site every time they see a link on the remote site. To solve this, the remote server links to a local (on the remote server) script. This script (acting much like a click-through counter), finds a token, records it, encrypts the password and redirects to your site. E.g.: $offset = get_unique_offset( $user_id ); $password = tokenize_user_password( $user_id, get_token( $offset ) ); header("Location: http://your_server/?username=$username&password=$password&offset=$offset"); exit; Layne Weathers Ifworld Inc. |
From: Brian P. <bp...@ct...> - 2002-02-13 18:15:28
|
>>This would not be secure at all for a non-SSL environment >>and I would prefer a better method even for an SSL environment >>(cacheing, etc). If I can see the md5 of the password and token, >>I don't need to see any more. That's very true.. very true indeed. Although, keeping x tables of tokens populated on two or more servers seems like a pretty daunting task. I supposed you could have the tables on both sides automatically regenerate as they are exhausted using some predetermined algorithm. I guess this is a much more complicated problem than I originally surmised. Anyone else have any ideas? -BPopp -----Original Message----- From: Layne Weathers [mailto:la...@if...] Sent: Wednesday, February 13, 2002 11:43 AM To: 'Phplib (E-mail)' Subject: Re: [Phplib-users] Basic authentication > I would go ahead and have them encrypt the username and > password somehow before posting it. SSL should protect > it from being intercepted, but you never know when you > might want to use this same signon process somewhere > else, in a non SSL environment. If you go ahead and expect > encrypted data, you won't have to have two separate check's > in your preauth, one for encrypted, one for not. An MD5 of > the password and an agreed upon token would probably be > adequate. This is purely hypothetical, but something > similar should work I think (?) : > > Remote partner generates: > > $password = url_encode ( md5 ( $password . "magicword" ) ); This would not be secure at all for a non-SSL environment and I would prefer a better method even for an SSL environment (cacheing, etc). If I can see the md5 of the password and token, I don't need to see any more. This is the problem that the Challenge Response Crypt extension of Auth was designed to solve by ensuring a unique token with each login attempt. With a two-server system, I would want to set up a library of tokens that both servers know about, sort of like a spy's code book. I would probably start with a list of at least a few million unique random tokens. Each user should only be allowed to use each token once, otherwise we're back to the problem above. The remote server would pull a token from the list and send the offset to that token along with the encrypted password. Your server would double check the offset against the user to ensure that this attempt was unique and then check the login for validity. However, we also need to prevent the remote server from using up tokens that are never used - I'm sure that the users will not click to your site every time they see a link on the remote site. To solve this, the remote server links to a local (on the remote server) script. This script (acting much like a click-through counter), finds a token, records it, encrypts the password and redirects to your site. E.g.: $offset = get_unique_offset( $user_id ); $password = tokenize_user_password( $user_id, get_token( $offset ) ); header("Location: http://your_server/?username=$username&password=$password&offset=$offset"); exit; Layne Weathers Ifworld Inc. _______________________________________________ Phplib-users mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phplib-users |
From: Layne W. <la...@if...> - 2002-02-13 22:41:24
|
> I can ASSUME that if I get a value username and password, I > can give them access, IF this scheme prevents anyone from > eavesdropping and gathering username/password pairs. If Bravo > or a Bravo customer screws up and lets an unauthorized person > have access to a username/password (e.g. by leaving themselves > logged in, or other means), then it's not my or Acme's > problem. As far as we know, the user is authorized. The SSL encryption is, IIRC, setup before the actual request headers are sent so your login info, whether in a posted form or in get vars as was also suggested, will be sent securely. Just as the earlier posts activated my paranoia mode (most things do these days), I would distrust my recollection and test with a packet sniffer first. > I'm still trying to poke holes in this because it seems too > simple. It seems like this solution meets your requirements, so I think you're safe. (Nice reflexes, though.) Layne Weathers Ifworld Inc. |
From: Chris J. <ch...@ch...> - 2002-02-01 18:48:59
|
1) "combined server log" is just the style of server log being used on my Apache webserver. 2) My problem with the authetication is that I do not control the source server in any fashion. In other words, users will signon to server A owned and operated by another company with which my company has an agreement to provide services. They will click on a link to go to my server B. We want them to be able to do that without signing on again. We will register users coming from A to B in our user database on B, so we know who all valid users are. I just need a way to know it IS a valid user coming from A. Thus, I need to tell the programmer at company A how to specify the user to my server at B via the URL in such a fashion that it is secure and I can reliably know they are authenticated at A and who they are. I'm using HTTPS for all connections, so it's only the URL I'd really have to worry about being hacked. All other data should be encrypted, should it not? ..chris ----- Original Message ----- From: "Peter Kursawe" <su...@si...> To: <php...@li...> Sent: Friday, February 01, 2002 12:01 AM Subject: Re: [Phplib-users] Basic authentication Hello Chris, here some ideas on your problems: > 1) Get the user name in the combined web server log. (I use apache, and > have not had any luck with other methods.) This is lower priority. I do not understand the phrase "... in the combined server log" ? > "single signon" capability -- that is, they logged in at the other site, and > the URL needs to contain the information that they logged in with. As you > know, the standard URL form is something like: > > [protocol]://[username]:[password]@host.domain.name:[port]/document_path I never ever would send passwords in an URL - very good opportunity for hackers! My plan (not realized yet!) to provide a single-sign-on: On server A there is a user database. On another server B the user U calls a page first time. B recognizes, that U isn't logged in and redirects the URL to a log on page at A. The URL must contain information that this request comes from B. U logs on. A opens a session with phplib and redirects the URL back to B including the session-id. B uses a tool like XML/RPC to establish a connection to A and reading the user information required. Instead of XML/RPC you may force A to write a file with the necessary user information and B can do a simple fopen. Further actions depend on your demands: If you do not use session variables, all is perfect. Every page on B can check if the user is still logged in at A. Or you have a phplib at B also to check that. This is a raw outline. In fact you have to do some more customizing. E.g. the server A must not give access to the user-files mentioned from other servers than B ... Sounds complicated, I know. But its very secure (I hope so at least ;-)) Peter Kursawe www.learn4use.com _______________________________________________ Phplib-users mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phplib-users |