Am 17.03.2010 17:19, schrieb Cédric Krier:
> On 17/03/10 09:15 -0700, Ian Wilson wrote:
>> I don't know much about this, but I thought repeating sending the
>> username and password was frowned upon.  Why is this a better approach
>> than the session/login approach?
> 
> It is a standard method and later we could implement authentication for HTTP
> 1.1 which provides a session approach.

+1

Let me try some basic thread analysis:

* The currently implemented login() method (even for XMLRPC)
  establishes a session with timeout. (I did not check, but assume same
  behaviour as for netrpc here.)

  a) If an eavesdropper is *not* able to listen to the login(), he will
     not get the credentials and can only use the existing session. He
     may keep this session alive a long time, but must not pause. This
     the session gives some limited security.

  b) If an eavesdropper is *able to listen to the login(), he will get
     the credentials and can establish new sessions at will.

  Only solution: use SSL.

* With Basic Auth the eavesdropper does *not* need to listen to the
  beginning of the session, since the credentials are passed with every
  request. So for BasicAuth the risk is higher.

  But again: solution is to use SSL.

When using SSL, the risk is the same for both cases.

When implementing HTTP/1.1 session authentication we'll get sessions.
Plus the session re-authentication is made by the HTTP client library,
thus the program does not need to care about session handling.

-- 
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP

Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult mit Mitglied bei http://www.7-it.de

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to