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

["James Landis" <jcl24@xxxxxxxxxxx>]

What you are talking about sounds like digest authentication, which
requires the server to maintain the original password in cleartext
form. Sure you can increase the security of the credential in transit,
but it doesn't make sense to do that at the cost of the overall
security of the system. You don't get additional security for free.

I can't think of a risk model that would cause me to choose an
authentication scheme which is more secure on an *already encrypted
channel* over an authentication scheme which allows me to protect the
credential in storage, hence my dismissal of what you refer to as
"password obfuscation".

Given the trend of some of the discussion on this thread, I
half-expected to see someone suggest something like setting up a
secure channel inside of SSL to exchange the authentication
credentials! We don't trust SSL, so let's try to do the same thing SSL
is doing, only better!

Ultimately, security is about identifying weaknesses and strengthening
them until the difficulty of attack is higher than the value of the
data being defended. What are the weak points in the system we're
discussing? Attack the channel, attack the client, attack the server,
attack the storage; if I'm the attacker, the last thing I'm putting my
money on is the channel to be the weakest link.

-j

On Wed, Jun 18, 2008 at 1:17 PM, Oliver Lavery
<oliver@xxxxxxxxxxxxxxxxxxx> wrote:
> Which is, incidentally, why a few comments in this thread about hashing
> schemes being just a layer of obfuscation are not completely true.
>
> It's a good point that SSL can be cracked, and in fact with many servers
> configured to accept low-strength ciphers, it's not really as impossible as
> it may sound (Lots of servers are configured to still support 40 bit
> 'exportable' DES! Eeek!).
>
> When talking about protecting the password within the SSL protocol stream,
> we tend to think only in terms of MiM attacks where the attacker controls
> the keys and has full control of the stream. This is a more difficult attack
> then simply being able to intercept the encrypted traffic, possibly in
> conjunction with an SSL cipher/protocol downgrade attack.
>
> There is a non-zero risk of breaking the key to decrypt intercepted SSL as
> you point out, and if cleartext passwords are used then the attacker gains
> the password in this case, not just the rest of the plaintext protocol
> stream. While hashing alone doesn't solve the problem (as the hash becomes
> equivalent to the password) using a nonce does improve things in the case of
> a break, because the hash can not be replayed. From what I understand the
> hash itself is difficult to break in such a scheme as well, because it needs
> to be reversed; simply finding a hash collision does not yield the original
> password.
>
> Also, it isn't relevant that the attacker knows the nonce from the decrypted
> protocol stream since it's just a one-time value used as input to a hashing
> algorithm.
>
> Not to flog a dead horse, but I didn't want to see this thread conclude with
> information that is slightly misleading... There are definitely hashing
> schemes that add to the security of a password in transit.
>
> Naturally the whole web should disable SSLv2 and weak ciphers as well.
>
> Cheers,
> ~ol
> ------
> Oliver Lavery
> Security Compass
> http://www.securitycompass.com/
>
>
>
> On 18/06/08 10:49 AM, "Ivan Ristic" <ivan.ristic@xxxxxxxxx> wrote:
>
> On Tue, Jun 17, 2008 at 11:27 PM, Martin O'Neal
> <martin.oneal@xxxxxxxxxxxx> wrote:
>>
>>> 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.
>>
>> The problem is that it is not effective, just cosmetic.  It doesn't buy
>> you anything (other than a false sense of security).
>>
>> If someone has compromised your SSL, they can change whatever you put
>> inside it.  In this example, all an attacker has to do is amend the
>> javascript as it goes past and make it send the cleartext auth.
>
> I think most people tend to think about SSL as if the protection it is
> providing is permanent, that, if you're not compromised initially
> (e.g. with an MITM attack or an application vulnerability) then you
> are never going to be compromised. This is not strictly true, although
> it is virtually true for almost everyone. An encrypted SSL session can
> be stored, kept indefinitely, and broken... eventually. At that point,
> whatever was in the session, including the password, will be known to
> the attacker. I accept that this is a stretch (and a really big one),
> but purely from that point it's better to not have the password in
> clear. Of course, people that are concerned with this sort of problem
> should really look into using multi-factor authentication.
>
> For the same reason, people need to think in terms for how long
> information needs to stay protected when choosing SSL key sizes and
> ciphers.
>
>
>> Martin...
>>
>>
>>
>>
>> ----------------------------------------------------------------------------
>> 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
>
> --
> Ivan Ristic
>
> ----------------------------------------------------------------------------
> 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