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

James Landis jcl24 at cornell.edu
Mon Jun 16 15:37:09 EDT 2008


If you compare a hash stored in the DB directly with a hash sent by
the client, then your hash has become your password. The situation you
describe is virtually identical to just sending a cleartext password,
with the exception that the hash is probably harder to remember than a
typical user's password. Doesn't really make much difference given the
attack vector anyway.

So, no, not joking.

To Oliver's point, I would argue that it is actually a large
disadvantage to do it this way, because now you've lost protection
against attacks against the database. If an attacker can pull a value
from the password store, they can replay it directly to authenticate.

Are people on this list seriously arguing that it's wise to perform
hashing on the client side only?

-j

On Mon, Jun 16, 2008 at 12:02 PM, Michele Orru'
<minchia.lusardu at gmail.com> wrote:
>
>> If you hash the password before you send it to the server, how do you
>> validate it when it gets there?
>>
>
> are we joking here :) ???
>
> you obviously must hash the password BEFORE it must be transmitted to the
> server, otherwise where do you want to has it??? on the server itself???
>
> You hash the password before credentials are sent to the server, then you
> compare the hashed password (and eventually the username) with the the hash
> you have on the DB, if they are not salted.
>
> Michele
>>
>> 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
>>
>>
>>
>
>

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



More information about the websecurity mailing list