升级 Swift 依赖项的加密算法
我正在使用开源 MobSF 安全框架来扫描我的 Swift 项目的源代码及其依赖项是否存在漏洞。大多数事情看起来都不错，但我担心它告诉我依赖项中的加密算法（MD5、SHA1）不够安全。
解决这个问题的标准做法是什么？我确保为其中大部分提取最新的分支，但他们似乎坚持使用过时的算法。我不愿意进去，不得不更改他们的源代码，结果每次重建 Podfile 时它都被删除了。
I am using the open source MobSF security framework to scan my Swift project's source code and its dependences for vulnerabilities. Most things look pretty good however I'm concerned that it is showing me that encryption algorithms (MD5, SHA1) in my dependencies are not sufficiently secure.
What would be standard practice for solving this? I made sure to pull the latest branches for most of these but they seem to insist on using outdated algos. I am reluctant to go in and have to change their source code only to have it wiped out each time I rebuild the Podfile.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，这取决于他们使用这些算法的原因。对于某些用途，MD5 或 SHA-1 不存在安全问题，并且它们可能是与现有标准兼容或向后兼容所必需的。
例如，PBKDF2 使用 SHA-1 作为其哈希值是完全安全的。它不需要非常强大的哈希函数来维护自身的安全性。使用 MD5 甚至是安全的。使用 PBKDF2 切换到 SHA-2 并不能提高安全性，它只是“安全卫生”，即“避免使用代码中存在已知问题的算法，即使它们在您的特定用例中不会造成问题。”安全卫生是一种很好的做法，但它与安全不同。
对于其他用例，哈希函数的安全性至关重要。如果一个框架使用 MD5 来验证任意消息，那就完全崩溃了。不要认为这个答案表明算法不重要。他们做到了！但并非在每个用例中都如此。如果您想解码信用卡刷卡交易，您可能需要在代码中使用 DES，这可怕被破坏了，但您仍然需要它，因为这就是它的魅力条带已加密。它不会使您的框架变得“不安全”。
当你说“但他们似乎坚持使用过时的算法”时，我假设你的意思是你打开了一个 PR 并且他们拒绝了它，在这种情况下我认为他们有充分的理由（例如在没有实际安全问题的情况下向后兼容） ）。如果您还没有，那么显然第一步就是创建 PR。
也就是说，如果您想更改此设置，因为您觉得存在他们无法解决的实际安全问题，或者纯粹是为了卫生，那么使用 CocoaPods，您可以分叉该项目，修改它，并使用
pod 的source属性代码>关键字。我自己维护一个加密框架，经常收到使用这些扫描仪的开发人员提出的完全错误的错误报告。确保您知道扫描仪告诉您什么以及如何评估结果。误报在这些方面非常常见。这些工具很有用，但您需要具备一些专业知识才能阅读他们的报告。
First, it depends on why they're using these algorithms. For certain uses, there are no security problems with MD5 or SHA-1, and they may be necessary for compatibility with existing standards or backward compatibility.
As an example, PBKDF2 is perfectly secure using SHA-1 as its hash. It doesn't require a very strong hash function to maintain its own security. It's even secure using MD5. Switching to SHA-2 with PBKDF2 doesn't improve security, it's just "security hygiene," which is "avoid algorithms that have known problems even being in your code, even if they cause no problems in your particular use case." Security hygiene is a good practice, but it's not the same thing as security.
For other use cases, the security of the hash function is critical. If a framework is authenticating arbitrary messages using MD5, that's completely broken. Don't take this answer to suggest that algorithms don't matter. They do! But not in every use case. And if you want to decode credit card swipe transactions, you're probably going to need DES to be in your code, which is horribly broken, but you're still going to need it because that's how magnetic stripes are encrypted. It doesn't make your framework "insecure."
When you say "but they seem to insist on using outdated algos," I assume you mean you opened a PR and they rejected it, in which case I assume they have a good reason (such as backward compatibility when there is no actual security problem). If you haven't, then obviously the first step would be to open a PR.
That said, if you want to change this because you feel there is an actual security problem that they will not resolve, or purely for hygiene, then with CocoaPods you would fork the project, modify it, and point to your own version using the
sourceattribute to thepodkeyword.Maintaining a cryptography framework myself, I often get bug reports that are simply wrong from developers using these scanners. Make sure that you know what the scanner is telling you and how to evaluate the findings. False positives are extremely common with these. These tools are useful, but you need to have some expertise to read their reports.