TLS 足够安全吗?需要在 PA-DSS 支付应用程序中滚动哈希吗?

发布于 2024-10-22 06:45:08 字数 785 浏览 4 评论 0原文

我是一名软件工程师,目前正在开发另一个支付应用程序(我的第三个),该应用程序必须符合 PCI PA-DSS 合规性。我正在重新检查 PA-DSS 文档,我想知道过去我是否在应用程序的安全性方面过度劳累,而我本来可以使用 TLS 和用户/通行证。因此,我的问题是,在实施 PA-DSS 安全应用程序时:

  1. 对于身份验证和通信安全,拥有 TLS + 用户/密码是否足够?

  2. PA-DSS 标准的哪些部分证明需要在 Web 方法调用之间实现消息哈希和滚动哈希? TLS 实现可靠的消息,但不会在消息之间滚动哈希和持久调用者。实施滚动哈希会产生任何影响吗(从 PA-DSS 的角度来看)?

  3. 如果支付处理应用程序存储 PII 信息并为不同的公司提供服务(意味着公司 A 和公司 B 可以在此类应用程序中拥有帐户),则没有具体要求规定 PII 信息不能存储在同一数据库中,但是过去,PA-QSA 一直坚持认为这是一个问题。问题是:这真的有必要吗?我无法想象 Authorize.NET,一家拥有数千个客户和处理商的公司有不同的数据库来存储通过每个客户公司处理的信用卡。

提前致谢!


更新 #1:

  • 假设 DMZ 和安全区中的所有页面和 Web 服务都将为所有通信通道、页面和服务提供 HTTPS。

  • 关于#3,问题不在于敏感信息存储的位置或安全性。这个问题更适合于质疑在同一数据库中共享来自不同来源(例如 AT&T 和 Verizon 等客户)的敏感信息的能力。

I’m a software engineer and I’m currently working on another payment application (my 3rd one) that must go under PCI PA-DSS compliance. I’m re-examining the PA-DSS documentation and I’m wondering if in the past I overworked on the security of the application, when I could’ve go by with TLS and user/pass. So, my questions are, when implementing a PA-DSS secure application:

  1. For Authentication and Communication security is it enough to have TLS + user/pass?

  2. What part(s) of the PA-DSS standard justifies the need of implementing message hashing and rolling hash between web methods calls? TLS implements reliable messages, but not rolling hashes and persistent callers between messages. Will implementing a rolling hash make any difference (from the PA-DSS stand point)?

  3. If a payment processing application stores PII information and serves different companies (meaning that Company A and Company B can have accounts in such application), there is no specific requirement that states the PII information cannot be stored in the same DB, but in the past, PA-QSAs have insisted in this being an issue. The question is: Is this truly necessary? I cannot think Authorize.NET, a company with thousands of clients and processors have different databases to store the credit cards processed through each of its client companies.

Thanks in advance!


Update #1:

  • Assume all pages and web services, both in DMZ and Secure Zone will have HTTPS for all the communication channels, pages and services.

  • On #3, the question is not about the location or security of the storage of sensitive information. The question is more geared to question the ability of sharing sensitive information from different sources (clients, such as AT&T and Verizon for example) in the same database.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

玉环 2024-10-29 06:45:08

这里有几个问题。

1) 仅对用户名+密码使用 TLS 仍然是一个漏洞。它违反了owasp a9,并且很容易劫持您的任何帐户系统使用 firehseep 风格的攻击。

我知道 PA-DSS 2.0 并未体现整个 owasp top 10,但应注意要求 12.1:

12.1 指示客户使用以下方法加密所有非控制台管理访问
强密码学,使用
SSH、VPN 等技术
SSL/TLS 用于基于 Web 的管理和
其他非控制台管理
访问。

其中将包括一个管理 http 接口。

2) PA-DSS 建议使用真正的传输层安全性,例如:VPN 和 TLS/SSL。我不认为需要滚动哈希,而且说实话这不是一个非常安全的设计。此类流量需要完整的传输层保护。

3)不要忘记要求9:

9.持卡人数据绝不能存储在连接到互联网的服务器上

There are a few issues here.

1) Using TLS for just the username+password is still a vulnerability. Its a violation of owasp a9 and its trivial to hijack any account on your system using a firehseep style attack.

I know the PA-DSS 2.0 doesn't embody the entire owasp top 10, but requirement 12.1 should be noted:

12.1 Instruct customers to encrypt all non-console administrative access with
strong cryptography, using
technologies such as SSH, VPN, or
SSL/TLS for web-based management and
other non-console administrative
access.

Which would include an administrative http interface.

2) The PA-DSS recommendeds using real transport layer security such as: VPNs, and TLS/SSL. I don't believe there is a requirement for rolling hashes, and to be honest this isn't a very secure design. Such traffic needs full transport layer protection.

3) Don't forget about requirement 9:

9. Cardholder data must never be stored on a server connected to the Internet

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文