Webservice for uploading data: security considerations

Question

Hi everyone!

Im not sure about what authentification method I should use for my webservice. I've searched on SO, and found nothing that helped me.

Preliminary

Im building an application that uploads data from a local database to a server (running my webservice), where all records are merged and stored in a central database. I am currently binary serializing a DataTable, that holds a small fragment of the local database, where all uninteresting stuff is already filtered out. The byte[] (serialized DataTable), together with the userid and a hash of the users password is then uploaded to the webservice via SOAP. The application together with the webservice already work exactly like intended.

The Problem

The issue I am thinking about is now: What is if someone just sniffs the network traffic, 'steals' the users id and password hash to send his own SOAP message with modified data that corrupts my database?

Small update: Not to be misunderstood: I dont worry about a syntactic/validation problem. All data that arrives at the webservice is of course validated, and I unit-tested that intensively. I meant 'attackers could semantically corrupt the database': e.g. a user can edit only his submitted records. An attacker could make use of that fact, and masquerade hisself as some user and edit his uploaded data.

I just dont want that people with some technical understanding can just dump the database with garbage in another users name.

Options

The approaches to solving that problem, I already thought of, are:

• Using ssl + certificates for establishing the connection:
  • I dont really want to use ssl, I would prefer a simpler solution. After all, every information that is transfered to the webservice can be seen on the website later on. What I want to say is: there is no secret/financial/business-critical information, that has to be hidden. I think ssl would be sort of an overkill for that task.
• Encrypting the byte[]:
  • I think that would be a performance killer, considering that the goal of the excercise was simply to authenticate the user.
• Hashing the users password together with the data:
  • I kind of like the idea: Creating a checksum from the data, concatenating that checksum with the password-hash and hashing this whole thing again. That would assure the data was sent from this specific user, and the data wasnt modified.

The actual question(s)

So, what do you think is the best approach in terms of meeting the following requirements?

• Rather simple solution (As it doesnt have to be super secure; no secret/business-critical information transfered)
• Easily implementable retrospectively (Dont want to write it all again :) )
• Doesnt impact to much on performance

What do you think of my prefered solution, the last one in the list above?

Is there any alternative solution I didnt mention, that would fit better?

Am I worried about nothing? Is it enough to just send the users id and password hash with every SOAP message?

You dont have to answer every question in detail. Just push me in the right direction. I very much appreciate every well-grounded opinion.

Thanks in advance!

Answer 1

You absolutely must use HTTPS. SSL is by far the simplest secuirty system you could implement, and it only costs $30 per year. Do not reinvent the wheal! After all how much is your time really worth? You can't just call an "encryption function". To implement this protocol properly you have to worry about block cipher modes, Initialization Vectors, a string2key (s2k) function, and finely a way to authenticate the server and/or client (asymmetric cyrpto/PKI...) . In short the vast majority of programmers have absolutely no idea what goes into creating a truly secure protocol.

Further more it is absolutely impossible to create a secure session and authentication without ssl. This is coming from the OWASP top 10 A3:Broken Authentication and Session Management.

Hashing the users password together with the data

What you are describing here is a Hash Message Authentication Code or HMAC. There is no point in doing this if you are just sending the username and password over the line in clear text. The whole point of an hmac is that you are using a secret, and the password isn't a secret unless you use ssl.

If you are sending the password hash over the wire to authenticate then you really fucked up. The whole point of hashing a password is to slow down the attacker after he has used sql injection to obtain another users password hash from the database, if you are using a message digest to authenticate then the attacker won't have to break the hash. It is as if you are storing passwords in clear text.