【问题标题】:Can I use JS encryption instead of SSL for credit card payments?我可以使用 JS 加密而不是 SSL 进行信用卡支付吗?
【发布时间】:2009-11-17 16:52:22
【问题描述】:

我有一个 HTML 表单,人们可以在我的网站上进行付款。除了使用 SSL,我想知道是否可以使用 JS 库来加密信用卡信息并以明文但加密的形式将其发送到服务器,而不是服务器将其解密。我发现了几个这样做的库,它们基本上是从服务器请求密钥对,对其进行加密并将其发送到加密的服务器。这些是我找到的:

http://www.jcryption.org/

http://www.hanewin.net/encrypt/

http://www.vincentcheung.ca/jsencryption/

信用卡支付是否足够安全?我知道会话没有加密,但唯一真正重要的是信用卡信息,对吧?

【问题讨论】:

  • 出于好奇,既然已经有了标准解决方案,为什么还要尝试这样做?
  • Ggolo 这是一个坏主意!!!!
  • 帮自己一个忙,使用您所在地区现有的商业信用卡支付处理商之一,他们已经解决了这些问题。
  • 我收藏了这个,只是因为 Ggolo 坚持认为它会对每个人的答案都有效,这太有趣了,不能输。
  • 这最终将登陆 thedailywtf.com

标签: javascript security encryption ssl payment


【解决方案1】:

这在任何方面、形状或形式上都不安全。

中间人可以用自己的公钥替换公钥。你用“referer”或除 SSL 之外的任何东西设计的任何组合都不会恢复这个残暴方案的安全性。

当您可以免费获得边缘证书,或者几乎一无所有的体面证书时,您为什么要乱用人们的信用卡号码?由于未能在传输过程中确保信用卡号,您违反了 PCI,并且可能使自己承担比获取和使用证书的成本高出许多倍的责任。或者您只是认为这是持卡人的问题?

您不能完全在带内引导安全通道。您需要一些安全介质来交换密钥材料。这可能是认证机构公钥的分发。或者也许面对面会面以共享密钥。

无论采用何种方案,您都不能从不安全中建立安全。

【讨论】:

  • 中间人甚至不必用自己的公钥替换公钥。他可以用function encrypt(str) { return str; }替换javascript“加密”函数。
  • “你不能从不安全中建立安全”...我不同意(SSL 是建立在 TCP 普通连接之上的)。但是 - 其余的 - 我完全同意。
  • Helios,关键是你不能在没有首先安全地获得一些公钥的情况下创建安全的 SSL 连接。也就是说,你必须有一个安全的通道来获取 CA 证书;如果你通过那个普通的 TCP 连接得到它,它可能会被欺骗,一切的真实性都取决于它。
【解决方案2】:

没有。不要使用 JavaScript 来保护信用卡付款。

如果您这样做了,那么有人复制您的所有源代码,然后毒害 DNS 缓存甚至设置网络钓鱼站点并将您的用户的付款发送到他们的银行帐户,这将是微不足道的。

这是一个场景。

  1. 您完成了您的网站 example.com,并将所有内容都放到了网上。网站启动,耶。您已使用 javascript 来保护您的信用卡支付系统。

  2. 一个名叫 Nefarious Hacker 的人注意到您没有使用经过验证的方法来保护重要的个人信息,因此他下载了您的所有 HTML、JS 和 CSS。

  3. N。黑客剥离了所有基于 js 的加密,只留下了表单。然后他在 evil-example.com 上托管它。它看起来完全像您的网站,并且行为与您的网站完全一样。除了它向 N Hacker 的数据库提交未加密的信用卡数据。

  4. N。黑客会发送一些钓鱼邮件,将用户指向 evil-example.com。一些用户相信这个邪恶的网站是有效的,提交了付款。他们的信用卡现在被盗了。

  5. N Hacker 能够成功毒化 DNS 缓存,因此一些访问 example.com 的用户会被 evil-example.com 提供服务。他们没有理由相信该网站是假的(网址是他们所期望的),因此他们提交了付款。他们的卡现在被盗了。

如果您拥有 SSL 证书,用户会立即知道 evil-example.com 不受信任,或者冒充 example.com 的 evil-example.com 是假的。

(我会把它放大,这样很明显)

底线 - javascript 不够安全,无法进行 CC 付款。

【讨论】:

  • SSL 不能完全解决网络钓鱼问题。如果有人很容易相信一封假电子邮件,那么他们可能不会注意到“锁定”图标的缺失。
【解决方案3】:

你可以这样做,但不要这样做。它需要客户端的 javascript,当您获得加密部分时,您可能会丢失 SSL 的另一部分,即身份验证。使用您的方法,中间人攻击是可能的,而使用 SSL 证书的可能性要小得多。

【讨论】:

  • SSL 证书包含有关颁发者和颁发者的信息。这确保了 foo.com 的证书实际上是 foo.com 的证书,而不是 evilfoo.com 的证书。哦, evilfoo.com 上的那些 haXor,我鄙视他们。
  • 如果攻击者正在查询您的服务器,他们通过任何他们喜欢的Referer 行绝对是微不足道的。 HTTP Referer 从不对任何事情都是足够的安全机制。
  • @Ggolo - 这就是为什么您必须为 签名 证书付费。当威瑞信(或任何人)签署您的证书时,他们会努力确认您就是您所说的那个人。他们的用户信任 Verisign,因此当他们获得由 Verisign 签名的 ggolo.com 证书时,他们信任它。假装的人应该发现很难获得由受信任的机构签署的证书。这就是为什么您的浏览器在找到未签名的证书时抱怨如此之多的原因。任何人都可以为他们喜欢的任何网站创建未签名的证书。
  • @Ggolo - 中间人攻击的一个普通人是通过 DNS 中毒。有人发现 ISP 的 DNS 服务器存在安全问题,并将其重新配置为为域提供错误的 IP 地址。所以用户浏览说,www.amazon.com 是发送到破解者的服务器。这需要 ISP 出错,并且根本不需要访问 amazon.com 上的任何系统。
  • 许多 ADSL 路由器也容易受到攻击,让攻击者告诉它使用什么 DNS 服务器。
【解决方案4】:

您可以使用 JS 加密并选择忽略它不安全的事实。

您会遇到的问题是人们不想在没有 SSL 连接的页面上输入他们的信用卡详细信息。不仅仅是技术人员;很多非技术用户都知道在输入信用卡号之前要查找挂锁,即使他们不知道 TLS 或 SSL 是什么。

【讨论】:

  • 这并不能消除他们的怀疑。事实上,如果我看到它并且没有 SSL 图标,我会认为它是一个诈骗网站 - 网络钓鱼网站通常会在没有 SSL 的情况下声明它们。
  • 我仍然不相信你。如果我看到一个网站询问信用卡详细信息,而该网站并没有努力整理出证书,我总是认为这是某种骗局。
  • 如何阻止中间人替换自己的公钥?
  • 戴夫:我不久前读过一篇论文,他们选择挂锁作为网站图标并侥幸成功。您会惊讶地发现,实际上很少有用户会寻找安全标志。
  • @Johannes Rössel - 遗憾的是你是对的。虽然有些人知道要寻找什么,但我敢肯定,如果有人问得好,很多人会通过电子邮件发送他们的信用卡详细信息。如果没有一些人会上当,人们就不会为网络钓鱼而烦恼。
【解决方案5】:

一点也不。请记住,SSL 还允许客户端(浏览器)验证远程方(您的服务器)的真实性。您必须确保您从中获取密钥的服务器实际上是您想要从中获取密钥的服务器,而不是完全不同的机器。 (参见Man in the middle)

【讨论】:

  • 我不需要 SSL 连接来验证远程方的真实性。我可以查看referer等等。
  • 如果黑客劫持了用户并将他们完全指向另一台服务器,这对您没有任何帮助。
  • Ggolo:当然,您可以在 JavaScript 中推出自己的 SSL 替代品,但见鬼,这有什么意义呢?已经有一个协议允许(a)远程方的身份验证和(b)它们之间的流量加密。如果您只能依靠其他人已经提供的东西,为什么要重新做呢?或者,套用 Bruce Schneier 的话说:“任何使用自己的加密货币的人要么是天才,要么是傻瓜。鉴于我们物种的天才/傻瓜比例,胜算不大。”
  • HTTP Referer 作为一种安全措施:搞笑。 HTTP Referer 作为保护我的信用卡详细信息的安全措施:太可怕了。
【解决方案6】:

您可能会遇到的潜在法律问题是方式不值得避免 SSL 费用。

【讨论】:

  • +1 这个轻率的方案非常不安全,除了技术原因之外,它还违反了 PCI-SIG 规则,几乎肯定违反了您的商家帐户的规则。
【解决方案7】:

如果用户在浏览器中禁用 JavaScript 会怎样?我会说,安全起见并坚持使用 SSL。

【讨论】:

  • 我可以有一张支票,禁止没有 javascript 的人付款。
  • @Ggolo 这似乎是一个糟糕的收入模式。抛弃非常好的客户?
  • 我是一个“书呆子”,我花了很多钱。
  • 哇,你是一个真正的魅力,你不是“Ggolo”吗?使用屏幕阅读器的残疾用户怎么办?我猜你也不想要他们的钱,对吧?
  • 残障用户如果有支持 JS 的屏幕阅读器,则可以使用 JS。许多人没有。同样,电子商务解决方案需要 JS 会损失您的收入。在 GoDaddy,SSL 证书只需 13 美元。
【解决方案8】:

@stimms 很好地解释了为什么这是危险的 - SSL 同时进行加密 和 确保加密的数据也可以到达正确的位置。最重要的是,浏览器对 SSL 和非 SSL 缓存的处理方式不同 - 如果您不通过 SSL 提供这些页面,用户的浏览器可能会将重要信息以明文形式存储在用户的计算机上。

即使完全安全,这也不是一个好主意。许多用户已经被 IT 人员、精通技术的亲戚等灌输了“为电子商务寻找锁定图标”的规则。Spring 只需 25 美元即可获得 SSL 证书。

编辑: 另一个潜在问题 - 大多数信用卡公司需要通过 SSL 传输。仅使用 JS 这样做很可能会违反您的商家协议 - 罚款和终止可能会随之而来。

【讨论】:

  • 25 美元在哪里可以获得 SSL 证书?
  • 实际上,GoDaddy 似乎以 13 美元的价格出售它们 - godaddy.com/Compare/gdcompare_ssl.aspx
  • 嗯,看看那个。我对 SSL 证书价格的概念已经过时了 5 年。
【解决方案9】:

Ggolo,说真的,伙计,不要这样做。任何传递信用卡详细信息的网站都会引起黑客的注意,如果他们足够努力,他们会在你的手动方法中发现一些错误或漏洞。只需准备好 SSL 证书。

【讨论】:

    【解决方案10】:

    虽然从技术上讲,在 JS 中加密的数据类似于使用真实证书对其进行加密,但我认为您在这里缺少一个关键元素;相信。使用来自受信任提供商的真实 SSL 证书时,您正在建立一个信任圈:

    • 客户信任微软
    • Microsoft 信任 GoDaddy/Verisign/whoever(通过 Windows 或任何其他附带根证书的 Web 浏览器)
    • GoDaddy/威瑞信/信任您的人(因为您从他们那里购买了证书,他们会验证您的身份)
    • Web 浏览器中出现绿灯和锁,用户可以根据需要自行检查证书,这反过来意味着客户信任您。

    如果您只有一个不安全的网站,并带有“您的数据是安全的,请忽略您的网络浏览器告诉您的内容”这样的话,那么客户就不信任您了。

    (如果他们这样做了,请将他们的信息转发给我,我有一个桥梁可以卖给他们......)

    此外,值得一提的是,主要 CC 公司都有关于如何处理和存储信用卡信息的标准。谷歌“PCI DSS”了解详情,或:https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

    【讨论】:

      【解决方案11】:

      除了其他人提出的观点之外,SSL 是一个既定标准,每个 Web 浏览器都内置了对该标准的支持。浏览器 GUI 以某种方式发生变化,让我知道我正在使用安全连接,如果我愿意,我可以检查证书详细信息。

      浏览器不支持您提出的任何本土方案。

      【讨论】:

        【解决方案12】:

        PCI DSS 标准现在是一项要求,因此即使您可以使用 JS 执行此操作(如本页已广泛讨论的那样 - 您不能),您仍然不会获得 PCI 批准,因此您不会不允许使用它。

        如果您绝对不想购买 SSL 证书,请查看您的支付提供商服务。他们中的大多数提供第三方托管解决方案,例如 Paypal、SagePay 等,您从您的网站传递到提供商网站以获取信用卡详细信息,然后再传回。

        这免除了您 a) 合规和 b) 购买 ssl 证书的负担。

        【讨论】:

        • 唯一的问题是那些支付提供商对每笔交易收取费用。每笔信用卡交易的 3% 远高于 SSL 证书 13 美元。
        • 信用卡商家也会对每笔交易收取费用,即使您拥有 ssl 证书。
        【解决方案13】:

        不,因为您仍然容易受到中间人攻击。

        但是您可以使用它来大大降低您的 PCI 合规性要求,因为如果您使用没有私钥的公钥加密信用卡号,那么您就可以转移合规性的负担。

        即使是支付处理商也鼓励这样做。例如,请参阅 Braintree 在 client-side encryption 上的文章。

        【讨论】:

          【解决方案14】:

          绝对没有

          如果您想接受信用卡付款,但又不想自己正确操作,那么有些服务机构专门从事这方面的工作。

          这里有一些:

          2CheckOut、Affero、BTClick&Buy、CCAvenue、CCBill、CCNow、ClickBank、DigiBuy、DigitalCandle、FastPay、iBill、iKobo、ImagineNation、InstaBill、Jettis、Kagi、MembershipPlus、Moneybookers、MultiCards、MyPaySystems、NoChex、PartyKey、Pay-Line , Paymate, Process54, ProPay, Reg.Net, RegNow, RegSoft, Share*It, StormPay, SWREG, V-Share, Verotel, VolPay, Yahoo!直接支付。

          这是more complete list

          给他们打电话!

          当然还有PayPal

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2015-01-29
            • 2011-04-14
            • 2014-10-25
            • 2012-04-14
            • 2013-10-14
            • 2014-07-25
            • 1970-01-01
            相关资源
            最近更新 更多