0

So feel free to not only answer this question but to throw out suggestions or improvements. I've never put together a large scale web application before. Here's my thought process:

  • Persistence Layer: Standard Database (MySQL right now)
  • Business Logic Layer: REST-like structure (PHP, Java Servlets, etc...)
  • Presentation Layer: Web Browser, Android devices (application not browser), and others

The reason I selected this architecture is so that devices can devise their own custom UI's and tap into the REST-like functionality by using GET, POST, and what not to interact with the server.

Problem 1:

The problem is, how do you secure user's information? You can authenticate the user over an SSL connection and return a special HASH so that the user can manipulate their account but if someone is listening on the network, all they have to do is listen for a REST call and steal the HASH. One solution is that all REST-like calls have to be over SSL, but this causes another problem.

Problem 2:

If the REST procedures are in SSL, the browser has to use SSL for everything which from my understanding can be slow and cumbersome when unnecessary. Also, SOP makes it impossible to use SSL ajax calls to the REST procedures from an unsecure browser. HTTP and HTTPS are considered different origins even though its the same origin, different protocol.

Is this solution viable? How would I solve these two problems? Or possibly (probably) is there a better architecture I should look into for my web application. Thanks in advance for all suggestions.

Spidy
  • 39,723
  • 15
  • 65
  • 83
  • What makes you say that SSL is expensive for everything? The only part that's (computationally) expensive is the creation of the session key; if the client keeps the connection open between requests (common with HTTP/1.1) then it's mostly about as expensive as plain HTTP. (It _is_ more awkward/costly to deploy though.) – Donal Fellows Apr 02 '11 at 21:16
  • From my understanding, the handshake is expensive (creation of the session key). This is the first time I've heard about the connection staying open. I'll have to look into that – Spidy Apr 02 '11 at 22:33
  • The handshake is indeed expensive because it requires a number of messages to be exchanged (it's computationally fairly expensive too, but that's neither here nor there on modern computers). But HTTP/1.1 has a provision for keeping a connection alive (“pipelining” IIRC). That's vital for speed anyway – pre it's introduction, HTTP was a slow pig of a protocol – and as long as the connection is to the same server with the same credentials, there's no problem. (It does make writing an HTTP protocol implementation hard, but most folks don't do that.) – Donal Fellows Apr 03 '11 at 21:49

2 Answers2

0

If you want to secure the information you have to use SSL, since anybody can listen the network, and see the user information. If you want to secure the access, then use HTTP authentication RFC2617. Over SSL, Basic is secure enough, but if you don't want to use SSL for every request, Digest is the way to go:

  • your application can be stateless: i.e. more restful, easier load balancing, ...
  • the authentication token can hardly be reused if listen (no session hijacking)
  • almost every HTTP client (browser or lib) can use basic or digest HTTP authentication.
Yannick Loiseau
  • 1,394
  • 8
  • 8
0

As it turns out, there is actually no great solution out there for this answer. You can either protect everything with SSL or devise your own home brew authentication system. A common method is to send the user a unique HASH, store the HASH in the database and in a cookie on the client's machine. Then only that user's IP, User-Agent, etc.. will be authenticated to that cookie.

So the answer is yes, the solution is viable. Extra security precautions will need to be maintained in order to disallow account hijacking. SSL for login will protected the password. A unique hash will allow the user to continue being authenticated without giving away their password to the account. Storing a large amount of information about the user such as IP, browser agent, etc... will disallow easy hijacking of an account.

Spidy
  • 39,723
  • 15
  • 65
  • 83