Re: [Bug-wget] Sprint Security non-challenge use case

[Tim Pizey]

Hi Micah,
On 1 July 2010 19:49, Micah Cowan  wrote:
> On 07/01/2010 05:23 AM, Tim Pizey wrote:
>> Hi Micah and list,
>>
>> Thanks for a great utility, whose size and complexity I am only just
>> beginning to appreciate.
>>
>> I have just been tripped up by the newish (post 1.10.2 ) behaviour of
>> wget, that it relies upon a challenge prior to supplying
>> authentication headers.
>>
>> I have written up the problem at
>> http://tim-pizey.blogspot.com/2010/07/using-both-http-basic-and-session-based.html
>>
>> To paraphrase: I think the old behaviour was more intuitive: if user
>> supplies username and password pass them on to server.
>>
>> The Spring Security auto-config (ie their default) is to respect
>> http-basic authentication if it is supplied but to redirect the 'user'
>> to a forms based login if it is not supplied, ie not to issue a
>> challenge.
>
> Yes, that happens on a few servers, and that's why
> --auth-before-challenge was made an option. Use that if that's what you
> want.
>
>> So I suggest that at the least the manpage wording is changed, if not
>> the behaviour reverted.
>
> What specifically would you wish to change?
>
> It's not my decision any longer, but reverting the behavior is a very
> bad idea IMO. There are obvious security problems with sending cleartext
> passwords as a default behavior, without first checking whether the
> server will allow you to send it in an encrypted form, which is why I
> made it a high priority to change that behavior in 1.11. It breaks any
> sense of decent security, and also breaks the RFCs.
>
> However, I suppose a case might be made for making an exception in the
> case of HTTPS, where even "cleartext" passwords would be sent over an
> encrypted tunnel.

As always when I trip up it just shows that I do not understand the
terrain well enough.
I did not read the manpage before tripping over this, so any amendment
there would
not have helped me, however I think that the current wording:

           Use of this option is not recommended, and is intended only to
           support some few obscure servers, which never send HTTP
           authentication challenges, but accept unsolicited auth info, say,
           in addition to form-based authentication.

Is misleading.

It might be reworded to suggest the real use case.

  This option in not recommended as it sends password information in cleartext,
  however it can be used safely over an https link. It is supplied to
support those
  servers which redirect to a form login page when basic authorisation
is not present.

My manpage writing skills are not up to it, but the fact that
authorisation headers
are only sent in response to a challenge, is only hinted at.

 `--user=USER' `--password=PASSWORD' Specify the username USER and
password PASSWORD for both FTP and HTTP
       file retrieval.  These parameters can be overridden using the
`--ftp-user' and `--ftp-password' options for
       FTP connections and the `--http-user' and `--http-password'
options for HTTP connections.

Maybe the following might be added:
       Even when specified passwords are only sent in response to a
challenge, unless forced by --auth-no-challenge.


regards
Tim