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

[jfvanmeter@xxxxxxxxxxx]

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