ansaurus

Question

How do I secure authentication but not the payload?

Answer 1

+1 A:

How about OpenID? Is there a reason that you have to store authentication information?

Edited to add

Sorry didn't catch that it was a desktop app. How about OAuth?

GregD 2009-03-01 19:22:16

This is for a desktop client talking to a web service (no browser involved) so OpenID might not be a natural fit. I'll have to investigate whether this is an option.

Gili 2009-03-01 19:37:08

Answer 2

+1 A:

Why not just have your authentication mechanism protected by SSL and then forward to the rest of your application which runs under normal HTTP?

Kevin 2009-03-01 19:22:23

How would you do this? Send an URL containing a secret token back to the client and assume that he'll be the only person to hit it? Is this as safe as encrypting the payload in the first place (minus confidentiality)?

Gili 2009-03-01 19:39:50

Generally, the authentication mechanism would store some authentication information in the users session and the rest of the application would use that. Can you not use http sessions?

Kevin 2009-03-01 19:41:21

I'm using RESTful web services so sessions are kind of out of the question. REST suggests everything should go in the URL or headers but a man-in-the-middle could intercept that, right? Then again, aren't client sessions vulnerable in the same way?

Gili 2009-03-01 19:49:27

If man in the middle attacks are a *valid* threat for you, then you should be using SSL. Part of SSL is not only encrypting the data, but verifying who you are talking to.

Kevin 2009-03-01 19:52:46

If man-in-the-middle is a threat, you need integrity protection for the entire request. What happens if the man-in-the-middle takes the authentication token and replaces the rest of the message with his own malicious request?

erickson 2009-03-01 21:31:57

Erickson, you just brought up a very good point. This begs the question, what's the point of securing one's authentication if man-in-the-middle is not a concern? What other kind of attack are we protecting against?

Gili 2009-03-02 04:25:10

@Gili Man in the middle is not the same as passive listening. An attacker may be able to listen to your traffic but not intercept/redirect it.

Kevin 2009-03-02 14:20:44

Answer 3

+4 A:

The popular scheme is to have login form protected by SSL, while rest of the site doesn't use SSL. See for example popular social networking sites.

vartec 2009-03-01 19:34:49

There is no login form. It's a web service.

erickson 2009-03-01 21:29:07

Answer 4

+1 A:

Is there a way that you could structure the original request URL to indicate the user? Then, the server could respond with a different different realm (acting as "salt") for every user in the HTTP digest authentication response. For example, request URLs of the form http://user.y.com/service or http://www.y.com/user/service would result in a challenge response like:

WWW-Authenticate: Digest realm="[email protected]", nonce="oqa9hvq49krprkphtqc"

Can you explain what's driving the "no encryption" mandate? If you are subject to man-in-the-middle attacks, you need to protect the integrity of the entire request. There, SSL would be very helpful. If you absolutely cannot have encryption, would SSL using an unencrypted cipher suite be acceptable?

erickson 2009-03-01 20:30:21

ansaurus

tags:

views:

answers:

How do I secure authentication but not the payload?

related questions