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

Lavery, Oliver oliver at securitycompass.com
Mon Jun 16 14:59:48 EDT 2008


Compare the transmitted hash against a hashed copy stored on the server. Very common outside of the web, and has the small advantage of not storing the cleartext password anywhere.

It's not much of an additional protection, since an attacker who can obtain the hash can replay it unless additional protection is in place (a nonce for instance)

Cheers,
~ol


----- Original Message -----
From: elspood at gmail.com <elspood at gmail.com>
To: jfvanmeter at comcast.net <jfvanmeter at comcast.net>
Cc: websecurity at webappsec.org <websecurity at webappsec.org>
Sent: Mon Jun 16 12:29:08 2008
Subject: Re: [WEB SECURITY] username & pw in clear-text through SSL considered safe?

If you hash the password before you send it to the server, how do you
validate it when it gets there?

On Mon, Jun 16, 2008 at 9:54 AM,  <jfvanmeter at comcast.net> wrote:
> IMHO it just seams wrong, with the potential for misconfiguration were the server will accept SSL 2,  random number generator in Debian's openssl package being predictable, etc. I dont' see why there is such a problem with adding a hash to the password to give it an addational layer of protection.
>
>
> http://www.schneier.com/paper-ssl.pdf
> http://www.sungate.co.uk/?p=314
>
> Just my two shiny centavos --JOhn
>
>  -------------- Original message ----------------------
> From: "Mike Fratto" <mfratto at gmail.com>
>> > 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?
>>
>> Sure. Provided your using a trusted SSL certificate, the transmission
>> between the client and the server are fully protected from
>> eavesdropping. Lots of sites pass credentials in the clear within SSL.
>> Get a copy of Webscarab or Paros Proxy, run it and look at your own
>> credentials to sites like amazon, yahoo, etc. Even if the web site is
>> using 401 authentication, look at the authentication header. It it is
>> base64, then it's not encrypted in anyway, just encoded.
>>
>> The biggest problem with SSL is man in the middle attacks. As part of
>> the client side SSL verification, the browser checks to see if the
>> signing certificate is stored in your certificate store and therefore
>> trusted. Verisign's signing certificates are in every browser, so any
>> certificate signed by them is "trusted." If you receive a certificate
>> that is not signed by a CA whose certificate is trusted by your
>> browsers certificate store, that is when you get a pop-up saying the
>> certificate is untrusted.
>>
>> You can use self-signed certificates, which is when you generate a SSL
>> certificate and sign it at the same time. But to be trusted by the
>> browser, you have to import the self-signed certificate into your
>> browser manually. If you can distribute the certificate securely
>> between your users, then that certificate is just as good as any
>> other.
>>
>> The problem with self-signed certificates is scale. The more people
>> you add to the system, the more difficult it becomes to distribute the
>> certificate. It's a management problem.
>>
>> > Would this also show that the passwords are being stored in clear-text and
>> > not encrypted with a salt value in the db?
>>
>> Not necessarily. The application may or may not encrypt the password
>> once it receives it. So when an account is created, hash the users
>> password and then store it. When a user decides to login, take the
>> plain text password over SSL, hash it, then compare the submitted,
>> hashed password to the one stored. If they match, you are good to go.
>> You would have to check with who ever developed your app to see what
>> they did with user credentials.
>>
>> ----------------------------------------------------------------------------
>> 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
>>
>
>
> ----------------------------------------------------------------------------
> 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
>
>

----------------------------------------------------------------------------
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20080616/fa44f53e/attachment.html>


More information about the websecurity mailing list