Login on every page requires SSL on all pages

Question

Our website has a login form that shows up in the header on every page on the website. This is what my boss wants however we need to get PCI compliant and it says any sensitive form (login/password) requires SSL. So does that mean the entire website has to be running under SSL while a user is not logged in?

Another question related to that, we have third party security software scanning and testing our site and it sends HTTP post to the login form on all the pages and reports it is unsecured because it submit's it under HTTP. I am wondering how a company like say Godaddy does it because they have a login/password on their homepage yet I can access it via HTTP and submit my login information just fine. By that logic they are not secure because it allows me to do that right? I feel like I am missing something but not sure what.

-EDIT- Some information that came from the security site:

Description A vulnerability exists that allows an attacker to harvest sensitive information (login credentials, etc) that are thought to be SSLsecured.

Specifically, a form was found on an HTTP (unencrypted) page that sends information to an HTTPS (encrypted) page. An attacker could leverage cache poisoning (DNS/DHCP/ARP/etc) or another vulnerability (e.g. XSS) to cause the HTTP page to send information to an attacker-controlled website instead of the legitimate HTTPS site.

Furthermore, toolkits exist to automate the process of harvesting such credentials, connecting to the legitimate HTTPS site and establishing the attacker as a transparent proxy between the victim and the legitimate host where the attacker sees all information in cleartext (including login credentials, etc).

Victim<---------HTTP--------->Attacker<---------HTTPS--------->Legitimate Site

CVSS Score 2.1

Solution

Do not allow any information you want SSL secured to originate from an unsecured page.

Answer 1

Technically, only the target of the form needs to be a SSL protected page for the submission to be encrypted. I saw this done at a previous job where we had a login form in the header.

HOWEVER

By doing this you are losing the clarity that we've been telling users to look for. Users are instructed to look to the URL bar to see if the website is using an encrypted connection for their information. By having the page not delivered via SSL, users may mistakenly believe that their form (username and password) isn't encrypted either.

Furthermore, as pointed out by Craig below, if the page you're submitting from isn't encrypted, you cannot assert that the page has not been intercepted and altered. That familiar form that you know has always submitted to a HTTPS url may have been intercepted and altered before it was rendered.

Your best bet is to just offer SSL on all pages if you insist on having the login form in the header. SSL is relatively cheap to implement as far as server resources, and it gives your users the extra security they deserve.

Answer 2

In order to be secure, the form must be hosted on a page delivered via SSL. Without SSL, the end user has no way of knowing that the form data will be delivered where they expect it to be delivered -- the action of the form could have been tampered with by an attacker while they were downloading the page, or they could be looking at a fake version of your site produced by a server they were redirected to via a DNS hijacking attack, or similar.

That said, while I'm not a PCI compliance expert, I was under the impression that the PCI regulations only apply to the transmission of cardholder data, and that therefore only payment-related forms need to be protected. Unless you are holding users' payment details permanently and allowing them to generate additional transactions without confirming that they hold the card, login forms should not be required to be PCI compliant.

Answer 3

Section 6.3 (a) of the Self-Assessment Questionnaire D (https://www.pcisecuritystandards.org/documents/pci_saq_d_v2.pdf) says

6.3 (a) Are software development processes based on industry standards and/or best practices?

I would say that encrypting login information is based on best practices, and not doing it definitely isn't. BTW remember that you can't force a user to submit data using SSL - that's impossible. Anyone can submit anything they want, it's up to you how to treat it.

(BTW one common gotcha is not protecting against XSS properly, if you are using ASP.NET MVC check out the @Html.AntiForgeryToken() function call. And obviously don't allow SQL injection (or command injection) but you already knew that :)

Also, section 8.4 says:

"8.4 (a) Are all passwords rendered unreadable during transmission and storage on all system components using strong cryptography?

Note that section 8 is actually talking about assigning unique IDs to each person with computer access, but you could argue that it's pretty much indicative of needing to securely encrypt passwords when logging into your website.

So depending on your assessment level (you might be A, B, C or D) you will need to encrypt login information for PCI compliance.

Oh and just because another company who claims to be PCI compliant does something strange, doesn't mean that you can too - definitely not a good guide to go by. Maybe they got special dispensation or have another compensating measure. (IMHO, be wary of anyone who tells you about what is compliant and what isn't, you need to get yourself a QSA - Qualified Security Assessor who can give you an answer).