安全软件体系结构

Question

我正在设计一个软件架构，我需要一些建议和澄清的几个问题。

这将是一个服务器端的RESTfull API，用于访问数据和多个移动/桌面客户端来访问API，收集一些数据和在客户端消费的数字产品。它将通过HTTPS访问。

客户端将是iOS (Swift 2)、安卓(Java)、Windows (C#)、Windows (C#)、Windows (C#)、Mac (Swift 2)、Web (C#/JavaScript/HTML)、Linux (编程语言尚不清楚)。

服务器端应用程序编程语言是C# on .Net Framework4.6，它将在Azure上运行

客户端可以在计算机(MAC、PC、Linux)、浏览器、智能手机或平板电脑(iOS、Android、Windows、Windows )上运行。

客户端将使用oAuth 2对REST服务进行身份验证，然后成员将使用其用户名和密码进行身份验证。成员唯一Id将存储在客户端数据库中，以便对进一步的步骤/请求进行身份验证和API请求，因为如果成员有意登出，则不需要登录。

当成员请求从API将有一个下载过程中的中型数字文件(如pdf或视频文件约200 mb)。文件将在服务器上加密，以便在客户端使用时解密。这意味着我们将在运行时解密数字产品，因此不会在解密的客户端中存储任何文件。因此，我的解密必须非常快和低资源消耗，但安全。

会员将被允许注册使用客户端软件的3种设备

当成员首次在设备上使用应用程序时，客户端设备将自动注册。

文件需要在客户端消费，如果客户注册，成员是有效的，数字产品是成员购买。任何其他成员或任何其他软件都不能消费产品。

下面是我在软件中实现上述要求的初步方法，这样我就可以确保产品和系统的安全：

我无法在这里输入我所有的解释，因为表单说这是垃圾邮件。这就是为什么我在下面添加了一个链接，这样您就可以在https://cryptbin.com/EDu#716f72dbd22ede12531a83cba4e464fb中找到我所有的笔记了。

这里我的问题；

• 我将使用SHA-512散列将我的成员密码保存在数据库中。我会用盐做密码。因此，我将在数据库中为每个成员保存SALT密钥。用这种方式实现安全和安全吗？
• 我是否应该将IV (初始化向量)保存在每个产品的数据库中，以便我可以使用它进行加密？如果是这样的话，我需要通过我的API公开它，这样客户端就可以获得它来解密。曝光安全吗？
• 哪种加密和哈希算法在不同的环境中使用最好，没有任何问题。我将解密iOS、安卓、Windows、Windows、Mac等文件。我从一位朋友那里得知，他在服务器上使用AES-128和MD5加密文件，但当试图解密文件时，他在不同客户端面临很多问题。
• 我计划使用AES-256 (密码模式: CBC，填充模式: PKCS7，带IV)和SHA-512.对这个选择有什么意见吗？
• 我将在数据库中存储2个不同的验证密码和2个不同的加密密码，这样我就可以将其与AES和SHA-512一起使用。但我需要在客户端代码中存储与硬编码文本相同的密码，以便对产品进行解密。但是这个密码可以通过消除混淆而被窃取。在客户端环境和其他重要客户端信息中保存这4密码的最佳方法是什么？
• 当我向市场发布iOS、安卓和Windows、Windows、Mac应用程序时，它们就会被自动混淆和签名。我将手动签署和混淆我的Windows应用程序。这足以保护我的代码免受好奇的人之害吗？
• 我正在使用一些数据加密或散列文件或信息。我必须通过API公开这些数据，这样我的客户端就可以获得这些数据并使用它们进行解密。这样做安全吗？还有别的办法吗？
• 对我上面解释的架构有什么建议吗？你预测过这种方法会有什么漏洞吗？

如果我们需要澄清什么，我可以给出更多的细节。

Answer 1

我将使用SHA-512散列将我的成员密码保存在数据库中。我会用盐做密码。因此，我将在数据库中为每个成员保存SALT密钥。用这种方式实现安全和安全吗？

是的，如果你使用的是盐(你应该这么做)，那么你应该把盐(清空)存储在散列旁边。

我是否应该将IV (初始化向量)保存在每个产品的数据库中，以便我可以使用它进行加密？如果是这样的话，我需要通过我的API公开它，这样客户端就可以获得它来解密。曝光安全吗？

这取决于您所使用的加密方案/模式，但由于您提到了AES-CBC，因此不需要对IV保密。唯一的要求是IV是随机/不可预测的。

哪种加密和哈希算法在不同的环境中使用最好，没有任何问题。我将解密iOS、安卓、Windows、Windows、Mac等文件。我从一位朋友那里得知，他在服务器上使用AES-128和MD5加密文件，但当试图解密文件时，他在不同客户端面临很多问题。

加密和哈希算法与语言和操作系统无关，您应该能够在大多数语言中找到实现。AES和SHA家族得到了特别的支持和广泛的应用。我不知道你的朋友遇到了什么问题(通常你想避免MD5)。

我计划使用AES-256 (密码模式: CBC，填充模式: PKCS7，带IV)和SHA-512.对这个选择有什么意见吗？我正在使用一些数据加密或散列文件或信息。我必须通过API公开这些数据，这样我的客户端就可以获得这些数据并使用它们进行解密。这样做安全吗？还有别的办法吗？

我要把这两点结合起来。我将假设，当您说AES-256和SHA-512时，您指的是用于加密的AES，以及作为消息完整性检查的SHA。这有一个问题:假设您对消息进行加密，然后计算哈希以确保完整性。假设您正在使用CBC模式，敌手可以(例如)执行比特翻转攻击，然后重新计算修改后的密文的散列，您将不会更明智。通常，为了完整性和真实性，您可能希望使用键控散列(如HMAC)。

现在(到第二点)，有一个叫做具有附加数据的认证加密(AEAD)的东西，它实际上将解决上一段中提到的问题(它将提供机密性、完整性和真实性，而不必用原语构建方案)。它还将使某些数据(额外数据)保持清晰，但仍将确保该数据的完整性。查看GCM模式(例如AES-GCM)。

我将在数据库中存储2个不同的验证密码和2个不同的加密密码，这样我就可以将其与AES和SHA-512一起使用。但我需要在客户端代码中存储与硬编码文本相同的密码，以便对产品进行解密。但是这个密码可以通过消除混淆而被窃取。在客户端环境和其他重要客户端信息中保存这4密码的最佳方法是什么？

我不是这方面的专家，但我强烈建议不要将密码硬编码到客户端。任何合理聪明的攻击者都将能够在最短的时间内恢复这个密码，因此这里实际上没有任何安全性。

当我向市场发布iOS、安卓和Windows、Windows、Mac应用程序时，它们就会被自动混淆和签名。我将手动签署和混淆我的Windows应用程序。这足以保护我的代码免受好奇的人之害吗？

我的理解是，签名代码/应用程序是为了向最终用户证明代码的真实性，以确保对手没有背弃他们下载的代码/app或类似的代码，并且不会使反编译/反向工程变得更加困难。混淆可能也不足以阻止一个专门的对手弄清楚您的源是如何工作的，或者在代码中恢复敏感数据。我一直觉得这是默默无闻的一个例子。

Answer 2

另一个答案涵盖了大部分问题，但题目是“安全软件体系结构”，所以我将回答最后一个宽泛的问题。

这将是用于访问数据的服务器端RESTfull API和访问API的多个移动/桌面客户端.对我上面解释的架构有什么建议吗？你预测过这种方法会有什么漏洞吗？

有一个明显的弱点。

当您让人在公共web和您的内部系统之间编写自定义代码时，您会增加安全漏洞的风险。最常见的问题是SQL注入，但问题还不止这些。API端点可能没有授权设置，使未经授权的用户能够做他们不应该做的事情。如果您想检查授权是否正确执行，您需要使用专业软件工程师来进行检查。当然，您可以减轻大部分风险，但这需要付出很大的代价，而且不能消除风险。此外，随着时间的推移，代码也会发生变化，开发团队也是如此。

那么，在没有自定义的人工编写代码的情况下，如何实现API呢？有数据库网关。这方面的一个流行例子是GraphQL。它是一个通用工具，有“自定义代码”，但是它是由构建您选择的GraphQL服务器引擎的团队管理和维护的。如果在处理JWT时存在已知的漏洞，他们将对其进行修补。你不仅得到了更好的安全，而且你也节省了时间/金钱。

“数据库网关”的概念也不必是GraphQL。可以使用相同的模式直接使用SQL参见https://colossal.gitbook.io/microprocess/definition/data-web-gateway (我是这个开放文档草案的作者)