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

Michele Orru' minchia.lusardu at gmail.com
Mon Jun 16 13:41:49 EDT 2008


I'm completely with you man...

I (we) think that the delay in server reply if it must check an hashed 
password is not too big.

I don't care if Amazon or Yahoo! don't implement them...VPN too are 
theoretically secure, btu when Yersinia and the various kind of attacks 
to Cisco devices were out, every security people was scared...

Do what big enterprises do is not what I follow generally.

anyway...if banks don't hash password or encrypt cards, bank as 
ecommerce websites, that's the main problem when some scriptkiddie send 
an exploit, take access to the DB and grab everything without the need 
to bruteforce anything....

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



More information about the websecurity mailing list