No SSL/TLS login?

[pocketpenguin]

Is there no way to login using TLS encryption? I would have thought that would have been one of the first fixes after the break-in this fall.

Am I missing something?

As an aside, I ran a high volume website for many years for a major university and the one thing that blocked most attacks was forcing TLS/SSL connections for all pages, not just logins. With modern CPU's there was very little performance hit and we could see the script kiddie attacks bounce right off of us in our logs.

 

[arn]

Is there no way to login using TLS encryption? I would have thought that would have been one of the first fixes after the break-in this fall.

Am I missing something?

As an aside, I ran a high volume website for many years for a major university and the one thing that blocked most attacks was forcing TLS/SSL connections for all pages, not just logins. With modern CPU's there was very little performance hit and we could see the script kiddie attacks bounce right off of us in our logs.

It's a little complicated because of mixed content warnings. If any non-SSL content is included in the page, then it can pop up a scary dialog to some users.

- That can happen if anyone includes an external image via the tag.
- Or from our ad network.

Solutions to #1, include turning off the [img] tag altogether, so no one can link to an external image. Or, we would have to host a caching proxy for all images linked on the forums.

There is no quick solution to #2.

We've been researching it.

arn

 

[wrldwzrd89]

It's a little complicated because of mixed content warnings. If any non-SSL content is included in the page, then it can pop up a scary dialog to some users.

- That can happen if anyone includes an external image via the tag.
- Or from our ad network.

Solutions to #1, include turning off the [img] tag altogether, so no one can link to an external image. Or, we would have to host a caching proxy for all images linked on the forums.

There is no quick solution to #2.

We've been researching it.

arn[/QUOTE]
Thanks for this. However, images aren't considered "active" mixed content, at least by Firefox and Chrome, so they shouldn't be blocked. Scripts, on the other hand, ARE considered active, so would need to be cached. That's not a huge deal, is it? I do not know how Safari handles mixed content.

 

[arn]

Thanks for this. However, images aren't considered "active" mixed content, at least by Firefox and Chrome, so they shouldn't be blocked. Scripts, on the other hand, ARE considered active, so would need to be cached. That's not a huge deal, is it? I do not know how Safari handles mixed content.

Safari handles it silently (but the page is not shown as secure). IE is the main culprit.

arn

 

[pocketpenguin]

The login page doesn't have any ads that I can see. Couldn't you at least make that page TLS/SSL? Also, it looks like even the little "instant" login form could at least be directed to a TLS URL.

Actually, you really only need the login form to simply post to an SSL/TLS URL, the forms themselves can be served up unencrypted. The post login page that redirects can still point at non-ssl as well. The user would see a quick switch to ssl then back to plaintext, but there shouldn't be any warnings.

It isn't critical for me as my Mac rumors password is very different from every one of my other passwords, but others may not be so wise as me .

 

[arn]

The login page doesn't have any ads that I can see. Couldn't you at least make that page TLS/SSL? Also, it looks like even the little "instant" login form could at least be directed to a TLS URL.

Actually, you really only need the login form to simply post to an SSL/TLS URL, the forms themselves can be served up unencrypted. The post login page that redirects can still point at non-ssl as well. The user would see a quick switch to ssl then back to plaintext, but there shouldn't be any warnings.

It isn't critical for me as my Mac rumors password is very different from every one of my other passwords, but others may not be so wise as me .

Serving the login form alone as TLS/SSL doesn't help that much. That might protect your password submission (which is MD5'd before it get submitted), but if the rest of the pages aren't SSL, then they can still grab your session cookie.

arn

 

[IvanX]

Actually, you really only need the login form to simply post to an SSL/TLS URL, the forms themselves can be served up unencrypted. The post login page that redirects can still point at non-ssl as well. The user would see a quick switch to ssl then back to plaintext, but there shouldn't be any warnings.

Serving the form unencrypted is a bad security practice and exposes it to Mad in the Middle attack. If the login itself can be done of HTTPS, serving the form over a secure connection should not pose much of a challenge.

Serving the login form alone as TLS/SSL doesn't help that much. That might protect your password submission (which is MD5'd before it get submitted), but if the rest of the pages aren't SSL, then they can still grab your session cookie.

Arn, MD5 is a weak hashing algorithm and is easy to reverse-engineer. Saying that a password gets MD5'd before submission does not alleviate my security concerns.

 

[arn]

Arn, MD5 is a weak hashing algorithm and is easy to reverse-engineer. Saying that a password gets MD5'd before submission does not alleviate my security concerns.

It wasn't meant to, I was just describing the system as it stands.

arn

 

[IvanX]

It wasn't meant to, I was just describing the system as it stands.

arn

Fair enough, but the system as it stands is bad and insecure. What, if any, are the plans to improve the situation?

 

[LaidBack]

It looks like Google AdSense does support placing ads in https web pages. They say the bids on your ad space will decrease because only the SSL compliant ads will be allowed through. I'm not sure how bad the drop in revenue might be.

 

[arn]

It looks like Google AdSense does support placing ads in https web pages. They say the bids on your ad space will decrease because only the SSL compliant ads will be allowed through. I'm not sure how bad the drop in revenue might be.

Adsense isn't our only ad network.

arn

 

[redheeler]

Serving the login form alone as TLS/SSL doesn't help that much. That might protect your password submission (which is MD5'd before it get submitted), but if the rest of the pages aren't SSL, then they can still grab your session cookie.

Being able to capture a temporary session cookie is still less severe than being able to capture a password, one that may even be used on multiple sites.