Next pet peeve to go after: sites that POST logins to https form actions from HTML pages served over insecure connections.
Six Months Later: Seven Major Websites that Send Passwords Unprotected
11–20 of 29 posts
Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected
#12When ProjectLocker was accused of storing passwords in plaintext, they responded by saying: "You can't verify this for ProjectLocker or any other website without access to their backend systems." http://superuser.com/questions/46810/should-i-be-concerned-i... Is that incorrect? If not, then I wonder how the author of this article can be so sure of his findings.
I believe the article is referring to the plaintext transmission of credentials (your browser --> their server) which can be intercepted, rather than the plaintext storage of credentials (their server --> their database). Both are problematic.
[deleted]
Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected
#13Next pet peeve to go after: sites that POST logins to https form actions from HTML pages served over insecure connections.
I'm going to ask for an example because I can't believe any business entity actually still does this.
Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected
#14Next pet peeve to go after: sites that POST logins to https form actions from HTML pages served over insecure connections.
I'm going to ask for an example because I can't believe any business entity actually still does this.
What are you talking about? HTTP-to-HTTPS post is perfectly fine w/r/t sending info securely. It's especially useful for performance if your login is on a page where less than 10% of your users are expected to login.
Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected
#15Earlier quoted context omitted.
I'm going to ask for an example because I can't believe any business entity actually still does this.
What are you talking about? HTTP-to-HTTPS post is perfectly fine w/r/t sending info securely. It's especially useful for performance if your login is on a page where less than 10% of your users are expected to login.
If you start considering active man-in-the-middle attacks, someone can modify the HTTP page that hosts the login form to, for example, also send the password somewhere else.
For defending against passive MITM, you're right (as far as I know) that HTTP-to-HTTPS is okay.
Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected
#16I wish someone would create a browser extension that would warn the user if a password field is submitted unencrypted and ask if they want to proceed.
Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected
#17I wish someone would create a browser extension that would warn the user if a password field is submitted unencrypted and ask if they want to proceed.
My Unencrypted Password Warning extension for Chrome does exactly that. https://chrome.google.com/extensions/detail/mjpinemnkjlppmem...
SSLPasswdWarning for Firefox is similar. https://addons.mozilla.org/en-US/firefox/addon/11894/
Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected
#18Earlier quoted context omitted.
I'm going to ask for an example because I can't believe any business entity actually still does this.
What are you talking about? HTTP-to-HTTPS post is perfectly fine w/r/t sending info securely. It's especially useful for performance if your login is on a page where less than 10% of your users are expected to login.
Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected
#19Next pet peeve to go after: sites that POST logins to https form actions from HTML pages served over insecure connections.
I'm going to ask for an example because I can't believe any business entity actually still does this.
discover.com -- there's a "log in" link at the top that takes you to a secure page, though.
Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected
#20Earlier quoted context omitted.
I'm going to ask for an example because I can't believe any business entity actually still does this.
What are you talking about? HTTP-to-HTTPS post is perfectly fine w/r/t sending info securely. It's especially useful for performance if your login is on a page where less than 10% of your users are expected to login.
No. Attackers will just modify the (insecure) login form so that it posts somewhere insecure, and then relay the creds to the secure handler without you noticing. You can't safely serve a secure login form from an insecure page.