[WEB SECURITY] username & pw in clear-text through SSL considered safe?

[Christian Frichot]

I think James and Martin mentioned above that if you compare an MD5
generated by the client against an MD5 in the database then that data
as it's transmitted across the Internet becomes the password. If this
information is eavesdropped, an attacker can just resend that hash to
impersonate you. So the added control here isn't strictly all that
much, more like another layer of obsfucation, or preventing your
password from reuse if you happen to use the same password for
multiple web apps.

I think best practice is that authentication traffic is encrypted
using SSL/TLS, and is POSTed not sent via HTTP Headers or within the
URL. This is what most websites (finance, online purchasing, whatever)
do.

Regards,

Christian

On Wed, Jun 18, 2008 at 9:51 AM, Chris Varenhorst <varenc at mit.edu> wrote:
> Just to jump in....netvibes.com seems to have a javascript implementation of
> md5.  The js code referenced is here..
> http://cdn.netvibes.com/js/c/Netvibes.js?v=410
> its a bit unreadable as is, but you can find other implementations around
> the internet.
>
> I'm not sure if hashing the password on the client side would be best
> practice (anyone have a strong opinion?) but it seems effective.
>
> -Chris
>
> On Tue, Jun 17, 2008 at 4:37 PM, wilke rodriquez <wilkepower at msn.com> wrote:
>>
>> What is considered best practice in this area?  How is it that sites like
>> netvibes.com are able to hash the password before transmission, I couldn't
>> find any javascript code doing the hashing there.
>>
>>
>> ________________________________
>> > Date: Mon, 16 Jun 2008 16:04:34 -0400
>> > From: rklists at gmail.com
>> > To: wilkepower at msn.com
>> > Subject: Re: [WEB SECURITY] username & pw in clear-text through SSL
>> > considered safe?
>> > CC: websecurity at webappsec.org
>> >
>> > It seems like the issue may have become confused a bit.
>> >
>> > The original question was in regards to transmitting credentials in
>> > an HTTP Header. This does not necessarily mean a URL. An example of a
>> > sensitive, non-URL header value that is used regularly is a Session ID
>> > in a cookie. Since this is the de-facto way of handling session
>> > management in most web applications, we'd really be in trouble if we
>> > couldn't trust the confidentiality of sensitive data transmitted
>> > through HTTP Headers (except, of course, for URLs).
>> >
>> > Cheers,
>> >
>> > Rohit Sethi
>> > Manager, Professional Services
>> > Security Compass
>> > http://www.securitycompass.com
>> >
>> > On Sun, Jun 15, 2008 at 9:28 PM, wilke rodriquez <wilkepower at msn.com>
>> > wrote:
>> > > Hi All,
>> > >
>> > > I recently came across a website that passed the user credentials
>> > > through
>> > > the http header in clear-text but via https.
>> > > Is this practice considered secure?
>> > > Would this also show that the passwords are being stored in clear-text
>> > > and
>> > > not encrypted with a salt value in the db?
>> > > It seems to be there are a few more secure options when dealing with
>> > > authentication what do you all suggest as the best for a low user
>> > > (less than
>> > > 10) system?
>> > > The system does need added security due to the contents.
>> > >
>> > > Thanks
>> > >
>
>



-- 
Christian Frichot
e: xntrik at gmail.com
p: 0433 490 117
w: http://un-excogitate.org

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA