OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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


Subject: Re: Encrypting a password


I was asked to forward this if I agree.
I agree so I'm forwarding. :)

From: Mike Burati 
Sent: Wednesday, March 19, 2003 9:36 AM
Subject: RE: [wss] Encrypting a password

Sorry for jumping in as a non-voting observer, but I have a couple
comments...

I agree with Hal's concerns about the password scenario potentially
confusing people into believing that it's a recommended secure mechanism
(relative to other choices), but I disagree that it should be dropped from
interop for the reasons given.

- Developers/Customers/Integrators are going to try and do it anyway - if
you don't show them the best way to do it from a security and interop point
of view, that may then just breed more non-secure/non-interoperable one-off
implementations of the scenario.

- I really wish the connection pooling, privileged account answer applied
across the board - it would make life so much easier.  Unfortunately, the
real world includes a lot of legacy stuff out there that still requires (or
rather the customers require in many cases) the end user's username/password
credentials :-(

- If there weren't a customer demand for such questionable half-baked U/P
based delegation out there, then there wouldn't be so many SSO and SSO-like
U/P credential based solutions in the market trying to solve them.

- I'd prefer to see the U/P use case included, with the caveats well
documented about the known risks involved of using that scenario in
practice.

- Many customers are well aware of the risks of using HTTP Basic Auth and
U/P based FORM auth in their web sites, web services, portals and the
backends accessed by those systems, (even with SSL / transport security),
but the majority of the market still uses those mechanisms and will continue
to do so even with more secure standards available...

Thanks for listening, if you made it this far :-)
..Mike


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