How secure is it to send data from mobile device via web service to database?

Hi,

This is our setup.  Users have mobile devices with our software on.  They load products from the database (on our server behind a firewall) via web service also on our server and behind a firewall - separate server though.  They select the products they want to order and quantity.  This is sent as xml via web service to database and processed.

Now what I would like to know if how secure is this?  what can be done, if any, to improve security?

Regards
H
LVL 12
gbzhhuAsked:
Who is Participating?
 
Mikal613Connect With a Mentor Commented:
1) the web methods on the web service will have another parameter "secId" this will be sent from the client. The server will see if the secid is good if not it will exit the web method.
0
 
RubenvdLindenCommented:
Check out this great article on web service security on the Code Project:
http://www.codeproject.com/webservices/WS-Security.asp
0
 
adktdCommented:
Hi gbzhhu.
If we are talking about the default setup of webservices then there is NO security.  One way you can make it secure is by having your webservice over https.

Other ways:
    *  Use password digests in SOAP headers for authentication.
    * Use Kerberos tickets in SOAP headers for authentication.
    * Use X.509 certificates in SOAP headers for authentication.
    * Use Windows authentication.
    * Use role-based authorization to restrict access to Web services. This can be done by using URL authorization to control access to the Web service file (.asmx) or at the Web method level by using principal-permission demands.

I hope this helps. If you need more information let me know.
0
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

 
gbzhhuAuthor Commented:
RubenvdLinden,

I am reading the article and will give feedback.

adktd,

I am not security savvy.  Could you give me bros and cons on each method that you listed.  Some methods may not be doable because of our infrustructure.  We simply give our clients the device with our client program on.  our clients are on our database so they provide a userid and password.  Currently we send this (only encrypting the password) so for example Windows authentication won't work.

Once you give advantage/disadvantage then could you suggest 1 or 2 most suitable methods

Thanks
H
 
0
 
Mikal613Commented:
Heres the security from the XML people

http://www.xml.com/pub/a/ws/2003/03/04/security.html

1) Encryption is always a good security
2) also to have a security key signed as a parameter to your web methods
0
 
adktdCommented:
*password digest in soap headers :
Uses hashing to transmit client credentials in an encrypted manner so the password is not transmitted in clear text. In addition, Digest authentication can work through proxy servers. However, it is not widely supported on other platforms.

*Use Kerberos tickets in SOAP headers for authentication:
To ensure that only authorized parties gain access to this data, the site must first prove its identity by authenticating itself. Rather than the application authenticating directly to .NET WebServices, it will do so to Microsoft's Passport service in order to obtain a token (a Kerberos ticket), which it will then present to .NET WebServices. .NET WebServices, after verifying the token and confirming that it came from Passport, will confirm that it conforms to the appropriate user's privacy preferences. It will then accept the request and return the requested data in a SOAP response.

* Use X.509 certificates in SOAP headers for authentication:
It is using a form of digital signing(public and private key)
0
 
gbzhhuAuthor Commented:
Mikal,

>>2) also to have a security key signed as a parameter to your web methods
How does this work in practice? How will my users obtain a security key signed? and how will my web methods verify?

adktd,

*password digest in soap headers :
We were already sending password as encrypted.  How will this improve what we were already doing?

*Use Kerberos tickets in SOAP headers for authentication:
This means users will have to have a M$ Passport (hotmail etc)?.  This is hardly the case in our scenario, so this is probably a no no

* Use X.509 certificates in SOAP headers for authentication:
Similar to SSL?  How easy is it to implement?  Is it transparent to the users?
0
 
gbzhhuAuthor Commented:
>>1) the web methods on the web service will have another parameter "secId" this will be sent from the client. The server will see if the secid is good if not it will exit the web method

Pardon me for my lack of knowledge Mikal but could you put it in layman's terms.
- What is the type of the parameter?
- What values will be in it and where are they coming from?
- How will the server code know if the parameter is good.  What exactly is it testing for?

0
 
Mikal613Commented:
What is the type of the parameter?
  it can be anything (int, string) any security parameter you want to setup

You make the algorithm
0
 
adktdConnect With a Mentor Commented:
The Digest mechanism allows a client to authenticate itself by presenting credentials consisting of an MD5 digest, transmitted in a request message. It is based on the principle that the client and server are in possession of a shared secret, a password string. The advantage of this method is that the client password is only used in calculating the digest, so it remains safe from network exposure.

The Digest mechanism is a challenge/response protocol in which the client presents its credentials in response to a challenge from the server, which consists of an opaque data string called a "nonce". This nonce serves as additional input to the MD5 function, and allows the server to influence the digest value in a way not controlled by the client; this increases the security of the mechanism. In order to authenticate the client, the server simply compares the digest value received from the client with the value it has computed internally. If the values match, the client must be in possession of the same nonce and password as the server, so the client is authenticated. The same technique is used in the mutual authentication scenario, where the server authenticates itself to the client by presenting a digest as credentials in response to a challenge from the client. In this case also the challenge consists of a client-produced nonce to be used as input to the digest function, allowing the client to influence the digest value in a way not controlled by the server.
-------------------------------------------------------------------------------------
Kerberos allows a client (you) to exchange private information with a server across an otherwise open network. A unique key, called a ticket, is assigned to each person that authenticates to the network using his or her Key and password with special ticket management software. The ticket instead of your Key and password is embedded in messages and identifies you to various Kerberized services on campus when you attempt to connect to them. Your Key and password are never sent across the network.
Types of Tickets

You receive two types of tickets that help identify you.

    *      Ticket-granting ticket (TGT). When you use your Key and password to log into the Kerberos ticket manager installed on your computer, you receive a ticket-granting ticket (TGT) from a central Key Distribution Center (KDC). The TGT acts as a master ID that identifies you to all the various Kerberized services on campus.
    *      Service ticket. When you attempt to connect to a specific service (e.g., IMAP email), on a server that employs Kerberos for authentication, the service wants to know that you are who you say you are. To that end, your Kerberos-capable client software (e.g., Eudora) presents the ticket that was issued by the KDC, much as one might present a government-issued photo ID at airport check-in. The service first examines the ticket to verify your identity, and then checks to see if you are authorized to use the service. If everything checks out, you are authenticated and presented with a Service Ticket.
-----------------------------------------------------------
I hope these help you distiguise things a bit more.

0
 
gbzhhuAuthor Commented:
I see!  That sounds like the easiest approach.  int would be too risky because if someone intercepts the message they could resend it many times using that int.  Encrypted string is probably much safer
0
 
Mikal613Commented:
you could add date,sender a whole bunch of types
0
 
gbzhhuAuthor Commented:
adktd,

The digest machanism sounds good.  I would like to see a sample implementation if there is one.  The kerberos method is too complex.

Mikal,

Yeah I agree.  I could send several extra parameters which are encrypted and checked at the server jsut to confuse a would be hacker.  The most difficult thing is to test if it can be broken easily or not.

The deployment of our program is still a couple months or so away, so I am going to leave this question for a few days as I don't have time to implement any suggestions right now.  Don't be disheartened! I rarely abandon my questions
0
 
Mikal613Commented:
you may also want to use ports where you can add the web reference with a port number instead of just the url.

The hacker would need the port number as well
0
 
adktdCommented:
There's a really good example with a downloadable code you can take a look at :
http://www.eggheadcafe.com/articles/20021227.asp
0
 
gbzhhuAuthor Commented:
Will check this out.  Please bear with me
0
 
gbzhhuAuthor Commented:
Sorry for the long wait.  I think I am going to settle for Mikal's suggestion but also give adktd some points as he/she contributed a lot.

Thank you all.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.