0

I've asked a question related to this one here:

Securely Passing UserID from ASP.Net to Javascript

However now I have a more detailed/specific question. I have the service and I have the application that is going to consume the service my plan to secure it, is to generate a hash based on some values, a nonce, and a secret key. My only issue is that it seems that in order to verify the hash I will have to send all of the values plus the nonce, except the secret key. Is this a flaw in my design or is this how such things are done? I have googled around and haven't been able to find out if this is the right and secure way to do this.

For example lets say I need to pass values 1,2, and 3 to my rest service, so I users phone number, the nonce, and, the secret key to generate a hash, now in order to generate the hash again I would need to pass all of the above except the key (which I can retrieve based on the users phone number).

I am totally leaving my service up for attack, securing it properly, or somewhere in between?

EDIT: made a spelling and grammar correction

EDIT 2: Finally came to to a satisfactory solution by using MVC 4 with forms authentication, identical cookie names between two projects, and making use of a globally applied [Authorize] attribute

Community
  • 1
  • 1
Pseudonym
  • 2,052
  • 2
  • 17
  • 38

1 Answers1

1

There is nothing inherently wrong with this plan. If the client sends:

data . nonce . hash(data . nonce . shared-secret)

Then the server verifies the message by checking that hash(data . nonce . shared-secret) matches the hash provided by the client, you would be safe against both tampering and replay (assuming, of course, that you're using a reasonable cryptographic hashing algorithm).

Under this design, the client can even generate its own nonces, provided there is no risk that two clients will generate the same nonce.

However, eavesdroppers will still be able to see all the data you send… So, unless there is a very good reason not to, I would simply use https (which, unless there are other requirements I'm unaware of, be entirely sufficient).

David Wolever
  • 148,955
  • 89
  • 346
  • 502
  • Alright, makes sense, so could data contain a user identifier and still be secure? And I am making use of HMAC256 algorithm fyi. – Pseudonym Nov 15 '12 at 18:19
  • You'd have to define "secure". Under this scheme, the server will be able to detect tampering and replay attacks, but it will *not* be secret (obviously). – David Wolever Nov 15 '12 at 18:20
  • Fair enough, within this scope we are trying to prevent replay and man-in-the-middle attacks, by the time the users gets to the area of the application that makes this rest call they should have had their credentials validated beforehand – Pseudonym Nov 15 '12 at 18:23
  • If users have already been authenticated, what use is this? Assuming this will be done through a web browser, if the authentication is being performed over an insecure channel, a man in the middle could simply steal the user's credentials. – David Wolever Nov 15 '12 at 18:25
  • We are also trying to prevent users from "impersonating" another user and getting data back that way. I know if an attacker gets a users credentials all bets are off but the goal is to prevent a replay attack, and prevent outside persons from just making a REST call and getting data back – Pseudonym Nov 15 '12 at 18:26
  • HTTPS will eventually be implemented in this before the application goes to production – Pseudonym Nov 15 '12 at 18:28
  • Ah, in that case, why do you need any of this? – David Wolever Nov 15 '12 at 18:29
  • Because this will initially be deployed on local intranet and this project is being planned to serve as a template for writing out future projects. So basically to prevent users from doing something they shouldn't and for practice – Pseudonym Nov 15 '12 at 18:32