in reply to Securing your SOAP Application

I would have thought it better to encode your username and password inside the SOAP body and encrypt them using some form of key known to client and server. Naturally you would then have to mime encode it but thats what CDATA sections are for.

Of course this only becomes as strong as your key management but you are at least not passing your credentials in plain text.

You could then, should you wish run this over SSL which is tradtionally port 443 (IIRC).

On a different tack, I do think you should re-phrase the comment: 
 so this does not stop you from implementing Schneier's suggestion to 
+keep SOAP off of HTTP.

[download]
HTTP is a protocol not a port. SOAP uses HTTP but can be transmitted over any port (hence why we have servers on 8080, 8800 etc as alternate standards). I think that is what you meant but (to my eyes) that isn't what you said.

HTH

Replies are listed 'Best First'.
Re: Re: Securing your SOAP Application
by hardburn (Abbot) on Jul 30, 2003 at 15:54 UTC

    I would have thought it better to encode your username and password inside the SOAP body and encrypt them using some form of key known to client and server.

    At first, I tried a similar scheme on my own version of the My::SOAP module above. Then I realized that its really a duplication of effort. You end up writing your own credintial validator (eek!) and your own crypto system (double-eek!). I don't see any benifit to this over just using SSL and sending the bare username/password.

    HTTP is a protocol not a port. SOAP uses HTTP but can be transmitted over any port . . .

    No, I meant HTTP. The problem Schneier and others have with SOAP is that it can be tunnled through HTTP and thus negate the benfits of a firewall. This is because an application-layer firewall not only has to analyze the HTTP headers, but it would also have to take apart the SOAP message. By dedicating a port to SOAP without tunneling, the firewall only has to worry about one thing passing over that port. Moving your HTTP server to port 8080 but still accepting SOAP connections over it doesn't solve this problem.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
      I see what you mean now about HTTP (sorry about that :P ).

      Frankly I have avoided the whole authentication issue by only exposing publicly available (in the company) data and making it query only. I couldn't use SSL in my projects (for various political reasons) and my scheme was the path of least resistance.

      Until there is a standard I guess it boils down to your own environment. In my case, packing it inside the envelope will have to be the way to go. Plus our security policy (at work) is to encrypt everything, SSL or otherwise.

      I do wonder, however, whether you have considered using some form of digest mechanism in your method? Do you think this is worthwhile?

      Thanks for your feedback :)
[reply]

        I do wonder, however, whether you have considered using some form of digest mechanism in your method? Do you think this is worthwhile?

        Perhaps. The Apache::Htpasswd module already stores the passwords in encryped form. Apache's .htpasswd file format supports using hashes instead of encrypted data, but the module doesn't appear to support this feature. For just transfering the password, it couldn't hurt to use a digester.

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        Note: All code is untested, unless otherwise stated

[reply]

In Section Meditations