Re: [xml-dev] RE: Encoding charset of HTTP Basic Authentication

["Pete Cordell" <petexmldev@codalogic.com>]

I'm surprised I'm in a minority of one on this.  I've snipped out lots of 
comments in a reply, but my basic position is that we shouldn't be adopting 
a "buyer beware" position when it comes to handling passwords when we know 
there are better ways to do it, and we have known that for the best part of 
a decade.

The upside of this is that I will be delving into my server configs and 
changing them to use Digest if I can.  So I'm pleased that the topic has 
been raised from that point of view.

A quick question before I do though, does Digest require the server to have 
access to the password in clear text form, whereas Basic allows the server 
to store the password in some hashed form?

Thanks,

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message ----- 
From: "Greg Hunt" <greg@firmansyah.com>
To: "Pete Cordell" <petexmldev@codalogic.com>
Cc: "xml-dev" <xml-dev@lists.xml.org>
Sent: Monday, January 30, 2012 11:29 AM
Subject: Re: [xml-dev] RE: Encoding charset of HTTP Basic Authentication


> Surely most of us here get paid to know how things work and what their
> strengths and weaknesses are.  The level of knowledge is sadly lower than
> it should be, but to paraphrase you, thats no excuse.  I don't think that
> digest was part of HTTP 1.0 and retiring standards is difficult.
>
> This, and the original issue, about character sets, is just evidence that
> things change; the industry's accepted level of knowledge and ideas of 
> good
> practice evolves and its up to us to understand the history.  The
> difficulty in using anything other than 8859-1 in post data (not exactly a
> lot of difficulty, but enough to cause a recurring class of unicode
> handling bug that people ring me up about) is probably another wrinkle
> related to what caused the lack of specification of the character set
> hidden in the base64 encoding.  The past had a different set of problems 
> to
> the present.  There was a page linked to earlier in this thread that
> asserted that the SSL threat model is entirely wrong, Perhaps today that 
> is
> true, but if you go back to the mid 90s there were large scale intrusions
> into network core routers, the network WAS relatively insecure and the
> security problem was not mostly trojans and key loggers on Windows
> desktops. We have to live with the past, more and more of it in IT as time
> goes by.
>
> On Mon, Jan 30, 2012 at 8:46 PM, Pete Cordell 
> <petexmldev@codalogic.com>wrote:
>
>> Original Message From: "Michael Sokolov"
>>
>> (I've flipped the order of Michael's reply to make the more important
>> comment first.)
>>
>>
>>  But yes, it's not good for public-facing auth, etc, and probably people
>>> (like you!) who don't know what it is have used it as if it were secure,
>>> so for that reason I agree with you, it's not the sort of standard that
>>> should be promulgated.
>>>
>>
>> I think that's the rub.  We all know that passwords should be kept 
>> secret,
>> and for a mechanism whose primary purpose is to exchange passwords it
>> surely
>> has a duty of care to help maintain that secrecy.  Sending passwords over
>> the Internet in the clear seems no more acceptable than storing passwords
>> in
>> a file in plain text.  No serious system would do the latter, so I think
>> it's only reasonable that we should object when systems do the former. 
>> "We
>> never said it was secure" is not an acceptable defence IMHO.
>>
>>
>>  It's actually pretty useful as an insecure *identification* mechanism. 
>> EG
>>> if you're operating inside a firewall and just want to give people a
>>> mechanism to say who they are, allowing for the fact someone might
>>> impersonate someone else, etc.  Not every authentication mechanism has 
>>> to
>>> be secure, just like not every door has to be locked - I mean do you 
>>> lock
>>> your bathroom door?  Closing it is enough; people knock and identify
>>> themselves.
>>>
>>
>> True, but it doesn't seem so much harder to always use Digest.  Surely 
>> it's
>> just calling a different function for most people?  (Digest may have its
>> weaknesses too, but that's a reason for making a stronger scheme rather
>> than
>> giving up completely.)
>>
>> I feel a bit like a disgruntled customer who's found his product doesn't 
>> do
>> what he thought it did based on the shining ads who on ringing into a 
>> help
>> line is told that I should have read the small print on page 215 :-)
>>
>>
>> Pete Cordell
>> Codalogic Ltd
>> Interface XML to C++ the easy way using C++ XML
>> data binding to convert XSD schemas to C++ classes.
>> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
>> for more info
>> ----- Original Message ----- From: "Michael Sokolov" 
>> <sokolov@ifactory.com
>> >
>> To: "Pete Cordell" <petexmldev@codalogic.com>
>> Cc: "Petite Abeille" <petite.abeille@gmail.com>; "xml-dev"
>> <xml-dev@lists.xml.org>
>> Sent: Sunday, January 29, 2012 10:31 PM
>>
>> Subject: Re: [xml-dev] RE: Encoding charset of HTTP Basic Authentication
>>
>>
>>  It's actually pretty useful as an insecure *identification* mechanism. 
>> EG
>>> if you're operating inside a firewall and just want to give people a
>>> mechanism to say who they are, allowing for the fact someone might
>>> impersonate someone else, etc.  Not every authentication mechanism has 
>>> to
>>> be secure, just like not every door has to be locked - I mean do you 
>>> lock
>>> your bathroom door?  Closing it is enough; people knock and identify
>>> themselves.
>>>
>>> But yes, it's not good for public-facing auth, etc, and probably people
>>> (like you!) who don't know what it is have used it as if it were secure,
>>> so for that reason I agree with you, it's not the sort of standard that
>>> should be promulgated.
>>>
>>> -Mike
>>>
>>> On 1/29/2012 5:15 PM, Pete Cordell wrote:
>>>
>>>> Holy s*** you're right.  Just used wireshark on some HTTP exchanges. 
>>>> All
>>>> this talk about online security and they effectively allow Base64 as an
>>>> 'encryption' algorithm!  People should go to jail for that!  Still 
>>>> think
>>>> it's a bad, bad, bad idea.  SIP has deprecated it and Twitter has
>>>> disabled it.  As I said, I'm pretty sure the IETF wouldn't accept
>>>> something similar to it these days.
>>>>
>>>> Pete Cordell
>>>> Codalogic Ltd
>>>> Interface XML to C++ the easy way using C++ XML
>>>> data binding to convert XSD schemas to C++ classes.
>>>> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
>>>> for more info
>>>> ----- Original Message ----- From: "Pete Cordell"
>>>> <petexmldev@codalogic.com>
>>>> To: "Petite Abeille" <petite.abeille@gmail.com>; "xml-dev"
>>>> <xml-dev@lists.xml.org>
>>>> Sent: Sunday, January 29, 2012 9:35 PM
>>>> Subject: Re: [xml-dev] RE: Encoding charset of HTTP Basic 
>>>> Authentication
>>>>
>>>>
>>>>  Convenient doesn't mean good though.  I think it _can_ be used over 
>>>> TLS,
>>>>> but since HTTP needs to support other schemes for non-TLS I can't see
>>>>> the point. I don't think it would accepted if it was introduced today.
>>>>>
>>>>> Pete Cordell
>>>>> Codalogic Ltd
>>>>> Interface XML to C++ the easy way using C++ XML
>>>>> data binding to convert XSD schemas to C++ classes.
>>>>> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
>>>>> for more info
>>>>> ----- Original Message ----- From: "Petite Abeille"
>>>>> <petite.abeille@gmail.com>
>>>>> To: "xml-dev" <xml-dev@lists.xml.org>
>>>>> Sent: Sunday, January 29, 2012 8:33 PM
>>>>> Subject: Re: [xml-dev] RE: Encoding charset of HTTP Basic 
>>>>> Authentication
>>>>>
>>>>>
>>>>>
>>>>> On Jan 29, 2012, at 9:17 PM, Pete Cordell wrote:
>>>>>
>>>>>  My understanding is that Basic is essentially considered insecure
>>>>>>
>>>>>
>>>>> Basic is convenient, universally  supported, and meant to be used over
>>>>> TLS if you care about this kind of things.
>>>>>
>>>>> ______________________________**______________________________**
>>>>> ___________
>>>>>
>>>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>>>>> to support XML implementation and development. To minimize
>>>>> spam in the archives, you must subscribe before posting.
>>>>>
>>>>> [Un]Subscribe/change address: 
>>>>> http://www.oasis-open.org/**mlmanage/<http://www.oasis-open.org/mlmanage/>
>>>>> Or unsubscribe: 
>>>>> xml-dev-unsubscribe@lists.xml.**org<xml-dev-unsubscribe@lists.xml.org>
>>>>> subscribe: 
>>>>> xml-dev-subscribe@lists.xml.**org<xml-dev-subscribe@lists.xml.org>
>>>>> List archive: 
>>>>> http://lists.xml.org/archives/**xml-dev/<http://lists.xml.org/archives/xml-dev/>
>>>>> List Guidelines: 
>>>>> http://www.oasis-open.org/**maillists/guidelines.php<http://www.oasis-open.org/maillists/guidelines.php>
>>>>>
>>>>>
>>>>> ______________________________**______________________________**
>>>>> ___________
>>>>>
>>>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>>>>> to support XML implementation and development. To minimize
>>>>> spam in the archives, you must subscribe before posting.
>>>>>
>>>>> [Un]Subscribe/change address: 
>>>>> http://www.oasis-open.org/**mlmanage/<http://www.oasis-open.org/mlmanage/>
>>>>> Or unsubscribe: 
>>>>> xml-dev-unsubscribe@lists.xml.**org<xml-dev-unsubscribe@lists.xml.org>
>>>>> subscribe: 
>>>>> xml-dev-subscribe@lists.xml.**org<xml-dev-subscribe@lists.xml.org>
>>>>> List archive: 
>>>>> http://lists.xml.org/archives/**xml-dev/<http://lists.xml.org/archives/xml-dev/>
>>>>> List Guidelines: 
>>>>> http://www.oasis-open.org/**maillists/guidelines.php<http://www.oasis-open.org/maillists/guidelines.php>
>>>>>
>>>>>
>>>>
>>>> ______________________________**______________________________**
>>>> ___________
>>>>
>>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>>>> to support XML implementation and development. To minimize
>>>> spam in the archives, you must subscribe before posting.
>>>>
>>>> [Un]Subscribe/change address: 
>>>> http://www.oasis-open.org/**mlmanage/<http://www.oasis-open.org/mlmanage/>
>>>> Or unsubscribe: 
>>>> xml-dev-unsubscribe@lists.xml.**org<xml-dev-unsubscribe@lists.xml.org>
>>>> subscribe: 
>>>> xml-dev-subscribe@lists.xml.**org<xml-dev-subscribe@lists.xml.org>
>>>> List archive: 
>>>> http://lists.xml.org/archives/**xml-dev/<http://lists.xml.org/archives/xml-dev/>
>>>> List Guidelines: 
>>>> http://www.oasis-open.org/**maillists/guidelines.php<http://www.oasis-open.org/maillists/guidelines.php>
>>>>
>>>>
>>>
>>> ______________________________**______________________________**
>>> ___________
>>>
>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>>> to support XML implementation and development. To minimize
>>> spam in the archives, you must subscribe before posting.
>>>
>>> [Un]Subscribe/change address: 
>>> http://www.oasis-open.org/**mlmanage/<http://www.oasis-open.org/mlmanage/>
>>> Or unsubscribe: 
>>> xml-dev-unsubscribe@lists.xml.**org<xml-dev-unsubscribe@lists.xml.org>
>>> subscribe: 
>>> xml-dev-subscribe@lists.xml.**org<xml-dev-subscribe@lists.xml.org>
>>> List archive: 
>>> http://lists.xml.org/archives/**xml-dev/<http://lists.xml.org/archives/xml-dev/>
>>> List Guidelines: 
>>> http://www.oasis-open.org/**maillists/guidelines.php<http://www.oasis-open.org/maillists/guidelines.php>
>>>
>>>
>>
>> ______________________________**______________________________**
>> ___________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: 
>> http://www.oasis-open.org/**mlmanage/<http://www.oasis-open.org/mlmanage/>
>> Or unsubscribe: 
>> xml-dev-unsubscribe@lists.xml.**org<xml-dev-unsubscribe@lists.xml.org>
>> subscribe: 
>> xml-dev-subscribe@lists.xml.**org<xml-dev-subscribe@lists.xml.org>
>> List archive: 
>> http://lists.xml.org/archives/**xml-dev/<http://lists.xml.org/archives/xml-dev/>
>> List Guidelines: 
>> http://www.oasis-open.org/**maillists/guidelines.php<http://www.oasis-open.org/maillists/guidelines.php>
>>
>>
>