在开发CloudEver应用程序时，我了解了 iOS生物识别身份验证 技术，包括Face ID和Touch ID。然后，我查看了一些具有指纹登录功能的应用程序，发现其中许多应用程序没有充分利用iOS安全功能。我想与社区分享我获得的知识，我希望我们使用的应用程序会越来越安全。
为什么我们需要身份验证？
大多数早期的互联网服务主要为每个人提供静态内容，而无需登录。后来，出现了一些动态服务，例如论坛，聊天室等。当时，身份验证需要密码。从那时起，密码身份验证已被许多互联网服务广泛采用。
您可能还喜欢： 身份验证和授权：掌握安全性.
密码身份验证的安全问题
但是，要确保密码身份验证的安全性并不容易。如果用户名和密码被他人破解，可能会泄露用户信息甚至导致金钱损失。那么，实施密码身份验证的常见错误是什么？
1. 使用 HTTP 而不是 HTTPS 进行密码身份验证
过去，一些知名的互联网公司设计了自己的方法来加密浏览器中的密码。然后，他们将它们提交给他们的服务器，以便通过HTTP进行身份验证。后来，他们发现这是错误的。现在，几乎所有的大公司都转向HTTPS。
我们必须使用 HTTPS 来验证用户名和密码。
2. 使用 HTTPS 进行密码身份验证，但通过 HTTP 显示登录框
一些开发人员认为，只要用户名和密码通过 HTTPS传输，它们就不会被披露。因此，它们通过 HTTP 提供登录页面以节省服务器资源。但是，这是一个非常常见的错误。黑客可能会通过HTTP将恶意JavaScript嵌入到登录页面中，即MITM JavaScript注入。用户名和密码可能被恶意 JavaScript 代码收集。
MITM JavaSrcript 注入来自 康卡斯特仍然使用MITMJavaScript注入来提供不需要的广告和消息
登录框必须通过 HTTPS 提供
3. 用户名不存在
我发现在登录某些网站时，存在两个不同的错误消息，分别是不存在的用户名和不正确的密码。这有什么问题吗？
绝对！在知道用户名以这种方式存在后，黑客只需要破解密码即可。在这个数十亿的世界中，我们的手机号码和电子邮件地址没有任何秘密。
使用
4.以纯文本形式存储密码
开发人员如何存储用户密码？是的，有些人只是将其插入到他们的数据库中。许多没有经验的开发人员在构建网站时通常会不假思索地将用户信息保存到数据库中，然后使用 SQL 验证用户密码。
如此简单，却如此不安全！
以纯文本形式保存密码意味着：
- 开发人员，运营工程师，甚至公司的其他员工都可以直接访问用户密码！
- 当发生数据泄露时，黑客会知道海量的密码。
- 在不同平台上重复使用密码的用户的所有帐户也处于危险之中！
5.将密码存储在哈希中
一些开发人员认为单向哈希是加密密码的好方法，黑客无法恢复原始密码。这是一个错误的想法。尽管安全哈希算法是不可逆的，但密码哈希是可逆的。
这是因为哈希算法（如 MD5、SHA1）始终为同一密码计算相同的结果用户“表;相同密码的哈希值是否相同？
您可能知道也可能不知道，但是有些人正在计算所有密码哈希并将它们放在Internet上免费下载。到目前为止，已经计算了9个符号内所有字母数字组合的密码，总共1TB的数据。那么，您的密码有多少个符号？
也许你会认为在如此庞大的数据库中通过哈希找到密码并不容易。当没有这样的彩虹表技术时，你是对的。
6. 哈希组合
如果一个哈希不起作用，那么哈希组合呢？
- MD5（SHA1（密码））.
- SHA1（SHA1（密码））.
- md5（sha1（md5（md5（password） + sha1（password）） + md5（password）））。
别这样。实际上，哈希组合通常会使密码变弱，而不是更强。例如，将已被证明不安全的MD5与相对安全的SHA1结合使用，可能不如仅SHA1安全。
7.存储密码的正确方法
那么，存储密码的正确方法是什么？
用盐散列。首先在密码中添加盐，然后计算哈希值。这是一个示例代码。
首先，生成一个安全的随机盐，然后计算 的 salt+password哈希值，最后保存盐和哈希值。是的，盐与哈希一起以纯文本形式存储。
在对用户进行身份验证时，我们获取盐并以相同的方式计算哈希，然后将结果与数据库中存储的哈希进行比较。
但是，这安全吗？仍然没有，如果你做得不恰当。有一些常见的错误，
-
重用盐：在程序中写一个随机数作为盐，减轻读取数据库的负担。这不能作为盐！相同的密码仍共享相同的哈希值。不仅每个用户都必须有一个唯一的盐，而且每次用户重置他/她的密码时，盐都必须重新生成。
-
使用简短的盐：让我们这样想。如果盐只有一位 ，则计算出的哈希将只有 2 个可能的结果。如果盐有两个位，则有四种 可能的结果。这意味着，盐越长，哈希就越安全。
如今，彩虹表已经计算到10个符号的密码
这是否意味着 1024 位会更好？没有。因为SHA256的哈希只有256位。盐不需要比哈希长。
8. 更加安全
如果您不介意在验证密码时消耗更多的 CPU/内存，您可以将普通的哈希函数替换为非常消耗资源的哈希算法，例如 PDKDF2、bcrypt 等。破解这些算法设置的密码将花费更多。
9. 处理“密码复用攻击”和弱密码？
从 https://www.thesun.co.uk/tech/7978489/worst-passwords-most-common-2018/
“密码复用攻击”的一般解决方案是2FA，例如短信验证码，电子邮件验证码和TOTP（基于时间的一次性密码）。但是手机号码克隆、破解电子邮件帐户等技术。也发展了，TOTP 无法防止黑客或员工盗窃的数据泄露。网络钓鱼攻击已被证明能够破坏谷歌2FA的保护。
密码不是身份验证的来源
长期以来，互联网服务都采用了密码认证。许多人知道密码对于身份验证不安全，但不知道这不是唯一的方法。
公钥 认证
后端开发人员和 Github 用户通常使用 SSH 密钥登录服务器或更新代码，非常方便和安全。
如果您仍然使用密码登录Linux服务器，则应切换到SSH密钥。我们关闭了所有 Linux 服务器上的密码身份验证，并且仅在我以前的公司使用密钥。
简而言之，它利用了公钥算法的优势。
-
将用户的公钥放在服务器上。
-
登录时，用户使用他的私钥对随机数据进行加密（或签名）。
-
服务器使用用户的公钥解密数据（或验证签名），并检查解密结果是否匹配。
公钥身份验证比密码身份验证和 TOTP 具有很大的优势。即使黑客转储数据库，也只能获取只能用于验证用户身份的公钥，不能用于登录，但不能使用它们登录或攻击共享相同密码的其他平台 应用程序沙盒机制可确保内部存储的数据也是安全的。
从 https://www.cse.wustl.edu/~jain/cse571-14/ftp/ios_security/index.html。
因此，许多应用程序开发人员使用 UserDefaults 将密码以纯文本形式保存在首选项plist文件中，或者只是写入文件。
有两个安全问题需要注意：
-
iPhone或iOS只是更多，但并不总是安全的。许多用户仍在使用旧的iOS，这可能有许多安全漏洞。几年前，FBI利用iOS 9中的漏洞破解了恐怖分子的iPhone 5C。
-
默认情况下，存储在iOS应用程序中的文件会自动通过iCloud备份。iCloud服务没有良好的安全历史。我们每年都会阅读有关iCloud数据泄露的新闻。因此，必须禁止敏感文件由
在iOS上存储密码的正确方法
如果要存储密码等敏感信息，则应使用 Keychain Services iOS Keychain Services 版本。前者是为应用程序存储重要数据的服务，并且不通过iCloud同步。后者是iCloud为苹果用户提供的功能。人们可能会因为名称相似而感到困惑。
与 SQL 一样，您需要先创建一个查询，然后调用 API，这不会因 Ctrl-C 和 Ctrl-V 而复杂化。
iOS 生物识别身份验证
2013年推出的iPhone 5S支持指纹支付，实现了更高的生物识别认证安全标准。以下是苹果的iPhone安全架构。
使用 Touch ID 进行身份验证时，Touch ID 传感器会扫描指纹并将图像数据 Secure Enclave 直接发送到进行身份验证，而无需通过 iOS 操作系统发送。然后， Secure Enclave 通过iOS操作系统将身份验证结果发送到应用程序。
在整个过程中，指纹数据直接 Secure Enclave 传输到连接的硬件电路中 Face ID也是这样工作的，除了它扫描面部的3D数据。
此外，为了提高iPhone的安全性，苹果在生产过程中将指纹传感器芯片与iPhone内部的安全芯片配对，通过更换指纹传感器芯片来确保无法访问数据 Secure Enclave 。更换的主页按钮无法与原始 Secure Enclave.由于这种配对，Touch ID在某些二手iPhone上可能不可用。
生物认证登录
Secure Enclave 对于 iOS 可以安全地创建密钥对并使用私钥对数据进行签名。创建的 Secure Enclave 私钥只存储在里面，不允许任何程序读取它。
那么我们如何利用iOS的硬件公钥功能来实现安全登录呢？
注册流程
当应用要求 Secure Enclave 创建密钥对时，iOS 会提示用户进行授权。用户可以通过触控 ID 或面容 ID 认证进行授权。然后，应用将公钥发送到服务器。私钥存储在内部 Secure Enclave ，无法由应用程序获取。
登录流程
登录很简单。当用户触摸“登录”按钮时，应用会要求 Secure Enclave 为登录请求创建签名，iOS 会提示进行授权。用户确认授权后，签名将发送到应用。然后，应用将其与登录请求一起发送到服务器进行身份验证。
使用生物识别身份验证登录的优势
如果应用程序充分利用 iOS 的安全功能，则与使用存储在 中的Keychain Services密码相比，通过本地生物识别身份验证创建带有私钥Secure Enclave的签名，然后使用公钥远程验证签名更安全。
-
私钥仅存储在内部
Secure Enclave，永远不会暴露给应用程序甚至iOS。这意味着，即使应用程序存在漏洞或iOS沙箱被破坏，黑客仍然无法获得私钥来窃取用户身份。
如果服务器端被黑客入侵，使用公钥身份验证的用户身份仍然是安全的，而不仅此应用程序/服务的用户身份在密码身份验证中不安全，而且共享相同密码的其他平台上的用户身份也都处于危险之中。
某些应用可以在不提示用户授权的情况下启用指纹登录。因此，显然，他们没有利用iPhone强大的硬件签名功能。
的安全性 Secure Enclave
Secure Enclave 可能是当今最安全的技术，但它不是 100%。事实上，Apple保留从中 Secure Enclave读取数据的能力，并且他们还可以通过系统更新来修改操作系统 Secure Enclave 。
延伸阅读
- TLS 安全性：TLS / SSL解释。
