.Net服务器应用程序是否存在与存储和检索敏感的每个用户信息（如第三方凭据）相关的参考模式？
我的初步设计思路如下：
我的要求是：
更新 3.忘记提及能够定期重新密钥是一项要求，以便10年内不会使用相同的密钥加密密钥。
问题：
更新 考虑一下操作系统的危害，我意识到如果技术娴熟的攻击者获得访问权限但是密钥应该受到不良管理员的保护，那么就没有什么可以做的，也就是说打开文件或注册表项来提取私钥不仅仅是问题。
我确信这个问题已经解决了一千次，对链接答案感到高兴，但搜索“安全加密”类型主题是低信号高噪声。
答案 0 :(得分：1)
我不知道有关.NET服务器应用程序信息安全性的任何特定设计模式，但是，最终，您只能做很多事情来保护您从中请求的任何信息。用户，特别是商店。
如果您要存储将用于您自己的应用程序将执行的身份验证的任何用户密码，那么存储它的最佳方式是使用salted单向散列函数。这样，用户每次使用您的应用程序进行身份验证时都会以纯文本形式手动提供密码，您将立即对该纯文本密码进行哈希处理，并将其与您存储的哈希密码进行比较。任何攻击者，甚至是可以访问原始数据库的攻击者，都必须对所有盐渍哈希进行反向工程。并非不可能（给予足够的计算能力），但在所有现实中肯定不太可能。
如果您正在存储用户提供给您的用户名/密码，那么您的应用程序就可以使用这些凭据自动“登录”/“代表用户”另一个应用程序或服务进行身份验证，嗯，如果数据的安全性至关重要，我建议您不要这样做。
简单地说，即使您最终加密这些凭据（无论是对称加密还是非对称加密），该数据必须在某处使用，并且为此发生，需要对其进行解密。这可以说是安全链中的“薄弱环节”。
降低用户敏感度的风险 信息如果受到损害 .Net服务器的主机操作系统， 在这种情况下，窗口的数据中心 版本，受到了损害。
如果发生这种情况，所有赌注都会被取消。以加密形式存储数据不再具有任何意义，就像Windows可以解密该数据一样，一旦攻击者可以访问机器/操作系统，攻击者也可以解密。他甚至不需要尝试从Windows证书存储中“导出”私钥，因为他可以在解密链中进一步注入恶意代码，并在解密过程中简单地拦截解密数据。
当然，保护用户敏感数据的最佳方法是永远不要存储它。每次都要求用户使用它，将其用于您需要的任何目的，然后立即处理它。在英国，PCI (Payment Card Industry) Data Standards针对信用卡上的CVV代码采用此政策。商家可以存储信用卡号码，但不能存储数据库中的CVV代码。
如果你必须存储数据，那么一定要加密它，但要注意加密它并不一定“保护”数据，它只是增加了另一层有效混淆的内容对于可能危及您的物理机器或操作系统的攻击者。
如果您要存储数据，则必须尽可能获得强大的周边安全性（即Network security），以准确防止攻击者的潜在危险访问服务器的操作系统。
导出证书和密钥 将它们存储在USB密钥上 锁在宝箱里并守着 由龙，
除了可靠的防火墙和IDS系统之外，您可能还希望让其中一条龙来保护您的服务器！ ：）
答案 1 :(得分：0)
我不知道最好的解决方案是什么，但这就是我所看到的一些视频游戏特别是游戏。游戏将首先使用通常的私钥技术进行身份验证。然后，游戏将下载一个在本地运行的脚本。然后，该脚本将以某种方式检查托管它的可执行文件。该脚本可以检查可执行文件是同一游戏还是已修改。脚本将在游戏开始前调用home。如果脚本没有打电话回家，游戏服务器会把游戏踢出去。
恶意软件编写者必须以某种方式欺骗脚本来思考游戏。每当发现恶意软件执行此操作时，开发人员都会更改脚本。这可以确保游戏公司能够在野外停用恶意软件。
您可以根据您的应用调整类似技术。
答案 2 :(得分：0)
除了您自己制作的建议和其他一些海报外，您可以考虑隔离数据库检索和修改的安全性。如果一个帐户遭到入侵，另一个帐户是安全的。