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

Smolsky, Shawn J shawn.j.smolsky at lmco.com
Mon Jun 16 15:16:44 EDT 2008


When authenticating over SSL using basic authenticate the password is
base64 encoded.  Effectively its clear text over SSL.

Going beyond the threats against SSL MITM attacks.  The threat related
to sending a UserID/PW pair to an untrusted server need to be
considered.
If you use the UserID/PW pair to access other sites, a very common
practice, a malicious or possibly compromised web site can harvest your
credentials and an attacker can assume your identity on any of the
websites.

Single-Sign-On solutions can help mitigate this threat.   With SSO, you
only send your UserID/PW to a, hopefully, trusted server where you are
issued a SSO token that your browser presents to a member web site.    

Within Intranets you have the same problem.   How do you know that your
UserID/PW are not being harvested by an untrusted entity with inside
access?  If you present a SSO token or a Kerberos ticket to an Intranet
site the attacker cannot harvest your UserID/PW pair.  

Shawn


-----Original Message-----
From: jfvanmeter at comcast.net [mailto:jfvanmeter at comcast.net] 
Sent: Monday, June 16, 2008 12:55 PM
To: websecurity at webappsec.org
Subject: Re: [WEB SECURITY] username & pw in clear-text through SSL
considered safe?

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