14

slate.com's paid membership program collects credit card info inside an HTTPS iframe over plain HTTP . The HTTPS url is https://my.slate.com/subscriptions/manage/. Screenshot of credit card form

In an article, they claim this is safe:

When credit card data are submitted, they are sent to a third-party payment provider and your credit card data are not stored by Slate itself. Your credit card data are always sent over HTTPS. I assure you that entering your credit card information at Slate is a very safe thing to do and I hope that you enjoy Slate Plus.

However, they also take username/password over plain HTTP so I am skeptical. screenshot of username and password form

Could someone tell me if it is possible to securely get credit card information in the way they have described?

Improve this question
6
  • 1
    yes, the info transit is safe.
    – dandavis
    Commented Sep 9, 2016 at 20:00
  • 19
    More accurately, the info transit is safe against passive attacks, but not MITM.
    – 700 Software
    Commented Sep 9, 2016 at 20:21
  • 5
    I wonder if this will be detected by Chrome's new warning for http pages that request credit card information... security.googleblog.com/2016/09/… The password form certainly will...
    – Ajedi32
    Commented Sep 9, 2016 at 20:24
  • 2
    Your username/password are NOT sent over plain HTTP. Their homepage just uses HTTP, but the action of the form is https://profile.slate.com/widget/traditional_signin.jsonp, so when you submit the login form your username and password are sent encrypted to profile.slate.com.
    – Mustard
    Commented Sep 10, 2016 at 1:13
  • 1
    Dupe security.stackexchange.com/questions/133983/… and near dupe security.stackexchange.com/questions/31813/…
    – dave_thompson_085
    Commented Sep 10, 2016 at 9:35

4 Answers 4

Reset to default
8

Caveat, IANAQSA

Update: Slate isn't actually a SAQ A - they aren't using iframes, and they're submitting card info to, for example, https://profile.slate.com/widget/traditional_register.jsonp... most of what's below still applies in spirit though.

Could someone tell me if it is possible to securely get credit card information in the way they have described?

Yes, it is possible. However, there is some implied responsibility shifted to you to check that your connection is secure and that the payment site you go to is a legitimate payment processor.

That said, this configuration is both acceptable (as per PCI) and mildly inadvisable (per security best practices).

A reading of SAQ A - which applies to merchants who outsource all card handling to their processor via an iframe - suggests that this is a legal configuration. Note that it does not place any explicit requirements on the pages containing the payment page (iframe) enclosing the Service Provider's payment page(s); just the SP's page(s) come from the SP and the SP is PCI DSS compliant (which implies encryption):

SAQ A Eligibility Requirements

Now, that being said, there are issues such as MITM that make the lack of outer encryption by Slate inadvisable. Many organizations have fought their way over this hump and eventually decided that encrypting everything on their site was preferable to dealing with the perception of insecurity. But it usually takes time and complaints before they organizations get there. So feel free to complain about this.

Improve this answer
39

What they are doing is certainly better than not doing https at all. However, their external http page is more susceptible to attacks like Man-In-The-Middle that could cause the 'secure' iFrame to be replaced or compromised in other ways. This method makes it hard for end users to make their own determinations, too - the lock icon is helpful and browsers are working hard to teach the users how to determine if a site is safe.

Given the minimal cost of https now and given how much additional security it offers in general, there's no reason for them to defend this - they should just fix it and go https everywhere.

Improve this answer
3
  • Paypal has this to say about using Secure IFrames in insecure websites: "There's lower risk compared to solutions where all the payment information is being collected directly on your website but we still have to make sure the store website itself is secure." paypal-community.com/t5/About-Products-Archive/…
    – Kevin Fee
    Commented Sep 9, 2016 at 20:58
  • @KevinFee, typically, yes, it is often nice for security (and compliance) if someone else can keep the payment info. ....But it's not really necessary. That's an implementation detail. You certainly could have a secure site that accepts its own payment info. It's a question of resources and such. In contrast, HTTPS is a requirement for trust. Maybe a MITM puts the payment iframe as evil.org.
    – Paul Draper
    Commented Sep 11, 2016 at 4:25
  • 1
    @PaulDraper Correct. That's why the Paypal says that "we still have to make sure the store website itself is secure." If it's not secure, then a MitM can alter the secure iframe's target or inject some key logging javascript or whatever. Point being, even Paypal, who offers secure, embedded iframes, says you shouldn't rely on that feature for your all of your security.
    – Kevin Fee
    Commented Sep 12, 2016 at 15:05
7

When you encrypt the whole site, you are protected against passive attackes, who only read the traffic without modifying it, as well as against active attackers, who will actively try to obtain information from you and to bypass security measures. By using an encrypted iframe, you are still protected against passive attackers, because the payment data is encrypted in transit. However, because the original page is unencrypted, an active attacker (aka a man in the middle) can just replace the secure iframe with one pointing to their own site, which they can make look identical to the one that is supposed to be there, or just force the iframe to load and submit over an unsecured connection (provided that it's not using HSTS to force you to load it over HTTPS). They are then able to capture everything that you enter, including your payment details. Moreover, there are no browser notices to inform you that what you enter is being intercepted, because iframes don't have protocol or origin indicators. That means that the only way for you to detect an attack like this would be to inspect element on the form, which almost nobody would do.

Using a HTTPS iframe is far better than nothing, but it would be wrong to say that is secure. Personally, I would never enter payment details on a page that doesn't have https in the URL bar, but when on a trusted connection (aka not public wifi), the risk is very small.

Improve this answer
3
  • "There are two threats that HTTPS is intended to protect against - passive attackers and active attackers." Perhaps I'm misunderstanding something, but isn't this entire notion redundant? What other attacks are there, aside from "passive" and "active"? The two categories are polar opposites and between them cover the entire spectrum by definition, no?
    – Lightness Races in Orbit
    Commented Sep 11, 2016 at 10:36
  • @LightnessRacesinOrbit I included that because the risks from active and passive attackers are very different in this case, and I then handled each of them in turn. I have edited the post to clear it up, because I agree that the sentence in its original form didn't really add much.
    – JackW
    Commented Sep 11, 2016 at 11:59
  • Oh I see yep okay.
    – Lightness Races in Orbit
    Commented Sep 11, 2016 at 15:56
0

Since slate.com is redirecting to (still) slate.com, while it's a protocol switch from http to https, it doesn't qualify slate.com as having no cardholder data environment. Yes, there is the increased security (assuming TLS 1.2, for example) between the user's browser and slate.com, but that's about it.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .