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


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

  • Is it the submission of the form that needs to be under SSL? or the presentation of the form also?
    – user40980
    Mar 13, 2013 at 17:22
  • @MichaelT No idea the security site does not specify.
    – Danny
    Mar 13, 2013 at 17:24
  • That is something that you likely need to clarify with the PCI auditors then. You may wish to consider if should all web traffic be encrypted.
    – user40980
    Mar 13, 2013 at 17:28
  • @MichaelT Now that I think about it, technically wouldn't submission only need it because nothing is "sent" via presentation alone. However if that security software sends posts directly to a page/form bypassing the actual browser/website rules wouldn't it bypass my "submitting" to https pages anyway (thus making all form posts to https irrelevant)?
    – Danny
    Mar 13, 2013 at 17:32
  • FWIW some XSS vectors would allow the attacker to send information to an attacker-controlled site even if the page with the login form is only sent over HTTPS. Mar 20, 2013 at 9:42

3 Answers 3


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.


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.

  • Good point on users not knowing it is secure even if it is posting via https with actual form on http.
    – Danny
    Mar 13, 2013 at 18:03
  • I wish more site designers would take this advice! I've encountered exactly what you describe before - forms that submit securely, but you cant tell from looking at the page that its doing so. Mar 13, 2013 at 18:59
  • 1
    The other risk of a non-encrypted form is that a man-in-the-middle attack can easily alter the form without any indication to the user that the form has been changed (for instance changing where the form is submitted). SSL on the form would make this a harder vector.
    – Craig
    Mar 13, 2013 at 21:21
  • Another fair point, Craig. If the page with the form isn't encrypted, you have no justifiable proof that the page hasn't been tampered with to begin with. That form that you know has always submitted to a HTTPS url may have been intercepted and altered before it was rendered.
    – Craige
    Mar 13, 2013 at 22:54
  • Asked and answered on StackOverflow over two years ago: stackoverflow.com/questions/4309199/must-logins-be-a-https-page Mar 14, 2013 at 0:07

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.

  • Strictly speaking you are correct. Only card holder data (CCV, card number and expiry date) needs to be encrypted. If you are holding cc details permanently that's a whole new ball game and your level of compliance will shoot through the roof. Avoid that at every opportunity :)
    – Rocklan
    Mar 14, 2013 at 1:53

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.