如何使用iOS生物识别身份验证启用登录
在开发CloudEver应用程序时，我了解了iOS生物识别技术，包括Face ID和Touch ID。 然后，我查看了一些具有指纹登录功能的应用程序，发现其中许多应用程序没有充分利用iOS安全功能的优势。 我想与社区分享知识，并希望我们使用的应用程序将越来越安全。
大多数早期的Internet服务主要为未登录的每个人提供静态内容。 后来，出现了一些动态服务，例如论坛，聊天室等。 那时，身份验证需要密码。 然后，密码认证已被许多Internet服务广泛采用。
但是，要确保密码认证的安全性并不容易。 如果用户名和密码被他人破解，可能会泄露用户信息，甚至造成金钱损失。 那么，实现密码认证的常见错误是什么？
1.使用HTTP代替HTTPS进行密码身份验证
过去，一些著名的Internet公司设计了自己的方法来对浏览器中的密码进行加密，然后将其提交到其服务器以通过HTTP进行身份验证。 后来，他们发现这是错误的，今天几乎所有大公司都转换为HTTPS。
我们必须使用HTTPS来验证用户名和密码。
2.使用HTTPS进行密码身份验证，但通过HTTP显示登录框
一些开发人员认为，只要通过HTTPS传输，用户名和密码就不会被泄露。 因此，它们通过HTTP提供登录页面以节省服务器资源。 但是，这是一个非常常见的错误。 黑客可能会通过HTTP（即MITM javascript注入）将恶意javascript嵌入登录页面。 用户名和密码可能是由恶意JS代码收集的。
From Comcast仍使用MITM javascript注入来投放不需要的广告和消息
登录框必须通过HTTPS提供
3.用户名不存在
我发现登录某些网站时，对于不存在的用户名和错误的密码，有两种不同的错误消息。 这有什么问题吗？
绝对！ 知道用户名以这种方式存在后，黑客只需要破解密码即可。 在这个数十亿美元的世界中，我们的手机号码和电子邮件地址没有任何秘密。
4.以纯文本形式存储密码
开发人员如何存储用户密码？ 是的，有些只是将其插入其数据库中。 许多经验不足的开发人员通常在构建网站时都会不加思索地将用户信息保存到数据库中，然后使用SQL来验证用户密码。
如此简单，却如此不安全！
以纯文本形式保存密码意味着
- 开发人员，运营工程师，甚至公司的其他员工都可以直接访问用户密码！
- 发生数据泄露时，黑客会知道大量密码。
- 在不同平台上重用密码的所有用户帐户也有危险！
5.将密码存储在哈希中
一些开发人员认为，单向哈希是一种加密密码的好方法，黑客无法恢复原始密码。 那是个错误的主意。 尽管安全哈希算法是不可逆的，但密码哈希是可逆的。
这是因为哈希算法（例如MD5，SHA1）始终针对相同的密码计算相同的结果。 看一下“ MySQL.users”表，相同密码的哈希值是否相同？
您可能知道，也可能不知道，有些人正在计算所有密码哈希并将其放在Internet上免费下载。 到目前为止，已经计算出9个符号内所有字母数字组合的密码，总共1TB数据。 那么您的密码有多少个符号？
也许您会认为，在如此庞大的数据库中通过哈希查找密码并不容易。 当没有这种彩虹表技术时，您是正确的。
6.哈希组合
如果一个哈希无效，那么哈希组合又如何呢？
- md5（sha1（密码））
- sha1（sha1（密码））
- md5（sha1（md5（md5（密码）+ sha1（密码））+ md5（密码）））
不要那样做 实际上，哈希组合通常会使它变弱而不是变强。 例如，将已被证明是不安全的MD5与相对更安全的SHA1结合使用，可能会比仅SHA1安全性低。
7.正确的密码存储方式
那么，什么是正确的密码存储方式？
撒盐。 首先在密码中加盐，然后计算哈希值。 这是示例代码。
首先，生成一个安全的随机盐，然后计算“盐+密码”的哈希，最后保存盐和哈希。 是的，盐以纯文本格式与哈希一起存储。
在对用户进行身份验证时，我们会得到相同的结果并计算哈希值，然后将结果与数据库中存储的哈希值进行比较。
但是，这安全吗？ 如果操作不当，仍然不会。 有一些常见的错误，
（1）再利用盐
在程序中写一个随机数作为盐，以减轻读取数据库的负担。 这不能作为盐！ 相同的密码仍共享相同的哈希。
不仅每个用户必须拥有唯一的盐，而且每次用户重设密码时，盐都必须重新生成。
（2）用短盐
让我们这样想。 如果salt只有1位，则计算的哈希将仅具有2个可能的结果。 如果salt有2位，则可能有4个结果。 这意味着，盐越长，哈希将越安全。
如今，rainbow表已被计算为10个符号的密码。 建议盐应至少为128位，最好为256位。
这是否意味着1024位会更好？ 并不是的。 因为SHA256的哈希值只有256位。 盐不必长于哈希。
8.更安全
如果您不介意在认证密码上花费更多的CPU /内存，则可以使用非常耗资源的哈希算法（例如PDKDF2，bcrypt等）来替换普通的哈希函数。破解密码将花费更多。
9.如何处理“密码重用攻击”和弱密码？
从https://www.thesun.co.uk/tech/7978489/worst-passwords-most-common-2018/
“密码重用攻击”的通用解决方案是2FA，例如SMS验证码，电子邮件验证码和TOTP（基于时间的一次性密码）。 但是，手机号码克隆，破解电子邮件帐户等也得到了发展，并且TOTP无法防止黑客或员工盗窃造成数据泄露。 网络钓鱼攻击已被证明能够破坏对Google 2FA的保护。
长期以来，Internet服务一直采用密码身份验证。 许多人知道密码对于身份验证而言并不安全，但并不知道这不是唯一的方法。
后端开发人员和Github用户通常使用SSH密钥登录服务器或更新代码，这非常方便且安全。
如果仍然使用密码登录Linux服务器，则应切换到SSH密钥。 我们关闭了所有Linux服务器上的密码身份验证，并且仅在我以前的公司中使用过密钥。
简而言之，它利用了公钥算法的优势。
（1）将用户的公钥放在服务器上。
（2）登录时，用户使用其私钥加密（或签名）随机数据。
（3）服务器使用用户的公钥解密数据（或验证签名），并检查解密结果是否匹配。
公钥身份验证比密码身份验证和TOTP具有很大的优势。 即使黑客转储数据库，他们也只能获取只能用于认证用户的公共密钥，而不能用于登录，而不能使用它们登录或攻击共享同一密码的其他平台。
iPhone的最大优点之一就是它的安全性。 App沙箱机制可确保内部存储的数据也很安全。
来自https://www.cse.wustl.edu/~jain/cse571-14/ftp/ios_security/index.html
因此，许多应用程序开发人员使用UserDefaults将密码以纯文本格式保存在Preferences plist文件中，或者干脆写在文件中。
有两个安全问题需要注意：
（1）iPhone或iOS只是更多，但并不总是安全的。 许多用户仍在使用旧的iOS，该iOS可能具有许多安全漏洞。 几年前，联邦调查局利用iOS 9中的漏洞破解了恐怖分子的iPhone 5C。
（2）默认情况下，存储在iOS应用中的文件会通过iCloud自动备份。 iCloud服务没有良好的安全历史。 我们每年都会阅读有关iCloud数据泄露的新闻。 因此，必须通过URL / NSURL的isExcludedFromBackup键禁止敏感文件备份。
如果要存储密码等敏感信息，则应使用iOS的Keychain Services 。 iOS的Keychain Services不同于iCloud钥匙串。 前者是一项存储应用程序重要数据的服务，并且不会通过iCloud进行同步。 后者是iCloud向Apple用户提供的功能。 人们可能会因类似的名字而感到困惑。
与SQL一样，您需要先创建一个查询，然后调用API，而Ctrl-C和Ctrl-V并不复杂。
iOS生物特征认证
2013年推出的iPhone 5S支持指纹支付，实现了更高的生物识别身份验证安全标准。 以下是Apple提供的iPhone安全体系结构。
使用Touch ID进行身份验证时，Touch ID传感器扫描指纹并将图像数据直接发送到Secure Enclave进行身份验证，而无需通过iOS操作系统发送。 然后， Secure Enclave通过iOS操作系统将身份验证结果发送到应用。 在整个过程中，指纹数据会直接传输到所连接硬件电路中的Secure Enclave 。 因此，该应用程序无法获取指纹数据。 人脸ID也可以像这样工作，除了它可以扫描人脸的3D数据。
此外，为了提高iPhone的安全性，Apple在生产过程中将指纹传感器芯片与iPhone内部的安全芯片配对，以确保无法通过更换指纹传感器芯片来访问Secure Enclave的数据。 替换后的“主页”按钮无法与原始的Secure Enclave配对。 由于存在这种配对，因此某些二手iPhone上可能无法使用Touch ID。
生物特征认证登录原理
适用于iOS的Secure Enclave可以安全地创建密钥对，并使用私钥对数据进行签名。 Secure Enclave创建的私钥仅存储在内部，并且不允许任何程序读取它。
那么，我们如何使用iOS的硬件公钥功能来实现安全登录？
（1）注册流程
当应用程序要求Secure Enclave创建密钥对时，iOS会提示用户进行授权。 用户可以通过Touch ID或Face ID身份验证进行授权。 然后，该应用将公钥发送到服务器。 私钥存储在Secure Enclave内部，应用程序无法获取。
（2）登录过程
登录很简单。 当用户触摸“登录”按钮时，该应用会要求Secure Enclave为登录请求和iOS提示授权创建签名。 用户确认授权后，签名就会发送到应用程序。 然后，该应用将其与登录请求一起发送到服务器进行身份验证。
使用生物特征认证登录更安全
如果该应用程序充分利用了iOS的安全功能，则与使用Keychain Services存储的密码相比，通过本地生物身份验证在Secure Enclave使用私钥创建签名，然后远程使用公钥来验证签名更加安全。 Keychain Services 。
（1）私钥仅存储在Secure Enclave内部，并且永远不会暴露给应用程序或iOS。 这意味着，即使该应用程序存在漏洞或iOS沙箱损坏，黑客仍无法获取私钥来窃取用户身份。 相反，当应用或iOS受到威胁时，保存在“ Keychain Services密码很容易受到攻击。
（2）如果服务器端遭到黑客攻击，则使用公钥身份验证的用户身份仍然是安全的，而不仅使用密码身份验证此应用程序/服务的用户身份是不安全的，而且共享同一密码的其他平台上的用户身份也将受到保护。也都处于危险之中。
某些应用程序可以启用指纹登录，而无需提示用户授权。 因此，显然，他们没有利用iPhone强大的硬件签名功能。
Secure Enclave的安全性
Secure Enclave可能是当今可用的最安全的技术，但并不是100％。 实际上，Apple保留从Secure Enclave读取数据的功能，并且他们还可以通过系统更新来修改Secure Enclave的操作系统。
- https://crackstation.net/hashing-security.htm
- https://zh.wikipedia.org/wiki/MD5
- https://zh.wikipedia.org/wiki/Cryptographic_hash_function
- https://zh.wikipedia.org/wiki/SHA-1
- https://zh.wikipedia.org/wiki/盐_（密码学）
- https://project-rainbowcrack.com/table.htm
- https://support.apple.com/zh-CN/HT208108
- https://support.apple.com/zh-CN/HT204587
- https://developer.apple.com/security/
- https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys
- https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1
- https://developer.apple.com/documentation/security/keychain_services/keychain_items/adding_a_password_to_the_keychain