Cuando desarrollamos un sitio web o una aplicación, el primer problema que debemos resolver es cómo transmitir y almacenar de forma segura las contraseñas de los usuarios . Los incidentes de fuga de bases de datos de usuarios de algunas grandes empresas también ocurren de vez en cuando, lo que genera impactos negativos muy grandes. Por lo tanto, cómo transmitir y almacenar de forma segura las contraseñas de los usuarios es una base esencial para todos los programadores. Este artículo aprenderá con usted cómo transmitir y almacenar de forma segura las contraseñas de los usuarios.
1. Cómo transmitir de forma segura la contraseña de un usuario
Para rechazar que las contraseñas de los usuarios se ejecuten sin protección en Internet, podemos pensar fácilmente en usar el protocolo https, así que primero revisemos el conocimiento sobre https ~
1.1 protocolo https
- "Tres riesgos de HTTP"
¿Por qué usar el protocolo https? ¿No es http delicioso ?Porque http transmite información en texto claro. Si utiliza el protocolo http en el vasto océano de la red, existen los siguientes tres riesgos principales:
- Riesgo de espionaje/olfateo: los datos de comunicación pueden ser interceptados por terceros.
- Riesgo de manipulación de datos: después de que el tercero obtenga los datos de comunicación, realizará modificaciones maliciosas.
- Riesgo de Falsificación de Identidad: Terceros pueden participar en las comunicaciones suplantando la identidad de otra persona.
Está bien transmitir información sin importancia, pero es terrible transmitir información confidencial, como las contraseñas de los usuarios. Por lo tanto, el protocolo https se usa generalmente para transmitir información de contraseña de usuario.
- "principio https"
¿Cuál es el principio de https? ¿Por qué puede resolver los tres principales riesgos de http?
https = http + SSL/TLS, SSL/TLS es un protocolo de cifrado de la capa de transporte, que proporciona cifrado de contenido, autenticación de identidad y verificación de integridad de datos para resolver el problema de seguridad de la transmisión de datos.
Para profundizar en la comprensión del principio de https, revisemos el proceso de solicitud de un https completo ~
- El cliente inicia una solicitud https
- El servidor debe contar con un conjunto de certificados digitales, los cuales pueden ser realizados por uno mismo o aplicados a la autoridad. Este conjunto de certificados es en realidad un par de claves públicas y privadas.
- El servidor envía su propio certificado digital (incluida la clave pública, la autoridad emisora del certificado, etc.) al cliente.
- 客户端收到服务器端的数字证书之后，会对其进行验证，主要验证公钥是否有效，比如颁发机构，过期时间等等。如果不通过，则弹出警告框。如果证书没问题，则生成一个密钥（对称加密算法的密钥，其实是一个随机值），并且用证书的公钥对这个随机值加密。
- 客户端会发起https中的第二个请求，将加密之后的客户端密钥(随机值)发送给服务器。
- 服务器接收到客户端发来的密钥之后，会用自己的私钥对其进行非对称解密，解密之后得到客户端密钥，然后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。
- 服务器将加密后的密文返回给客户端。
- 客户端收到服务器发返回的密文，用自己的密钥（客户端密钥）对其进行对称解密，得到服务器返回的数据。
- 「https一定安全吗？」
https的数据传输过程，数据都是密文的，那么，使用了https协议传输密码信息，一定是安全的吗？其实不然
- 比如，https 完全就是建立在证书可信的基础上的呢。但是如果遇到中间人伪造证书，一旦客户端通过验证，安全性顿时就没了哦！平时各种钓鱼不可描述的网站，很可能就是黑客在诱导用户安装它们的伪造证书！
- 通过伪造证书，https也是可能被抓包的哦。
1.2 对称加密算法
既然使用了https协议传输用户密码，还是 「不一定安全」，那么，我们就给用户密码 「加密再传输」 呗~
加密算法有 「对称加密」 和 「非对称加密」 两大类。用哪种类型的加密算法 「靠谱」 呢？
对称加密：加密和解密使用 「相同密钥」 的加密算法。
常用的对称加密算法主要有以下几种哈：
如果使用对称加密算法，需要考虑 「密钥如何给到对方」 ，如果密钥还是网络传输给对方，传输过程，被中间人拿到的话，也是有风险的哦。
1.3 非对称加密算法
再考虑一下非对称加密算法呢？
「非对称加密：」 非对称加密算法需要两个密钥（公开密钥和私有密钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。
常用的非对称加密算法主要有以下几种哈：
如果使用非对称加密算法，也需要考虑 「密钥公钥如何给到对方」 ，如果公钥还是网络传输给对方，传输过程，被中间人拿到的话，会有什么问题呢？「他们是不是可以伪造公钥，把伪造的公钥给客户端，然后，用自己的私钥等公钥加密的数据过来？」 大家可以思考下这个问题哈~
我们直接 「登录一下百度」 ，抓下接口请求，验证一发大厂是怎么加密的。可以发现有获取公钥接口，如下:
再看下登录接口，发现就是RSA算法，RSA就是 「非对称加密算法」 。其实百度前端是用了JavaScript库 「jsencrypt」 ，在github的star还挺多的。
因此，我们可以用 「https + 非对称加密算法（如RSA）」 传输用户密码~
2. 如何安全地存储你的密码？
假设密码已经安全到达服务端啦，那么，如何存储用户的密码呢？一定不能明文存储密码到数据库哦！可以用 「哈希摘要算法加密密码」 ，再保存到数据库。
哈希摘要算法：只能从明文生成一个对应的哈希值，不能反过来根据哈希值得到对应的明文。
2.1 MD5摘要算法保护你的密码
MD5 是一种非常经典的哈希摘要算法，被广泛应用于数据完整性校验、数据（消息）摘要、数据加密等。但是仅仅使用 MD5 对密码进行摘要，并不安全。我们看个例子，如下：
public class MD5Test {
public static void main(String[] args) {
String password = "abc123456";
System.out.println(DigestUtils.md5Hex(password));
}
}
运行结果： 0659c7992e268962384eb17fafe88364
在MD5免费破解网站一输入，马上就可以看到原密码了。。。
试想一下，如果黑客构建一个超大的数据库，把所有20位数字以内的数字和字母组合的密码全部计算MD5哈希值出来，并且把密码和它们对应的哈希值存到里面去（这就是 「彩虹表」 ）。在破解密码的时候，只需要查一下这个彩虹表就完事了。所以 「单单MD5对密码取哈希值存储」 ，已经不安全啦~
2.2 MD5+盐摘要算法保护用户的密码
那么，为什么不试一下MD5+盐呢？什么是 「加盐」？
在密码学中，是指通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符，这种过程称之为“加盐”。
用户密码+盐之后，进行哈希散列，再保存到数据库。这样可以有效应对彩虹表破解法。但是呢，使用加盐，需要注意一下几点：
- 不能在代码中写死盐，且盐需要有一定的长度（盐写死太简单的话，黑客可能注册几个账号反推出来）
- 每一个密码都有独立的盐，并且盐要长一点，比如超过 20 位。(盐太短，加上原始密码太短，容易破解)
- 最好是随机的值，并且是全球唯一的，意味着全球不可能有现成的彩虹表给你用。
2.3 提升密码存储安全的利器登场，Bcrypt
即使是加了盐，密码仍有可能被暴力破解。因此，我们可以采取更 「慢一点」 的算法，让黑客破解密码付出更大的代价，甚至迫使他们放弃。提升密码存储安全的利器~Bcrypt，可以闪亮登场啦。
De hecho, Spring Security ha abandonado MessageDigestPasswordEncoder y recomienda usar BCryptPasswordEncoder, que es BCrypt, para el hash de contraseñas. BCrypt es un algoritmo diseñado para almacenar contraseñas, que es mucho más lento que MD5.
Veamos un ejemplo para comparar:
public class BCryptTest {
public static void main(String[] args) {
String password = "123456";
long md5Begin = System.currentTimeMillis();
DigestUtils.md5Hex(password);
long md5End = System.currentTimeMillis();
System.out.println("md5 time:"+(md5End - md5Begin));
long bcrytBegin = System.currentTimeMillis();
BCrypt.hashpw(password, BCrypt.gensalt(10));
long bcrytEnd = System.currentTimeMillis();
System.out.println("bcrypt Time:" + (bcrytEnd- bcrytBegin));
}
}
resultado de la operación:
md5 time:47
bcrypt Time:1597
Una comparación aproximada muestra que BCrypt es docenas de veces más lento que MD5, y si los piratas informáticos quieren usar la fuerza bruta, costará docenas de veces. Por lo tanto, en general, se recomienda utilizar Bcrypt para almacenar las contraseñas de los usuarios.
3. Resumen
- Por lo tanto, el protocolo https + algoritmo de cifrado asimétrico (como RSA) se usa generalmente para transmitir contraseñas de usuario Para ser más seguro, se puede construir un factor aleatorio en la parte delantera.
- Use BCrypt + salt para almacenar contraseñas de usuario.
- Cuando se percibe el peligro del cracking por fuerza bruta, se utilizan mecanismos de defensa como "verificación de SMS abierta, código de verificación gráfico y bloqueo temporal de la cuenta" para resistir el cracking por fuerza bruta.