[b]前言 [/b] 上一篇记录了如何在 Kestrel 中使用 HTTPS（SSL）, 也是我们目前项目中实际使用到的。  数据安全往往是开发人员很容易忽略的一个部分，包括我自己。近两年业内也出现了很多因为安全问题导致了很多严重事情发生，所以安全对我们开发人员很重要，我们要对我们的代码的安全负责。  在工作中，我们常常会见到 encode，base64，sha256, rsa, hash，encryption, md5 等，一些人对他们还傻傻分不清楚，也不知道什么时候使用他们，还有一些人认为MD5就是加密算法。  在 ASP.NET Core 中，为数据保护相关提供了一批新的 API，包括加密解密机制，下面就让我们来看看吧。  [b]目录[/b]  •加密，编码，哈希之间的区别  •数据保护（Data Protection）介绍  •ASP.NET Core 中的数据保护  •总结  [b]编码，加密，哈希之间的区别[/b]  1、编码  编码是信息从一种形式或格式转换为另一种形式的过程，他们是可逆的。  如 url、base64、jsunicode、utf-8等等。  2、加密  加密是可逆的，类似于编码也是把数据从一种形式转换为另一种形式，它通过一个特定的加密的密匙，相对应的有解密的过程。加解密的算法有2种：对称加密算法和非对称加密算法。  对称：DES、AES、SM1、RC4 等等。  非对称：RSA、ECC、SM2 等等。  3、哈希  又叫"散列"，就是把任意长度的数据转换成固定长度的“指纹”，这个过程是不可逆的。而且只要输入发生改变，输出的 hash值也会有很大不同。  它还有一个特性是相同的输入总是有相同的结果, 这种特性恰好合适用来用来保存密码。  如：MD5、SHA256, SHA512, RipeMD, WHIRLPOOL等等。  [b]数据保护（Data Protection）介绍  [/b] 在看数据保护官方文档的时候，微软的文档是这样写的，大致意思就是他们基于几点需求，要开发一套数据保护的库以便用来给受信任的客户端和不受信任的客户端来使用。这几点要求就是：  1、真实性、完整性  举了一个身份验证cookie的例子，就是服务端生成了一个包含xyz权限的token，然后会在将来的某个时间过期，这个时候就需要重新请求生成一个，怎么样来保证请求的token不是被篡改过的。  2、机密性  服务器要保证请求是受信任的，所以就需要一些包含特定操作环境的信息，比如一个路径，一个权限或者一个句柄或者其他的一些东西特定于服务器的东西，这些信息不应该透漏给不受信任的客户端，也就是说类似于私钥。  3、隔离性  然后就是要求做成一个组件，并且这个组件具有独立性，可以不依赖于系统中的其他组件。如一个bearer token的组件，它要使用这个组件的话，也不需要引用anti-CSRF这种机制了。  再进一步的缩小需求范围，加密的数据不需要在系统之外的其他系统中使用，另外处理速度要尽可能的快，因为每一次web请求都会使用加密组件一次或者多次。  基于以上要求，微软提出来可以使用密码学，因为这是一个典型的密码学应用的场景。确实这是一个密码学的应用场景，并且是一个非对称加密算法的场景。但是大家都知道，非对称加密是由一个公钥和私钥用来保证安全性的，即使公钥遭泄露，整个通讯仍然是安全的，这就是它比对称加密的好处。但是非对称加密也是有缺点的，就是加密和解密花费的时间长，速度慢。  但是上面的要求又是需要速度尽可能快，怎么办呢？ 于是微软的工程师们想出了可以通过精简并且优化非对称加密机制，来达到这个要求。因为不需要跨系统或者跨语言什么的，所以也不需要什么协议之类的，这就给优化带来了更多的可能性。  到这里，我就想，如果让我来基于以上几点来设计开发这样一个系统，我应该怎么样设计？怎么样达到要求？  带着这个问题，我们来进一步看看微软是怎么样做的吧？  下面是一些总结的设计原则 ：  1、配置应该尽量的简单，默认情况下应该可以零配置，开发人员可以直接运行。  2、提供一个简单的API，应该容易使用，并且不会轻易用错。  3、开发人员不需要专门学习怎么样管理这些钥（公钥，私钥），系统应该自动的选择算法和管理钥的生命周期。理想情况下开发人员都不应该访问这些钥的原始文件。  4、钥应该是受保护的，不会被远程调用到。系统应该有一个自动保护机制并且可以自动应用。  如果让我设计这样一个库，我可能不会想到这么多，也许只会想到前3点。  再看一下针对的受众群体：  1、应用程序开发人员和框架开发人员（不需要学习任何知识）。  2、应用开发人员和系统管理员（不使用默认配置，只是设定一些路径等）。  3、针对具有更高安全意识的开发人员提供可扩展api，或特定需求扩展（需要重写系统的组件，有一些独特的需求）。  以上，可以看到微软在开发一个组件的时候对问题的分析，也许我们可以从中学到一些东西。  [b]ASP.NET Core 中的数据保护[/b]  Web应用程序中经常需要存储一些敏感数据（如用户密码），Windows 系统为桌面程序提供了DPAPI用来使用，但是并不适用于 Web 系统。ASP.NET Core提供了一套简单易用的API 用来保护数据。  ASP.NET Core 中，数据保护主要是用来给服务端设计的，用来替换ASP.NET 1.x-4.x中的，machineKey主要是用来保证使用Form身份验证时Cookie数据的加密解密，以确保不会被修改。或者ViewState数据的加密解密不被篡改，以及对session状态标识进行验证。  先看一下最简单的使用方法： 在CreateProtector("Contoso.MyClass.v1")中，参数“Contoso.MyClass.v1”可以理解为一个公钥，因为 ASP.NET Core Data Protection 是非对称加密（见前面介绍），所以系统中应该还有一个密钥，那么此处的密钥 ASP.NET Core 在系统内部帮你维护了。  读到这里，有同学可能会问了，那系统中是如何帮我维护我的密钥的呢？ 我们不妨先来做一个测试。  首先，我在我的开发环境中，先把上面的程序中的解密部分代码注释掉，然后运行上面的程序，输入一个“Hello World!” ，得到了一个加密的字符串CfDJ8ICcgQwZZhlAlTZT...OdfH66i1PnGmpCR5e441xQ(略写)。  然后我把同样的程序拷贝到另外一台开发环境的机器上，然后把上面的加密部分代码注释掉，使用第一步生成的CfDJ8ICcgQwZZhlAlTZT...OdfH66i1PnGmpCR5e441xQ来解密，注意这两步中我们都使用 "Contoso.MyClass.v1" 来做为公钥。  运行程序，查看结果： [img]http://files.jb51.net/file_images/article/201609/2016910141351871.jpg?201681014140[/img] 程序抛出了一个“System.Security.Cryptography.CryptographicException”异常的结果。  [b]为什么呢？ [/b]这是因为每一台机器都有一个自有的私钥，由于在解密的过程中，这个私钥是不同的，所以解密失败，抛出了一个异常。  [b]私钥[/b]  私钥存放在哪里呢？  1、如果程序寄宿在 Microsoft Azure下，存储在“%HOME%\ASP.NET\DataProtection-Keys” 文件夹。  2、如果程序寄宿在IIS下，它被保存在HKLM注册表的ACLed特殊注册表键，并且只有工作进程可以访问，它使用windows的DPAPI加密。  3、如果当前用户可用，即win10或者win7中，它存储在“%LOCALAPPDATA%\ASP.NET\DataProtection-Keys”文件夹，同样使用的windows的DPAPI加密。  4、如果这些都不符合，那么也就是私钥是没有被持久化的，也就是说当进程关闭的时候，生成的私钥就丢失了。  下面是博主机器上的私钥文件：  一个xml配置文件，位于C:\Users\用户名\AppData\Local\ASP.NET\DataProtection-Keys文件夹，名为：key-c37e3ed9-fbb5-47bc-9e8c-128afaf1c6d9.xml，内容如下： 文件包含一个创建日期，一个过期日期。间隔为90天，当90天之后密钥就会失效，系统将自动生成一个新的密钥并设置新的密钥作为活动的密钥。只要已过期的密钥还存在于系统上，你仍然可以解密任何受保护的数据。  文章不宜太长，下篇再接着写。  [b]总结[/b]  这篇文章算是对ASP.NET Core Data Protection做了一个大致的介绍，并且包含了一个简单的使用方法。 在实际使用过程中，其实很多组件内部都会使用到它，比如Session中间件，Identity中间件，Authercation中间件等等，对于普通开发人员在编码的时候可能不会用到，但是在做系统分布式部署的时候如果你不了解这个机制可能就会遇到麻烦了（详见蟋蟀博客的这篇文章），所以还是可以期待一下下文，更加深入的了解它，掌握它。 以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持编程素材网。