今天看到同事转的一个防止扫码登录钓鱼的文章，在 Github，原文链接：https://github.com/OWASP/QRLJacking/wiki/Recommendations-and-Mitigations
里面给了几个防止钓鱼的建议，和一个声纹识别的风控方案，简而言之：
登录交互中，生成显示 二维码页面 或 网站提供者 的指纹信息，并在扫码页面上展示；
检查生成二维码登录页 和 扫码设备 的网络、地域，并做限制；
利用声纹技术，闭环检测；
限制不同网络、地域的扫码，可能会误伤，可以在 App 扫码确认的页面，展示被扫页面的信息，如二维码生成的城市、终端信息，提示用户是不是正常的。这也是第一条提到的指纹信息。
很有意思的是声纹技术，比如在 PC 浏览器中显示二维码登录，使用 App 扫码，在 App 确认登录的页面，让手机发出带有验证码信息的声音，然后让 PC 浏览器识别，相当于页面回填验证。只是实现起来依赖设备的语音输入是否正常了。
文章翻译如下：
Recommendations and Mitigations 推荐和防护方案
Our top recommendation is to just stop using Login with QR code except when it is necessary also there is a lot of ways to mitigate such issue and here is some ways to be used together or standalone:
我们最推荐的方式，是不使用二维码登录，除非实在有必要。当然这也有一些方案可以防护这些问题，可以配合或单独使用：
Session Confirmation, We recommend implementing a confirmation message/notification displaying characteristic information about the session made by the client/server. 会话（Session）确认：我们推荐实现一种消息或通知确认的会话（Session）机制，这个会话（Session）中需要展示客户端和服务端生成的特征信息。
IP Restrictions, Restricting any authentication process on different networks (WANs) will minimize the attack window. 网络限制策略：限制所有跨网络的认证过程，将缩小攻击窗口。
Location-based Restrictions, Restricting any authentication process based on different locations will minimize the attack window. 基于地域的限制策略：限制所有跨地域的认证过程，将缩小攻击窗口。
Sound-based Authentication, One of the techniques to mitigate this kind of attack [And maintain the same usability level as to not require any additional interaction from the user other than scanning the QR ] is to add sound-based authentication step to the process , we have seen this kind of technology where it is possible to generate unique data and convert it to audio that can be recognized back into its original form [SlickLogin and Sound-Proof] so it is possible to include this technology in the process . 基于语音的身份验证：这是一种可以减少二维码钓鱼攻击的技术（它和扫码有一样的可用性，不会额外增加交互），在认证过程中增加语音验证环节。我们在SlickLogin公司的语音验证功能中，已经见识过这种技术：生成一个唯一的数据，在转化到音频中后，再识别还原。所以这技术可以用在认证过程中。
The purposes of this added step is to make sure that scanned QR code is generated in the same physical location as the mobile device that is doing the scan and therefore eliminating the possibility of a remote attacker deceiving the user into scanning his qr code.
增加语音验证环节的目的，是确保生成二维码的设备，和扫码的设备，在同一个物理位置。这样可以排除远程攻击的可能性：攻击者让用户扫攻击者中转的二维码。
Figure(5) An illustration of the login process [QR code login + Sound authentication]
图 5 展示了有语音验证环节的扫码登录过程。
The Attack Scenario (with the mitigation)：有防护策略的攻击场景
Attacker visits the website and opens a session. 攻击者访问网站，并打开一个会话（Session）
The Website Generates QR Code which holds a session key.网站生成一个含会话密钥（ Session key） 的二维码
Attacker crafts a phishing website with the received QR Code and sends it to the user. 攻击者伪造一个含有上述登录二维码的钓鱼网站，并发送给用户。
User scans the attacker's QR Code in the phishing website. 用户在钓鱼网站上尝试扫码登录。
The mobile App generates the authentication sound and play it to the phishing website. 扫码的 App 会生成含认证信息的语音，并播放让网站听。
The phishing website fails to process and capture the authentication audio as it requires additional browser permissions. 钓鱼网站无法识别到认证语音，因为这需要额外的浏览器权限，扫码登录认证流程失败。
Even if the attacker tries to generate the authentication sound based on the (User ID) he still lacks the private key. 即使攻击者试图生成这条认证语音，但他没有这个帐号的私钥信息，所以还是会失败。
Figure(6) An illustration of the login process [QR code login + Sound authentication] attacks & mitigation
图 6 展示了含有语音认证环节的扫码登录攻防过程。