[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: Encoding charset of HTTP Basic Authentication

  • From: Greg Hunt <greg@firmansyah.com>
  • To: Pete Cordell <petexmldev@codalogic.com>
  • Date: Mon, 30 Jan 2012 22:29:38 +1100

Re:  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: 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: 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: 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/
Or unsubscribe: xml-dev-unsubscribe@l....org
subscribe: xml-dev-subscribe@l....org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: 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/
Or unsubscribe: xml-dev-unsubscribe@l....org
subscribe: xml-dev-subscribe@l....org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: 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/
Or unsubscribe: xml-dev-unsubscribe@l....org
subscribe: xml-dev-subscribe@l....org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: 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/
Or unsubscribe: xml-dev-unsubscribe@l....org
subscribe: xml-dev-subscribe@l....org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: 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/
Or unsubscribe: xml-dev-unsubscribe@l....org
subscribe: xml-dev-subscribe@l....org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.