PDA

View Full Version : Security



Karl A. Sørensen
14-Sep-2005, 01:48 AM
The company I am working for is going to use web services to talk to another
company. This other company is also calling our web services. Since we are
new to using web services, we don't know how to easy implement security (we
want to make sure only this one customer is calling our web services, and
they want to make sure only we call their services).

My question is how to implement this in the simplest way (certificates,
https, ???) ?

TIA
Karl

David Martinko
14-Sep-2005, 08:49 AM
IMHO,

Passwords. I created a webservice in which to register my products. Only my
registration program should be calling the webservice... so on the server
side, I have a user_id and password as a part of the webservice call. If the
correct information is not provided, it's denied.


--
David Martinko
Redeemed Software
248-535-7495
RedeemedSoftware(SHIFT+2)Hotmail(PERIOD)com
www.redeemedsoftware.com

"Karl A. Sørensen" <kas@kamstrup-ems.no> wrote in message
news:0T3vahPuFHA.1684@dacmail.dataaccess.com...
> The company I am working for is going to use web services to talk to
> another company. This other company is also calling our web services.
> Since we are new to using web services, we don't know how to easy
> implement security (we want to make sure only this one customer is calling
> our web services, and they want to make sure only we call their services).
>
> My question is how to implement this in the simplest way (certificates,
> https, ???) ?
>
> TIA
> Karl
>
>
>

Anders Öhrt
14-Sep-2005, 09:19 AM
> Passwords. I created a webservice in which to register my products. Only
> my
> registration program should be calling the webservice... so on the server
> side, I have a user_id and password as a part of the webservice call. If
> the correct information is not provided, it's denied.

Then you need SSL/TLS with both client and server side certificated. Without
SSL/TLS your password can be sniffed, and without both client and server
side certificated you are vulnerable to a man-in-the-middle attack.

You could do a security-by-obscurity and request a challenge from the
server, and pass this together with a hash back, where the hash is either
salted or keyed, which would work without other encryption.

// Anders

David Martinko
14-Sep-2005, 09:47 AM
re: password can be sniffed.

For right now, that's ok. Why? because I have a database of who bought what
program. They purchase a certain number of licenses (usually 1). In addition
to a username and password, you have to pass an encrypted string which
identifies your PC. Even if you know the name and password, it is useless to
you because you don't know this encryption. And as for the information that
is returned... well, it is just a registration code which is unique to the
PC that made the request... it won't work on anyone elses computer.

So you can sniff it, get the username, password, and registration code...
but then what will you do with it? Nothing... it is useless data to you. :)

I will be watching this thread about the SSL because if I have a need to
have a secure webservice, I'll need that..

--
David Martinko
Redeemed Software
248-535-7495
RedeemedSoftware(SHIFT+2)Hotmail(PERIOD)com
www.redeemedsoftware.com

"Anders Öhrt" <Anders.Ohrt@capslock.se> wrote in message
news:Z06qUdTuFHA.1276@dacmail.dataaccess.com...
>
>> Passwords. I created a webservice in which to register my products. Only
>> my
>> registration program should be calling the webservice... so on the server
>> side, I have a user_id and password as a part of the webservice call. If
>> the correct information is not provided, it's denied.
>
> Then you need SSL/TLS with both client and server side certificated.
> Without SSL/TLS your password can be sniffed, and without both client and
> server side certificated you are vulnerable to a man-in-the-middle attack.
>
> You could do a security-by-obscurity and request a challenge from the
> server, and pass this together with a hash back, where the hash is either
> salted or keyed, which would work without other encryption.
>
> // Anders
>

Anders Öhrt
15-Sep-2005, 01:14 AM
> In addition to a username and password, you have to pass an encrypted
> string which
> identifies your PC. Even if you know the name and password, it is useless
> to you because you don't know this encryption.

If there is no challenge or time based info, the encryption can also be
sniffed.


> So you can sniff it, get the username, password, and registration code...
> but then what will you do with it? Nothing... it is useless data to you.
> :)

That's might be ok for your application, but I'm guessing it's not for
Karl's.


> I will be watching this thread about the SSL because if I have a need to
> have a secure webservice, I'll need that..

SSL is end-to-end secure if you have both client and server side
certificates. If you do, you can't be sniffed and you can just assign a
token to the application that is passed. It doesn't need to be hashed or
encrypted or anything.

// Anders

Karl A. Sørensen
15-Sep-2005, 01:52 AM
That is correct. We need to make sure that nobody else than our customer can
call our web services, so I guess we will be using server + client
certificates and ssl.

Regards
Karl

"Anders Öhrt" <Anders.Ohrt@capslock.se> wrote in message
news:OWWvyybuFHA.1896@dacmail.dataaccess.com...
>
>> In addition to a username and password, you have to pass an encrypted
>> string which
>> identifies your PC. Even if you know the name and password, it is useless
>> to you because you don't know this encryption.
>
> If there is no challenge or time based info, the encryption can also be
> sniffed.
>
>
>> So you can sniff it, get the username, password, and registration code...
>> but then what will you do with it? Nothing... it is useless data to you.
>> :)
>
> That's might be ok for your application, but I'm guessing it's not for
> Karl's.
>
>
>> I will be watching this thread about the SSL because if I have a need to
>> have a secure webservice, I'll need that..
>
> SSL is end-to-end secure if you have both client and server side
> certificates. If you do, you can't be sniffed and you can just assign a
> token to the application that is passed. It doesn't need to be hashed or
> encrypted or anything.
>
> // Anders
>

Anders Öhrt
15-Sep-2005, 02:39 AM
> That is correct. We need to make sure that nobody else than our customer
> can
> call our web services, so I guess we will be using server + client
> certificates and ssl.

Another way would be to setup a VPN tunnel and only allow access via it.
That would mean you don't need to bother at all, and leave the whole issue
to the network techs.

// Anders

Knut Sparhell
15-Sep-2005, 04:40 AM
Karl A. Sørensen wrote:
> The company I am working for is going to use web services to talk to another
> company. This other company is also calling our web services. Since we are
> new to using web services, we don't know how to easy implement security (we
> want to make sure only this one customer is calling our web services, and
> they want to make sure only we call their services).
>
> My question is how to implement this in the simplest way (certificates,
> https, ???) ?

I use:

* Server certificate and SSL
* User name and password (IIS Anonymous Access *not* allowed, Windows
Integrated authentication only)
* A ticket (random number, changed after each access)

If you can use Windows Integrated authentication this is quite secure
an can not easily be intercepted (it's encrypted regardless of data
encryption). If you must use some form of plain text username/password,
as in FTP, you will need SSL or similar to avoid leak or sniffing.

VDF HttpTransfer and SOAP Web Services support this directly, just fill
the properties on the client and remove the anonymous access on the
server. This is the main way to go for security between Windows peers.

Windows Integrated security is not so popular for web applications,
because thre may be many users and the users have to maintained through
the server operating system. It also only works for Windows clients.
Therefore we use anonymous access on IIS for web sites and lets the
application handle the user access. For a web service this may be very
different, and especially for Windows application-to-application
communication.

-----------------------
For two applications that must communicate safely and without
interference, you may use a ticket, with or without traditional security
as above. The server side maintains a ticket for each accepted client
application (or user). For each access (request) of a certain type a
new ticket is returned as part of the response. The client application
(or user) maintains the same ticket an updates it on a successful
request, based on the return. I use Random(maxinteger).

You may of course also implement a traditional application based
username/password pair, transferred at each call. But for an
applications a ticket, fixed as a username/password pair, or continously
changing, may be equally safe. Username and password could me merged
into a longer string, equally secure, when humans are not the ones to
use those regularily. Applications also doesn't complain about the work
of having to take a note of a new password (save a ticket) that changes
for every request. Humans would, loudly or silently avoid your site.
Applications just do what they are told to as long as the burden is not
too heavy. Doesn't work for public web services, of course.

--
Knut Sparhell, Norway

Karl A. Sørensen
15-Sep-2005, 06:10 AM
Good idea, but I don't think this is "possible" with this customer.

Regards
Karl


"Anders Öhrt" <Anders.Ohrt@capslock.se> wrote in message
news:ArTvmicuFHA.1880@dacmail.dataaccess.com...
>
>> That is correct. We need to make sure that nobody else than our customer
>> can
>> call our web services, so I guess we will be using server + client
>> certificates and ssl.
>
> Another way would be to setup a VPN tunnel and only allow access via it.
> That would mean you don't need to bother at all, and leave the whole issue
> to the network techs.
>
> // Anders
>