9

I want to make a light webapp on top of a REST api, where the user should authenticate only once, from then on all request against the web api would hopefully be done by keeping alive the username and password in some way.

I have already made a working prototype where I store the username and password in session variables if the first request to the REST api is successfull, and from then on every request is made with auth info gotten from the session variables. So far so good.

With this approach, I realize someone with access to the server would be able to read the password. Is there some way in PHP that i could follow my approach with an appropriate amount of security?

Update with some further details:

The intended goal here is to make a visualisation of data retrieved from an API, based on querying it with different data, but not having the user enter his username and password for each attempt. So the API is totally stateless, but the web application with gui should be statefull.

In this case I have no control over the Rest API, so each request to it will always require sending the API username and password with basic auth, there are no alternative schemes such as a API key, session token or anything like that. This is why I have to retain the username and password for as long as a user session lasts, and I wanted to know if the approach with storing them in session variables could be considered secure.

Bjørn Otto Vasbotten
  • 1,673
  • 1
  • 23
  • 32
  • 3
    Isn't this against the principles of REST? –  Nov 10 '13 at 22:19
  • 1
    This is a bit unclear. Can you go into more detail about who the client is in this situation? How are you logging into, and querying, the API? Where would you be storing the username and password? – Pekka Nov 10 '13 at 22:31
  • I hoped it was clear from my original question that I was doing HTTP requests to a REST Api with a username and password that is kept in PHP $_Session variables so that my users only have to enter them once, but i have updated the question with a bit more info now. – Bjørn Otto Vasbotten Nov 11 '13 at 07:28
  • Your question is still unclear. Why must you store username and password in the session when each request includes username and password? – Marcus Adams Nov 11 '13 at 14:38
  • Because i want the user to only need to login to my webapp once, using their api username and password. – Bjørn Otto Vasbotten Nov 11 '13 at 15:03

1 Answers1

1

As long as you're not storing session state on the REST API server, only on your client webapp, it seems fine from an architectural point of view.

If you really must use the username and password and can't get a disposable token, you may encrypt them with a server-side key, and decrypt on-the-fly when you send them to the API, so even if someone can hijack a session they can't obtain the username and password without the server-side key, but you should be a lot more careful with leaking your php session anyway.

PHP Session Security.

Follow the steps outlined in the answer for that question, except that you should use HTTPS for all interactions, between the user and the webapp, and between the webapp and the REST API.

Community
  • 1
  • 1
Pedro Werneck
  • 40,902
  • 7
  • 64
  • 85
  • So there are no things I should/could do like apply encryption, stiffen up server/PHP settings, and so on? – Bjørn Otto Vasbotten Nov 11 '13 at 07:15
  • Thanks, great article. If there are no further answers I'll give you the green tomorrow. :) Also, I found this article with an easy way to obfuscate the session: http://www.php.net/manual/en/class.sessionhandler.php Was it something like that you were thinking about? – Bjørn Otto Vasbotten Nov 11 '13 at 16:53
  • That's the idea, As long as you're not storing the key within the session itself. However, I don't think you need to go over encrypting the whole session data. – Pedro Werneck Nov 11 '13 at 17:17
  • One final thing: The main value from encrypting sessions is that if its a shared system, then other users can see them on a shared store on the host. While if someone gets root access to the host then they will probably be able to get the key and decrypt the sessions anyway? – Bjørn Otto Vasbotten Nov 13 '13 at 21:50
  • Exactly. While anyone with the session id can probably get the session, they need access to the server to have the key to decrypt it. – Pedro Werneck Nov 14 '13 at 00:44