Security concern - Not good to pass username:password in every HTTP transaction

[Gaurav Dhiman]

I noted that the way OrientDB authenticate user for every HTTP access is by expecting username:password encoded in base64 for every HTTP call. Isn't that a bad idea.

I think, username:password should only be expected once at the time of login (HTTP connect call). Once connect is successful, OrientDB should return session ID and in consecutive call to ORientDB server that session ID should be sent in place of username:password combination. Using sessionID OrientDB should be able to fetch current logged-in user and and its details at server end to perform specific actions.

Can we achieve above in OrientDB (for HTTP REST calls) ?

Regards,

Gaurav

[Mateusz Dymczyk]

REST by definition is stateless so what you are asking for isn't REST. What's bad with sending credentials with every request?

Mateusz

[Domenico Rotondi]

Hi,

yes HTTP is stateless, but this doesn't mean we can't had session's concept like almost all web applications do.

Sending credentials with every request is a bad idea from an operational and security point of view.

From an operational point of view this implies that the server has to execute the authnetication process for each request, which implies addind overhead to each request has compared to simply check is a session ID exists and is still valid.

From a security point of view resending credentials with each request increases the risk that the credentials are caught by others (even using TLS/SSL; see the patch Apple was urged to provide to fix a bug in its implementation of the TLS/SSL stack!), unless you take specific measures to protect them (which increase the processing overhead).

Ciao

   Domenico

---

--

---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mateusz Dymczyk]

I'm not talking about statelessness of HTTP but about basic REST principles. OrientDB is trying to expose a REST interface, which by definition is stateless. The kind of statefulness you are talking about also has a lot of problems (what if you have a load balancer between your clients and distributed DB services? you need to manage that which usually means much more work than plain authentication/authorization). About security you can as well say that someone can find out your session ID the only benefit of it is that it might sooner or later expire.

Mateusz 

To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Milen Dyankov]

Well, I agree with Domenico - this (passing username and password on each request) is a security issue. In fact at most of my customers such approach would never pass thier security audits. 

Note, I'm talking about the general approach not the OrientDB case. It is a whole different story whether it's a good idea to have the database availabe via REST in a network where the traffic can be sniffed. I personally prefer to have App <-> DB communication isolated in dedicated network when possible. 

But back to the issue - the statlesness of REST has nothing to do with this. There are number of ways to provide more secure stateless authentication (tokens beeing the simplest one) then sending passwords with each request. 

Just my 2 cents.   

To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://about.me/milen

[Domenico Rotondi]

Hi Mateusz,

me too was referrring to HTTP principles.

On the session ID (which is, at the end, a temprary access token) discussion: these kind of tokens are temporary, while credentials are more stable and don't require the processing that is associated to the valdiation of credetnials.

Yes someone can stolen your session token; but think at what happens if someone steals a session token as compared to steal your credentials!

If I still your session token I could do something while the token is valid, but you, for example, are still able to login to the system. If I steal your credentials, I, for example, can log to the system, change the password and permanently throwt you away from the system!

Even if you use SSL/TLS there could be risk; indeed being credentials more stable in time (you don't change your password every hour or day), the encrypted flow can present some recurring patterns that help in restricting the "space" of possible credentials. Session tokens being temporary (especially if you take the habit to assign a limited time validity) add entropy to the system that avoid reducing the possibility for atatckers to guess tokens.

Ciao

   Domenico

---

To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout .

[Gaurav Dhiman]

I too feel that exposing whole DB over REST is inviting hackers to your app; esp for public / cloud apps. There should be some configuration switch using which we can enable / disable the whole REST functionality. Ideal will be blocking default REST exposure of DB and giving access to server only through server defined function (even login). Everything on REST should be accessible through REST call to functions like http://<<host>>:<<port>>/function/<<db>>/<<function name>>/ <<arguments>>. In this case all security and cross-checking can be done by developer in server side defined functions.

Back to main topic, I noted that OrientDB returns OSESSIONID on successful connect. What is the purpose of OSESSIONID if OrientDB does not use it in subsequent HTTP / REST calls to apply access control.

Regards,

Gauarv

[Luca Garulli]

You should pass authentication header only the first time, then OrientDB returns a session id. If you pass that session id, you're good.

Lvc@

[Gaurav Dhiman]

On Tue, Mar 11, 2014 at 4:31 PM, Luca Garulli <l.ga...@gmail.com> wrote:

You should pass authentication header only the first time, then OrientDB returns a session id. If you pass that session id, you're good.

Thant's good ! It should be like that only.

Few more related questions:

1. Any specific way to send session id (OSESSIONID) ? Do we need to send that in header (what config in header) or as parameter (for get) or as data (for post) ?

2. What is the session life by default ?

3. Can we configure life of session ? For instance lets say infinite, till user log out explicitly.

Regards,

Gaurav

 

Lvc@

You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/BXDuzJ3AHUc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.

[Gaurav Dhiman]

Once login is successful and we get OSESSIONID in cookie, do we need to sent that explicitly in subsequent HTTP calls or is that sent automatically by browser (being part of cookie). Asking so, as in subsequent HTTP calls I could not see the OSESSIONID in request header under chrome debugger.

1. If we need to send it explicitly, how to send it - What header to set ?

2. How can we set the session life to infinite? Session should not die unless user explicitly logs out.

Regards,

Gaurav

On Tuesday, March 11, 2014 4:52:08 PM UTC+5:30, Gaurav Dhiman wrote:

Lvc@

You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/BXDuzJ3AHUc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to orient-database+unsubscribe@googlegroups.com.

[Devon Miller]

I know this is a slightly older thread, but I've not been able to make that work. Using curl sessions with cookie saving support, I have been unable to use ONLY a OSESSIONID, once issued, to make a valid HTTP command call. I just opened an issue on the documentation. I could not quite trace the code perfectly, but the code also suggests you need to send the http authorization each time as it checks the user field in the session token on the server side at the very least.

[Luca Garulli]

Hi,

1) Look at Studio: put the OSESSIONID in the request's header.

2) You could set the property "network.http.sessionExpireTimeout" that now is 300 seconds (5 minutes).

Lvc@

 

[Devon Miller]

Actually, that's a really good idea that I had not thought of to get a semi-definitive answer.

I opened up the google console and tracked network traffic. I do see the Authorization header on the HTTP API calls along with the OSESSIONID even after login and within the session timeout period.

I looked at the orientdb-api.js API (in the distribution's www/js folder) as well and I could see the auth getting sent for the open call but not on some of the others. But the API did not appear to manipulate sessionids at all so I'm not sure how it is handled.

As near as I can tell, the OSESSIONID allows you to optimize the request but it still requires the auth header.

1. Remote Address:
   ::1:2480
2. Request URL:
   http://localhost:2480/command/dmm/sql/-/20?format=rid,type,version,shallow,class,graph
3. Request Method:
   POST
4. Status Code:
   200 OK
5. Request Headersview source
1. Accept:
   application/json, text/plain, */*, application/json
2. Accept-Encoding:
   gzip,deflate,sdch
3. Accept-Language:
   en-US,en;q=0.8
4. Authorization:
   Basic YWRtaW46YWRtaW4=
5. Connection:
   keep-alive
6. Content-Length:
   18
7. Content-Type:
   application/json;charset=UTF-8
8. Cookie:
   OSESSIONID=OS14015836464586386280545031455507
9. Host:
   localhost:2480
10. Origin:
    http://localhost:2480
11. Referer:
    http://localhost:2480/studio/index.html
12. User-Agent:
    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
6. Query String Parametersview sourceview URL encoded
1. format:
   rid,type,version,shallow,class,graph
7. Request Payload
1. select * from role

[Gaurav Dhiman]

On Saturday, May 31, 2014 9:37:07 PM UTC+5:30, Lvc@ wrote:

Hi,

1) Look at Studio: put the OSESSIONID in the request's header.

Do we need to place it or is it placed automatically by browser in subsequent server calls ? I have an understanding that it is placed automatically in all subsequent calls.

If we need to programatically place it before making HTTP / REST call, how to do it ?

This might be a reason that some of my HTTP / REST calls return 401 error.

 

Lvc@

--

---
You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/BXDuzJ3AHUc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Devon Miller]

Hi,

1) Look at Studio: put the OSESSIONID in the request's header.

Do we need to place it or is it placed automatically by browser in subsequent server calls ? I have an understanding that it is placed automatically in all subsequent calls.

The cookie should go back automatically from the browser. But you have to add it in (in a server specific way) if you write your own server that sits between your client and the db and its not a pass through.

I'm writing a finatra server between a web front end and orientdb and other services. So I was trying to test my understanding of the security approach in orientdb using curl.

 

If we need to programatically place it before making HTTP / REST call, how to do it ?

In JS, you can set it in the headers by adding an ajax preFilter in jquery.

[wajid shafi]

Whenever you are creating a rest api and connecting to orientdb instance , then you need to have proper header in place. The most important is authorizarion header which changes on every machine. We need to know what is the authorization token on that particular instance , which can be detected by proxy tools.