Ian G wrote:
Ka-Ping Yee wrote:
It's an assumption of Gervase's current anti-phishing proposal that everything starts with SSL. Indeed, sites really should have no business slinging around passwords and credit card numbers in cleartext -- it's pretty irresponsible. Here are a few thoughts on how we might encourage the use of SSL and move towards a world in which users come to expect it.
1. As mentioned in my last message, a transient warning could
appear when the user is typing text into a form on an unencrypted
site. The warning would appear below the text field while the
focus is in the field, and disappear automatically (no extra user
effort needed) when the focus moves elsewhere. The warning could
say something like "The text you enter here will be visible to the
public" if the connection is unencrypted.
Good one.
2. Currently, typing in password fields shows a bunch of stars to
give the impression that what you type is secret. Well, if we
are really serious about the necessity of SSL for keeping passwords
secret, then why should we give that impression when there's no
encryption? Suppose that, if there's no SSL, password fields
*don't* blank out the text with stars -- they just behave like
normal visible text fields. That would be instant, unmistakable
feedback, and i think it would be a pretty intuitive way to show
that the password isn't being kept secret.
The reason for the stars is based on the old Unix security threat of students reading over shoulders in terminal labs. 20 years ago this was a reality, something that was done every day in the labs...
But, in practice, it would be more secure these days to show the password in the clear all the time, as there is nobody peeking over the shoulder most of the time in today's computing, and the ability to remember the password is far more important than any such.
I would have to disagree with the implementation.
with unmasked passwords at all times you ould also tell users that no login has any security.
non-ssl login unmasked, good idea.
ssl login the option to mask or not, depending on if user makes it a trusted site.
only trusted unmask the password.
But, turning off the stars is a non-starter, one would have to convince all the people who code and use these things of where they came from, and who's got the time to do that?
OTOH, your suggestion has some merit ... it certainly isn't going to reduce security markedly, and may result in a big hint. Worth experimenting with.
3. Consider these three cases: (a) Unencrypted connection. (b) SSL connection with a self-signed certificate. (c) SSL connection with a certificate signed by a known CA.
Of these three options, (a) is the riskiest context in which to submit an HTML form; (b) and (c) are safer. (If you trust centralized CAs, then you might also believe that (c) is safer than (b). I *don't* trust the CAs, but that is an issue for a separate thread. In any case, i hope we can agree that (b) is still safer than (a).)
Compare this ranking of risk to the user experience. (b) is heavily penalized by a pop-up warning, but (a) and (c) are not penalized at all. It may be worth thinking about how to bring these user-experience costs more in line with the actual risks, so that sites are encouraged to use encryption without being required to pay the extortion^H^H^H^H^H^H^H^H^Hfees demanded by centralized CAs.
since most CA will issue certificate of your site and security based solely on the fact that you paid for the cert, I wouls also have to agree that CA issued does not meant trusted.
I would disagree that a self issued cert makes you more trusted.
the issuing of certs needs to be re-examined, and some sort of viable system worked out to protect end users from fraudulent use.
far beyond the scope of any one development team, though maybe getting security teams from most development groups to work together on a sane security standard, with better control over certificates issued.
( control as in verified identity and, as much as possible, good business peractices )
4. What if the browser chose SSL by default first? As in, when
you type "paypal.com" in the location bar, the browser *first*
tries https://paypal.com/. If that fails, then it falls back
to http://paypal.com/. In a world where self-signed certificates
aren't penalized with a big scary warning, this might go a long
way toward encouraging more widespread use of SSL.
Perhaps. I think an alternate is to perhaps probe the SSL port and perhaps pop up a little upgrade logo if a connection can be established ...
If the SSL connection were tried first, it would slow most browsing down a lot. SSL takes order of many seconds to connect and start up in the first instance. Putting this in front of every browsing attempt isn't going to make for happy campers.
iang
_______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security