传统进行防钓鱼的措施有3种：白名单校验， 时间戳校验， IP检查
1. 白名单检查
商户调用支付公司系统，其http请求的Referer字段应该是支付公司合作伙伴的某个URL链接。支付公司会收集合作伙伴的网站域名做成一个集合叫做“白名单”
逻辑：
1、refer为空，交易直接失败。
2、refer不为空，refer域名不属于白名单列表时，失败交易
2. 时间戳检查
商户在发出http请求前先调用支付公司提供的一个接口来拿到支付公司服务器上的当前时间T1，把时间T1作为支付请求链接的一个参数加在url中传递给支付公司服务器，支付公司服务器接收到请求后先取出url中的时间参数T1，然后再取一下支付宝服务器当前的系统时间T2，计算两个时间的间隔，如果时间差超过一定范围，则时间戳检查失败，拒绝服务，可以跳转到error页面。时间间隔的设定默认是60秒，可以根据配置灵活的调整
3. IP检查
商户首先在商户平台内获取用户客户端的IP地址，然后将该IP地址作为支付接口的参数加到URL中。支付公司服务器在接受到支付请求后先取出URL中的IP值，然后再重新获取当前操作用户的客户端IP地址，比对两者是否一致，如果不一致，则IP检查失败，然后提醒风险（这里是提示风险，由用户决定是否下一步操作，因为IP可能获取不同，比如某公司有双网络出口）
Basic认证及其安全问题
Basic认证是一个流程比较简单的协议，整个过程可以分为以下三个步骤：
a） 客户端使用GET方法向服务器请求资源。
b） 服务器返回401响应码和WWW-Authentication：Basic realm=”Family”响应头要求客户端进行身份验证。其中realm声明了资源所在的域。
c） 浏览器接收到以上HTTP响应头后，弹出登录框要求用户输入用户名和密码；用户提交的用户名和密码通过冒号串联起来并对其进行BASE64编码后再提交到服务器；服务器对提交上来的BASE64字符串进行验证，如果验证通过则返回200响应码。
Basic认证虽然简单、方便，但它只能作为对非敏感资源的访问认证，因为它并不安全，主要表现在以下几个方面：
1、 客户端提交的用户名和密码只经过简单的编码，攻击者只要窃听到该数据包，便可很容易的将其反编码为原始用户名和密码。
2、 即使客户端使用了一种比BASE64更复杂的编码方式使得攻击者无法对其反编码，攻击者也可以使用fiddler等工具将拦截到的HTTP报文重新提交给服务器，服务器只对编码的字符串进行验证，所以验证同样能通过。这种攻击方法称之为重放攻击（Replay-Attack）。
以上两个问题也是各种身份认证协议需要考虑到的安全问题，包括OAuth、Digest认证、NTLM认证等等认证机制都使用了nonce和timestamp来解决这些问题。
Nonce、Timestamp——解决Replay-Attack问题
Nonce是由服务器生成的一个随机数，在客户端第一次请求页面时将其发回客户端；客户端拿到这个Nonce，将其与用户密码串联在一起并进行非可逆加密（MD5、SHA1等等），然后将这个加密后的字符串和用户名、Nonce、加密算法名称一起发回服务器；服务器使用接收到的用户名到数据库搜索密码，然后跟客户端使用同样的算法对其进行加密，接着将其与客户端提交上来的加密字符串进行比较，如果两个字符串一致就表示用户身份有效。这样就解决了用户密码明文被窃取的问题，攻击者就算知道了算法名和nonce也无法解密出密码。
每个nonce只能供一个用户使用一次，这样就可以防止攻击者使用重放攻击，因为该Http报文已经无效。可选的实现方式是把每一次请求的Nonce保存到数据库，客户端再一次提交请求时将请求头中得Nonce与数据库中得数据作比较，如果已存在该Nonce，则证明该请求有可能是恶意的。然而这种解决方案也有个问题，很有可能在两次正常的资源请求中，产生的随机数是一样的，这样就造成正常的请求也被当成了攻击，随着数据库中保存的随机数不断增多，这个问题就会变得很明显。所以，还需要加上另外一个参数Timestamp（时间戳）。
Timestamp是根据服务器当前时间生成的一个字符串，与nonce放在一起，可以表示服务器在某个时间点生成的随机数。这样就算生成的随机数相同，但因为它们生成的时间点不一样，所以也算有效的随机数。
问题又来了，随着用户访问的增加，数据库中保存的nonce/timestamp/username数据量会变得非常大。对于这个问题，可选的解决方案是对数据设定一个“过期时间”，比如说在数据库中保存超过一天的数据将会被清除。如果是这样的，攻击者可以等待一天后，再将拦截到的HTTP报文提交到服务器，这时候因为nonce/timestamp/username数据已被服务器清除，请求将会被认为是有效的。要解决这个问题，就需要给时间戳设置一个超时时间，比如说将时间戳与服务器当前时间比较，如果相差一天则认为该时间戳是无效的。
HTTPS消息体的加密
很不幸的是，经过上面这些复杂的处理后，我们的数据传输仍然是不安全的。我们都知道，http报文是以明文的方式在网络中传输的，包括Basic认证、Digest认证、OAuth、NTLM等等验证这一些认证机制都只是对HTTP头的信息作保护，而对于Http消息体的数据却没有作加密。以新浪首页的登录为例，它的账号就是以明文的方式传送的，
这样的方式是很不安全的，用户名和密码完全以明文的方式提交了。同样是新浪的网站——新浪微博就在登录前作了加密过的，加密的方法可以参考前面讲到的nonce+timestamp的方案。不过这只解决了登录的问题，在注册时就不能提交使用nonce和timestamp非可逆加密了，这个时候要使用非对称加密。在用户打开注册页时，服务器生成一个公钥/私钥对并将公钥返回给客户端，客户端使用该公钥将密码加密后提交到服务器，服务器使用私钥解密后再保存到数据库。非对称加密算法的特点是每一个公钥和私钥都是一一对应的，使用公钥加密后只有拥有私钥的人才能进行解密，所以攻击者截取到http报文也毫无用处。
当然，在条件允许的情况下，可以使用SSL来实现HTTP报文的加密，这种方案是在应用层和传输层中间添加一个SSL层，该层使用对称加密的方法将HTTP报文加密后再传递到传输层，
在这之前，客户端与服务器需要使用非对称加密的方法来协商用于对称加密的公钥，对称加密要求加密者和解密者拥有同一个密钥（即公钥）。当客户端首次访问页面时，需要生成一个公钥给服务器，而这个公钥不是不可以给第三方知道的（知道了这个公钥就可对数据进行解密了），所以需要服务器首先生成一个公钥/密钥对，并使用生成的公钥加密客户端生成的公钥（非对称加密），这一个过程与前面讲到的注册密码加密的方式类似。
正因为在正式数据传输之前需要在服务器跟客户端之间进行几轮的协商，所以HTTPS相比HTTP来说安全性会高些、而性能会差些。