TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why we are still using PBKDF2-SHA256 despite being aware of its limitations

85 点作者 pldpld超过 4 年前

9 条评论

henns超过 4 年前
I think this misses the point: we should be doing everything we can to deprecate PBKDF2 because of the big differences between what a specialized attacker can do vs. the defender.<p>As a rough estimate: a $2k bitcoin miner can do 2^45 SHA-256 hashes&#x2F;sec whereas your $2k laptop can do 2^16 hashes&#x2F;sec; the attacker has ~a billion x advantage over you that can be multiplied based on their funding. At that point, doing even 10,000 PBKDF2 hashes may not make much of a difference.<p>argon2, scrypt and other memory hard password hashing algorithms reduce the orders of magnitude advantages of the attacker by requiring RAM. Attackers might be able to purchase RAM cheaper than the defender, but nothing close to a billion times cheaper.<p>Addressing concern #3 (want to have a password set on a laptop that decodes in a reasonable amount of time on a low-end smartphone), you could restrict the RAM to some small amount (like 256MB) if you anticipate needing to use a low-end device. This will still be a vast reduction in the attacker&#x27;s advantage over PBKDF2.
评论 #26231160 未加载
评论 #26230022 未加载
评论 #26230115 未加载
xxpor超过 4 年前
My threat model isn&#x27;t a directed attack, it&#x27;s DB dumps with unhashed or unsalted passwords from random websites. I want to use a unique password on every site, and password managers provide a convenient way of doing that.<p>Even if every BW vault leaked, if it takes half a day to run through 8 a-zA-Z0-9, it&#x27;s not practical to do that for every vault. On the other hand, if I&#x27;m being targeted, even increasing that to a month wouldn&#x27;t really matter.<p>Every &quot;critical&quot; site I use also supports u2f 2fa, which I&#x27;ve turned on. So even if they got my passwords, there&#x27;s the 2nd factor they don&#x27;t have.<p>tl;dr: Just use a damn password manager, even one that has arguable issues such as this improves the average person&#x27;s security by orders of magnitude.
评论 #26229980 未加载
评论 #26229849 未加载
woliveirajr超过 4 年前
If I understood correctly, the points are:<p>- using longer passwords (or salts) is better than increasing the number of rounds<p>- having the same database on different devices (top-CPU x older cellphone) have impacts on the performance for the user but not for the attacker (as a powerful hardware will be used)<p>Seems fair, for the average user. And the top user will prefer a longer password anyway.
评论 #26231360 未加载
tialaramex超过 4 年前
A lot of the sub-threads seem to have decided to talk about using PBKDF2-SHA256 as a password hash like crypt(), which actually isn&#x27;t what the linked report is about. PBKDF2, as its name suggests, is a key derivation function. We can use these as password hashes, and people do, but we can also use them to turn any human memorable password (like &quot;stonks&quot;, &quot;S&amp;SMBMBbc&amp;wem&quot; or &quot;fzg76@PRU385!&quot;) into a nice 128-bit or 256-bit symmetric encryption key and that&#x27;s what they&#x27;re doing in tools like Bitwarden or 1Password.<p>In this role, you very much have a practical option to just pick a decent password. &quot;stonks&quot; is not a good password, the second one is a Rhianna lyric (&quot;... but chains and whips excite me&quot;) but the third one is a pretty obscure reference and it&#x27;s neither likely that your adversary would &quot;guess&quot; it nor that the sort of brute force attacks envisioned would hit this random looking 13 character password.<p>Anyway, even as a password hash I&#x27;ve made the argument previously that stronger hashes only marginally improve things, far too many of your users will pick &quot;stonks&quot; or if you insist on eight characters maybe &quot;stonks!!&quot; and even if you have Argon2 tuned way up the attacker can reverse that because it&#x27;s too obvious. If your users picked unique random passwords (as they might with tools like Bitwarden or 1Password, even though I personally use zx2c4&#x27;s pass) then it doesn&#x27;t matter if you use a terrible hash like some turn of the century PHP forum using MD5, because that&#x27;s still safe with such passwords.
dheera超过 4 年前
What&#x27;s wrong with PBKDF2-SHA256? I use PBKDF2-HMAC-SHA256 for an almost-stateless password manager.
评论 #26229941 未加载
评论 #26229873 未加载
评论 #26230228 未加载
评论 #26229345 未加载
评论 #26229349 未加载
fuoqi超过 4 年前
The model of hashing user plaintext passwords on server-side is itself a deeply flawed one. User password and master keys derived out of it should NEVER leave user-controlled computer. For authentication password-authenticated key agreement protocols [0] should be used, anything but it means that service does not treat user security as a high enough priority.<p>[0]: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Password-authenticated_key_agreement" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Password-authenticated_key_agr...</a>
评论 #26230154 未加载
评论 #26229907 未加载
评论 #26230934 未加载
goalieca超过 4 年前
Pbkdf2 itself is not the best for the same reasons why sha256 was listed. I do agree that argon2 is better.
评论 #26229914 未加载
infogulch超过 4 年前
User-defined passwords are a bad choice for an encryption KDF. I&#x27;m not disagreeing with sibling xxpor&#x27;s tl;dr that worse is better here; getting everyone on password managers would be a huge net win for personal security. But debating the choice of KDF is missing the elephant in the room: that user passwords simply lack enough entropy for use as secure key material. It&#x27;s like debating which kind of paper you should use to repair a huge hole in your bunker with a paper mache.<p>That said, asking the user to manually type full-size generated keys between devices is simply a nonstarter.<p>But what if the user stored their passwords in a private Matrix room? Matrix&#x27; solution to sharing encryption keys between devices is by being the communication channel by which users approve new devices from existing devices; upon approval the room&#x27;s encryption key is sent to the new device encrypted using the new device&#x27;s public key. That is, the room key can only ever be seen by the devices themselves. (I think this is a reasonable summary of encryption in Matrix, please correct me if I&#x27;m mistaken.) This is basically using a Matrix room as a general distributed, encrypted data store. Thoughts?
henriquez超过 4 年前
If it&#x27;s not broke, don&#x27;t fix it. The underlying hasher is most important anyway. Crappy passwords will always be susceptible to rainbow attacks.
评论 #26229336 未加载