Re: Securing Web Servicesq
- From: <Andy>
- Date: Thu, 21 Dec 2006 11:49:43 -0000
I forgot to say, a replay attack on the same session is also avoided because
each packet has an incremental sequence number which is remembered by the
SSL session.
<Andy> wrote in message news:uZrppoOJHHA.3916@xxxxxxxxxxxxxxxxxxxxxxx
The stream can not be replayed. Each SSL connection has a unique session
key so just replaying an old stream on a new connection will not work
Remember to only send a hash of the password and not the full password.
This means that you don't have to store actual passwords on the server.
Regards,
Andy Kendall
"Chris" <nospam@xxxxxxxxxx> wrote in message
news:ucJtBbHJHHA.1044@xxxxxxxxxxxxxxxxxxxxxxx
I want to secure a web service so only authorized client apps can use it.
Will using SSL with an encrypted username and password in the soap header
do the job? I know you could potentially capture a post to a web service
(or anything sent over the web). Will SSL mean you can't capture the
stream to the web service and resend it? I am thinking if the post to the
web service contains the username and password then it is useless unless
SSL means it can't be captured and reused? Regards.
.
- References:
- Securing Web Servicesq
- From: Chris
- Re: Securing Web Servicesq
- From: Andy
- Securing Web Servicesq
- Prev by Date: Re: Securing Web Servicesq
- Next by Date: SslStream.AuthenticateAsClient is slow (calling the RemoteCertificateValidationCallback)
- Previous by thread: Re: Securing Web Servicesq
- Next by thread: SslStream.AuthenticateAsClient is slow (calling the RemoteCertificateValidationCallback)
- Index(es):
Relevant Pages
|