如何正确进行密码验证?

译者 | baron

审校 | 孙淑娟 梁策

网络安全问题日益严重,即使是大型知名企业也面临敏感用户数据泄露的问题。这些问题可能包括对数据库的未经授权的访问以及日志的泄露等等。此外,我们也经常遇到零日漏洞攻击(Zero-Day Vulnerabilities),所有这些都对用户自身安全和企业声誉产生了负面影响。本文将介绍如何使用密码认证来实现用户认证的数据存储。

一、身份验证 

身份验证是用户确认他是所提供标识符的所有者的过程。最明显和人们最熟悉的身份验证过程是密码身份验证。用户进入登录页面,输入用户名和密码,然后登录。下文将展示如何在服务器上实现身份验证。

认证过程可以用一张图表示:

服务端收到请求后,服务器将使用存储在数据库中的值(在注册期间保存的)检查用户的数据,并判断用户是否可以通过身份验证。如果检查成功,通常会在服务器上创建一个会话,并将其标识符作为 Cookie 在响应中返回。

那么,用户注册时如何保存认证数据呢?

1.将密码存储为纯文本

在这种情况下,数据库中的数据将作为开放数据存储。任何有权访问数据库的人都可以获取用户的密码,比如数据库管理员、支持人员或开发人员。此外,系统中始终存在漏洞风险,可能允许入侵者访问数据库且进行下载和转存。

理想情况下,每项服务都应有其唯一的密码,这样就可以避免在服务中泄露身份验证数据的风险。但由于我们使用的服务如此之多,记住所有密码是不可能的。一种解决方案是密码管理器,但使用的人很少,并且用户倾向于能随处使用的一个或多个密码。当一项服务的数据泄露,使用该密码的其他服务也会受到影响,因此强烈建议不要以纯文本形式保存密码,从而保护用户免受此类问题影响。

2.密码哈希

哈希算法是根据用户密码计算数字摘要的特定函数。该函数的工作原理是可以足够快地从密码中获取哈希值,而无法在足够的时间内完成反向转换。哈希函数有MD5、SHA-1、SHA-256 、SH3-512等。使用这些函数,我们保存到数据库中的不是密码本身,而是使用哈希函数从密码中计算出来的数值摘要值。例如,在 Java 中,使用如下所示操作获取密码的哈希值:

String password ="pa$$word";
MessageDigest md = MessageDigest.getInstance("SHA-256");
byte[] digest = md.digest(password.getBytes());
String hash = new BigInteger(1, digest).toString(16);

作为转换的结果,我们将得到以下值,可以将其保存在数据库中:

6a158d9847a80e99511b2a7866233e404b305fdb7c953a30deb65300a57a0655

这个变体已经好很多了,但它仍有缺点。其中之一是具有相同密码的用户将具有相同的哈希值。如果入侵者获得对数据库的访问权,他就可以根据自己的目的使用数据,同时暴力破解密码的可能性也相当危险。你可以使用流行的密码和哈希来创建数据库(或使用现有数据库),因此可以快速恢复用户密码的值。这也是不推荐这一选项的原因。

3.使用唯一盐(Salt)的密码哈希

针对前一个解决方案的痛点,我们可以使用每个用户唯一的盐。盐是与密码连接的随机值,并从结果中获取哈希函数。

String password ="pa$$word";
String salt ="b0f57dccf7133f7ef3acb09641e5f7a3";

MessageDigest md = MessageDigest.getInstance("SHA-256");

byte[] digest = md.digest((password + salt).getBytes());
String hash = new BigInteger(1, digest).toString(16)

随机盐可以像这样生成:

Random random = new SecureRandom();
byte[] saltBytes = new byte[16];
random.nextBytes(saltBytes);

String salt = new BigInteger(1, saltBytes).toString(16);

这样,我们一次解决了几个问题。首先,具有相同密码的用户将具有不同的盐值,因此哈希函数的值也不同。因为无法应用预先计算的哈希表,入侵者获取密码将更加困难。

4.特殊算法 PBKDF2、BCrypt、SCrypt

最好的选择是使用为散列密码开发的特殊算法。这些算法是自适应的,可以有意让计算时间放慢,以使暴力攻击更加困难。

我们以 BCrypt 算法(实现是 Spring Security 的一部分)为例:

String password ="pa$$word";
String salt = BCrypt.gensalt();

String hash = BCrypt.hashpw(password, salt);

结果是以下哈希值:

$2a$10$alXdzX7lkEp52xiKS7YfuelpoFqz6AsvyBwIEz/BbWghdkmwGqYoy

$2a$ - the hash algorithm identifier
10- number of hashing rounds (2^10=1024)
alXdzX7lkEp52xiKS7Yfue - salt
lpoFqz6AsvyBwIEz/BbWghdkmwGqYoy - hash

为了计算这个函数,我们使用了1024轮哈希。随着时间的推移和计算能力的增长,我们可以增加这个值来保持计算的复杂性。

在对用户进行身份验证时,只需调用检查发送的密码的方法以及存储在数据库中的哈希值:

//plaintext - sent by the user
//hash - loaded from DB
boolean checkpw = BCrypt.checkpw(plaintext, hash);

5.使用 PAKE

通过 PAKE(密码验证密钥协议)系列协议,可以在不传输密码的情况下验证用户是否知道密码。该算法是专门设计的,因此密码本身不被传输,而是使用密码的一些计算的值被传输。如果攻击者获得了数据库的访问权限,哪怕可以窃听客户端和服务器之间的通道,他也无法恢复原始密码值。我们以 PAKE 的 SRP-6a 为例。

登录过程分两步进行,经过数学计算,可以证明客户端输入的密码,而无需传输密码。该协议规范在RFC5054中有详细描述。为了保存认证数据,需要计算v和s的值,其中v是verifier,s是salt 。计算salt的方法我们已经知道,计算verifier的方法则是:

x = H(salt, password)
v = g^x (mod N)

H- 哈希函数(SHA-1、SHA256 等)。

g, N- 可以从RFC5054.Appendix A中选择的常量。需要注意的是,选择的常量和哈希函数在服务器和客户端上必须相同。

salt 和verifier 值可以在客户端和服务器上计算。如果这些值是在客户端计算的,我们根本不会在通信通道上传输密码,但我们也无法检查服务器上的密码策略(长度、通配符数量等)。因此,这些检查也需要传输到客户端。

例如,你可以使用Nimbus SRP 库:

String password ="pa$$word";

SRP6CryptoParams config = SRP6CryptoParams.getInstance(256,"SHA-1");
SRP6VerifierGenerator verifierGenerator = new SRP6VerifierGenerator(config);

byte[] saltBytes = verifierGenerator.generateRandomSalt(16);
String verifier = verifierGenerator.generateVerifier(saltBytes, password.getBytes()).toString(16);

String salt = new BigInteger(saltBytes).toString(16);

结果:

salt:6bb9db1c839bdc59ecbcd0ee12488462
verifier: f28aed4372b1312ccdd6e281c7270be503bac99bff845c41da8189eadf9e4497

这些值必须保存在数据库中,并在以后的客户端身份验证过程中使用。该协议最大的优点是密码不会以任何方式传输到服务器,并且无法从verifier值中恢复原始密码。此外,verifier仅在注册期间传输(如果在客户端计算)并且仅用于身份验证期间的计算。该协议本身可以抵抗 MITM 攻击,这意味着如果有人意外启用了服务器上所有用户请求的日志记录,并且这些日志随后被泄露,密码也不会泄露。此数据在每个会话中计算,不能用于重新输入。

二、结论

正确使用现代用户身份验证方法可以大大降低身份验证数据泄露的可能,但身份验证只是网络安全领域的一个侧面。除此之外,日志请求和日志存储也是值得人们关注的问题。

原文链接:https://dzone.com/articles/password-authentication-how-to-do-it-correctly

译者介绍

baron,IDC.NET社区编辑,具有九年手机安全/SOC底层安全开发经验,擅长TrustZone/TEE安全产品的设计和开发。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/148696.html<

(0)
管理的头像管理
上一篇2025-03-12 06:47
下一篇 2025-03-12 06:48

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注