- 密码强化 -> 散列算法，加盐
- 人机识别 -> 选图 、滑动、点选等验证码的方式
- HTTPS
- 浏览器安全控制
- CSP(Content-Security-Policy)
人机验证滑动拼成一个完整图案的原理：
HTTPS:
对称加密：
就像是一把钥匙，把门锁上（加密），那么下次再进来时候，还要用这把钥匙去开门（解密）。
传统的对称加密使用的是一套秘钥，数据的加密以及解密用的都是这一套秘钥，可想而知所有的客户端以及服务端都需要保存这套秘钥，泄露的风险很高，而一旦秘钥便泄露便保证不了数据安全。
对称加密的一大缺点就是密钥的分配与管理，换句话说，如何把密钥发送到需要解密你消息的人手里是一个问题，因为在发送密钥的过程中，密钥很大风险会被黑客们拦截，现实的做法通常是对称加密的密钥进行非对称加密，然后传送给需要他的人。
非对称加密：
1.产生一对密钥
2.公钥负责加密
3.私钥负责解密
4.私钥无法解开，说明公钥无效 -> 意思就是公钥加了密后，放到网上，但是他说不是他做的，但是私钥解开了，那么公钥是不能抵赖的，就是他加密的。
5.计算复杂对性能有影响（消耗CPU）所以不能用于大量的数据传输。
非对称加密解决的就是这个问题，它包含两套秘钥 - 公钥以及 私钥，其中公钥用来加密，私钥用来解密，并且通过公钥计算不出私钥，因此私钥谨慎保存在服务端，而公钥可以随便传递，即使泄露也无风险。
保证SSH安全性的方法，简单来说就是客户端和服务端各自生成一套私钥和公钥，并且互相交换公钥，这样每一条发出的数据都可以用对方的公钥来加密，对方收到后再用自己的私钥来解密。
客户端和服务器两台机器除了各自的一套公、私钥之外，还保存了对方的公钥，因此必然存在一个交换各自公钥的步骤。实际上并不是简单的各自发送公钥，而是存在一些专门的算法。这一步在首次链接时、数据传送之前发生。
具体步骤：
- 客户端发起链接请求
- 服务端返回自己的公钥，以及一个会话ID（这一步客户端得到服务端公钥）
- 客户端生成密钥对
- 客户端用自己的公钥亦或会话ID，计算出一个值，并用服务端的公钥加密
- 客户端发送加密后的值到服务端，服务端用私钥解密
- 服务端用解密后的值亦或会话ID，计算出客户端的公钥（这一步服务端得到客户端公钥）
- 至此，双方各自持有三个秘钥，分别为自己的一对公、私钥，以及对方的公钥，之后的所有通讯都会被加密
这里有一个有趣的地方，两台机器第一次使用SSH链接时，当服务端返回自己的公钥（第2步）的时候，客户端会有一条信息提示，大意是无法验证对方是否可信，并给出对方公钥的MD5编码值，问是否确定要建立链接。
这是因为SSH虽然传输过程中很安全，但是在首次建立链接时并没有办法知道发来的公钥是否真的来自自己请求的服务器，如果有人在客户端请求服务器后拦截了请求，并返回自己的公钥冒充服务器，这时候如果链接建立，那么所有的数据就都能被攻击者用自己的私钥解密了。这也就是所谓的中间人攻击。
SSH协议是如何应对的呢？ 下图中圈起来的就是核心，去目标服务器的网站上看他的公钥指纹，其实就是建立对号入座的过程。
口令登录原理：
- 服务端收到登录请求后，首先互换秘钥，详细步骤如上面所述。
- 客户端用服务端的公钥加密账号密码并发送
- 服务端用自己的秘钥解密后得到账号密码，然后进行验证
- 服务端用客户端的公钥加密验证结果并返回
- 服务端用自己的秘钥解密后得到验证结果
SSH公钥登录原理：
有些时候并不是开发者手动去连接服务器，而是客户端的程序需要连接到服务器，这时候用密码登录就比较不方便，一是需要处理输入密码的问题，二是需要想办法安全的储存密码到程序里，这种情况下便可以利用公钥来进行无密码登录。
- 客户端用户必须手动地将自己的公钥添加到服务器一个名叫authorized_keys的文件里，顾名思义，这个文件保存了所有可以远程登录的机器的公钥。
- 客户端发起登录请求，并且发送一个自己公钥的指纹（具有唯一性，但不是公钥）
- 服务端根据指纹检测此公钥是否保存在authorized_keys中
- 若存在，服务端便生成一段随机字符串，然后利用客户端公钥加密并返回
- 客户端收到后用自己的私钥解密，再利用服务端公钥加密后发回
- 服务端收到后用自己的私钥解密，如果为同一字符串，则验证通过
利用公钥登录的关键是必须手动将客户端的公钥添加到服务端（这一步就是防止中间人攻击，提前关联约定好），比如GitHub便有这一步骤，添加了之后便可无密码登录。
