1

So after much frustration with Janrain's PHP OpenID Library I decided to switch over to the LightOpenID library because it's much simpler and according to this answer, doesn't compromise on security as long as the OpenID provider is implemented correctly (hopefully this is the case since they hold all the user's information anyways :P).

The one remaining issue I have is that LightOpenID returns the OpenID authentication request using the GET protocol. I understand that for convenience-sake I can always re-direct the user using header after I've extracted the relevant information, but I'm wondering what issues I have to worry about with the authentication information being transmitted through GET rather than through POST. For example, It seems that the user's personal information they provided (such as address, email, etc., whatever is requested using sregs) could be much easier to intercept and extract by a middle-man than if it were encrypted and passed through POST.

Here's how I'm picture the data being transmitted:

  1. End user enters OpenID, sends to my server (can use any protocol)
  2. My server asks the OpenID Provider for authentication, use header to redirect to the OpenID Provider's page and have the end user allow my site if necessary. (can use any protocol)
  3. OpenID Provider sends back authentication information to my server using GET. This includes the above mentioned concern about user's personal information, meaning any middle man just has to catch the passed URL to extract the personal information. As far as I know the authentication information is useless to them since I could only use it once to validate login and generate a different unique ID to use for tracking the user's session. For added security I can only ask for sreg information once for the initial registration.
  4. My server processes the information, ultimately redirecting the end user to the page which required authentication in the first place (again can use any protocol, plus I can choose what information to send)

Am I completely wrong about this? If not, how can I alleviate these problems?

p.s. I'm not too familiar with the terminology, please let me know if I've made any mistakes and how to fix them.

Community
  • 1
  • 1
helloworld922
  • 10,801
  • 5
  • 48
  • 85
  • See also [Is either GET or POST more secure than the other?](http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other) on why POST isn't inherently more secure just because browsers don't visualize that payload. – mario Oct 16 '12 at 03:26
  • Sorry, I should have been more clear. My understanding is that in order to have HTTPS encryption you need to pass data as POST, not as GET. Is this correct/incorrect/how do I tell? – helloworld922 Oct 16 '12 at 05:06

1 Answers1

1

There's two aspects to using OpenID successfully that apply to this particular question:

  1. Authentication - does the request come from the expected source and has it not been tampered?

  2. Security - has anyone, besides the user and your server, seen the request in transit?

OpenID assertions are signed by the server using either a shared or private key; in the latter case your server has to make another round trip to the server to verify the request.

Using GET or POST doesn't matter in terms of security, but using SSL does. Both methods transmit the data in a similar fashion, so any packet sniffer will have no problems retrieving sensitive data. However, when SSL is applied, both methods are equally protected.

Ja͢ck
  • 170,779
  • 38
  • 263
  • 309