上篇最后想法不合适
不能做base64， base64没有锁也可以做。
做base64和直接写明文没有区别，谁都可以做， 谁都可以解。如果是使用base64加密， 那加密锁起的作用仅仅是一个存储介质，相当于是一个移动优盘， 存储加密后的用户信息， 这样就没起到加密锁加密的作用。
其实制作的加密锁的方案合适不合适有一种检测方案：无论知道用户名密码，还是不知道用户名密码，不使用锁，看能不能登陆系统。难就难在要实现知道用户名密码，不使用加密锁，就无法登陆。
base64加密，如果不使用锁， 将用户信息加密后将加密结果存储到硬盘中， 把硬盘给用户， 或者是存储到内存中， 这样在用户登陆的时候， 从硬盘中读出加密后的用户信息， 再使用base64解密，同样可以获取到用户的信息实现登陆。
必须使用锁内算法
加密锁和硬盘的区别是， 我们可以将私钥放到锁里。 这样的话， 将用户信息使用公钥加密，将加密结果写到锁里。验证的时候， 只能通过锁里的私钥去解密， 如果没有这个锁， 根本解密不了。 也就是， 如果没有锁， 根本无法知道加密前用户的信息。也就无法将加密前的用户信息传给后台去与数据库比对。当然， 如果你事现就知道加密前的用户信息， 同样也可以不使用加密锁，通过调试代码进入系统。
再次明确目的
不管是用户本身也好， 还是不小心泄露了也好， 在知道用户名密码的情况下， 如果没有加密锁同样不能登陆系统。 必须得经过用户名密码和加密锁双重验证， 同时成立才能登陆。
再次整理思路
基本
要想实现使用用户名密码和加密锁的双重验证， 必须要客户端和服务器公共合作。
-
用户锁只存一份私钥文件。服务器产生随机数，将这个随机数返回个客户端。 客户端通过用户锁的私钥加密，将加密结果传递给服务器， 服务器使用公钥解密， 将解密后的结果与最开始生成的随机数比对。通过这种方式来实现必须使用加密锁。
-
登陆页面留两个输入框， 输入用户名密码。将用户名密码传入到后台验证，从而实现必须使用用户名和密码的验证。
首先， 看当前设备是否插入了加密锁。 以前的想法时通过XXX公司给的API去枚举锁， 看能不能找到锁信息。如果能找到就说明插入了用户锁， 这样不行。不行的原因是调试浏览器代码可以修改判定条件，比如response为1时证明有锁， 为其他值时证明没有。 我可以在浏览器调试代码， 使得这个值恒为1。但如果实现了第1点， 我需要锁里的私钥去对后台传过来的数据加密， 如果没有锁根本无法加密。 当然可以说随便使用一种算法加密， 但是服务器存有该私钥对应的公钥， 会对该私钥加密的随机数进行解密， 如果解密后与最开始生成的随机数不同， 就算没有使用key。
其次， 对用户名密码验证。就是正常系统的登陆， 将用户名密码传入到后台， 然后跟数据库比对。
最后要说明的是：锁里没有存关于用户的信息， 随机数必须从后台发起。
完善1
做到上面两点基本功能算是完成了。但是多数情况下， 我们还需要将key与用户绑定， 也就是说， 每个用户有他自己的key， 别人使用他的key登陆不上， 他使用别人的key也登陆不上。
目前实现将用户与锁绑定的方式， 是在锁里存放用户的标识， 比如用户账号。发送验证请求的时候， 将锁里的账号发送到后台， 与用户输入的账号比对， 看是否一致。
不过这样不是很好。 假如说我的加密锁里存放的账号是xxm， 我拿着账号为zds的加密锁。这样表面上，我输入的和用户锁里的账号是不一致的是不能通过的。但是在对比的过程中可以调试浏览器代码。如果在客户端比对， 可以通过调试，使得比对结果恒为true。 如果将锁里的账号传到后台比对， 可以通过调试，在获取到锁里的账号后向后台传送时， 将zds改为xxm。
如果在向锁里存用户账号的时候， 使用锁里的私钥， 对用户账号加密，将加密结果写入到锁内。在后台使用公钥去解密感觉也可以。但实际是不行的。同样是调试代码， 在调试代码时编写代码， 增添使用锁内私钥加密功能。这样向后台发送锁里加密后的用户账号的时候， 不再发送锁里存放的， 而是发送添加的对自己账号加密的密文。
所以说， 目前这种实现方式是有漏洞的。对于这种usbkey登陆认证， 加密明文的发起一定要是服务器端， 类似于随机数加密， 后台产生随机数发送给客户端， 客户端去加密，然后将密文传给后台， 后台解密与原来的验证。如果明文的发起是客户端， 那就相当于自己验证自己， 是有漏洞的。
完善2
还有一点没有考虑到，假如我知道zds的账号和密码， 但是我没有该用户的加密锁。 这种情况我可以自己制作一个加密锁。无非就是往锁里生成一对密钥文件，然后再把zds的账号信息写到锁里。这样我就制作成了一把和zds账号对应账户一摸一样的锁。
解决方式1：额外使用一把锁，暂时称之为管理员锁。 生成密钥对文件， 将私钥写入到管理员锁， 公钥放到后台程序中。利用管理员锁的私钥对用户账号加密， 将密文传给服务器，服务器使用公钥解密验证。这样用户锁就不能随便制作了。
解决方式2：不用准备锁， 签发用户锁的时候， 向每个用户锁类写入相同的私钥。 这个私钥文件一定要管理员保存好。因为这个私钥文件是用来制备用户锁的。谁拿到都可以制备。这样和上面的流程一样， 后台返回随机数， 这个私钥加密，密文传给后台解密比对。 如果没有私钥文件，那制备的加密锁对随机数加密后台就解不了了。
小误区
后台进行解密的时候， 因为服务器没有锁，与锁就没有任何关系了， 也就不用调用XXX公司给的解密接口。 知道公钥， 知道密文，可以上网查询关于RSA加密文件是怎么解密的，从而实现解密。
网友评论