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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

How To Safely Store A Password (2010)

93 点作者 baddate超过 4 年前

19 条评论

skrebbel超过 4 年前
This blog post was instrumental in convincing large swaths of programmers 10 years ago why normal hashing doesn&#x27;t cut it. This was in a time that PHP code snippets doing md5($password) were widespread. If people were even hashing passwords at all. It was a time when lots of crypto was hard to use for programmers, and the jargon gap between cryptographers and programmers was even bigger than it was now. A blog post that unambiguously told people what to was uncommon and much needed.<p>This post truly is internet history. Complaining that there&#x27;s alternatives today that solve the same problem better than bcrypt is beside the point. The fundamental insight hasn&#x27;t changed, only the best available algorithm.
评论 #25290508 未加载
Ciantic超过 4 年前
With password storing, you want to cover your ass. One way to do it is follow guidelines of known authority, e.g. NIST or OWASP.<p>OWASP has nice document: <a href="https:&#x2F;&#x2F;cheatsheetseries.owasp.org&#x2F;cheatsheets&#x2F;Password_Storage_Cheat_Sheet.html" rel="nofollow">https:&#x2F;&#x2F;cheatsheetseries.owasp.org&#x2F;cheatsheets&#x2F;Password_Stor...</a><p>It boils down to this:<p>&gt; Bcrypt is the most widely supported of the algorithms and should be the default choice unless there are specific requirements for PBKDF2, or appropriate knowledge to tune Argon2.
评论 #25289466 未加载
Straw超过 4 年前
Bcrypt doesn&#x27;t have memory-hardness, so has high susceptibility to ASIC attacks. In particular, it incurs the same or lower cost factor on the attacker than the user.<p>More recent designs such as scrypt and Argon2 force high memory usage as well as computation time, incurring little cost on the users but making ASIC and GPU attacks significantly less cost-effective.<p>Of course, any of these will still give better protection than plain cryptographic hashes.
评论 #25288623 未加载
评论 #25288520 未加载
评论 #25293257 未加载
评论 #25288344 未加载
OliverJones超过 4 年前
For what it&#x27;s worth the php implementation of password hashing offers a function to determine whether it&#x27;s time to rehash a password. <a href="https:&#x2F;&#x2F;www.php.net&#x2F;manual&#x2F;en&#x2F;function.password-needs-rehash.php" rel="nofollow">https:&#x2F;&#x2F;www.php.net&#x2F;manual&#x2F;en&#x2F;function.password-needs-rehash...</a><p>The idea is to alert an application program to the need to regenerate the hash at the time it has the plaintext password in hand (when the user has just presented it for login).<p>This is a great idea; rehashing a long-standing bcrypt password with a larger work factor makes it safer.<p>And, an extension or new version of the runtime can add a new hashing scheme.<p>It would be sweet if other password-hashing APIs added the same kind of thing. User accounts can last far longer than LTS versions of software runtimes, and this can help future-proof them.
评论 #25288858 未加载
_wldu超过 4 年前
I cracked a lot of sha512crypt and PBKDF2-HMAC-SHA256 hashes with a cheap GPU at Defcon this year. Here&#x27;s the write-up.<p>(Cracking Passwords with Cheap Hardware at Defcon):<p><a href="https:&#x2F;&#x2F;github.com&#x2F;62726164&#x2F;cmiyc2020" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;62726164&#x2F;cmiyc2020</a>
评论 #25291789 未加载
wagslane超过 4 年前
I recently did a write up on Bcrypt, for anyone who is unfamiliar with it&#x27;s technicalities: <a href="https:&#x2F;&#x2F;qvault.io&#x2F;2020&#x2F;08&#x2F;24&#x2F;bcrypt-step-by-step&#x2F;" rel="nofollow">https:&#x2F;&#x2F;qvault.io&#x2F;2020&#x2F;08&#x2F;24&#x2F;bcrypt-step-by-step&#x2F;</a>
bob1029超过 4 年前
I have started to look at a model where the device itself is the password. How often do we realistically need to concern ourselves with the scenario where multiple users are utilizing the same physical device in 2020?<p>Imagine every device has a cookie&#x2F;token with 256-512 CSPRNG bytes which uniquely identify it. The server uses this as the exclusive means of authentication. For sensitive application scenarios, an in-app PIN mechanism can be used as a soft protective measure (e.g. Robinhood mobile apps use this). The device you initially sign up on can be used to activate additional devices by way of scanning a QR code, offline recovery codes, SMS, etc.<p>This model makes it so that a user has no username or password to remember. They just need to make sure they have a backup device and&#x2F;or offline recovery options available. I find that side-stepping the problem altogether might be the best solution for all involved. Users loathe remembering passwords. Developers screw up password hashing constantly. Malicious actors should grow to strongly dislike this approach.<p>This also provides a much stricter chain of custody over how additional devices are added to an account. You have to already have a trusted device to bring another. Making the &quot;What you have&quot; (device) the first factor, and the &quot;What you know&quot; (i.e. pin code) the second factor seems to work out a lot better looking forward.
评论 #25289546 未加载
评论 #25293612 未加载
mijoharas超过 4 年前
So there&#x27;s a bunch of people here saying Argon2, whereas I thought one of the current best recommendations was scrypt. Can someone explain the trade-off between them?<p>Why would you pick one over the other? Or are both &quot;pretty much fine&quot; for most workloads and a casual user shouldn&#x27;t worry too much?
评论 #25289498 未加载
评论 #25291459 未加载
dang超过 4 年前
If curious see also<p>2011 <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2716714" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2716714</a><p>2010 <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2004833" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2004833</a><p>Discussed at the time: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1091104" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1091104</a>
rendall超过 4 年前
Several days ago I favorited this comment, which is a list of authentication vendors and open source projects:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25212694" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25212694</a>
edf13超过 4 年前
This works for me...<p><a href="https:&#x2F;&#x2F;www.google.co.uk&#x2F;amp&#x2F;s&#x2F;nakedsecurity.sophos.com&#x2F;2013&#x2F;11&#x2F;20&#x2F;serious-security-how-to-store-your-users-passwords-safely&#x2F;amp&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.google.co.uk&#x2F;amp&#x2F;s&#x2F;nakedsecurity.sophos.com&#x2F;2013...</a><p>(Apologies for the blasted Amp link... on my phone)
jonathanstrange超过 4 年前
Cryptographic hashing decreases entropy because it is based on a compression function. Most password stretching algorithms are not optimal in that respect, especially if they repeatedly lengthen the plaintext before hashing it again.<p>There are constructions to avoid this problem but they are not commonly used.
评论 #25293891 未加载
评论 #25293686 未加载
评论 #25292955 未加载
neallindsay超过 4 年前
Just me quibbling about language, but this article should really be titled &quot;How To Safely Store A Hash That Lets You Verify A Password&quot;. Nobody who knows what they&#x27;re doing (including the author) advocates storing passwords, even encrypted.<p>But an article with that title would probably be less visible to the audience that really needs to read it.
WorldMaker超过 4 年前
How To Safely Store a Password (2020): Don&#x27;t<p>Feeling glib, but passwords are hot potatoes best to avoid if you can. There are plenty of OpenID Connect providers to pass off the buck to, or an increasing number of &quot;passwordless&quot; options including the simple scheme of one-time codes delivered to user email addresses.
jgalt212超过 4 年前
&gt; So I’m not saying salts are without purpose, I’m saying that they don’t prevent dictionary or brute force attacks (which they don’t)<p>Only true if you don&#x27;t know the salt. Of course, most folks store the hash and salt in the same table or column (Django).
kordlessagain超过 4 年前
Just get rid of passwords.
_wldu超过 4 年前
Ten years ago, bcrypt was a fine suggestion. Today, I&#x27;d suggest Argon2.
评论 #25288486 未加载
评论 #25290556 未加载
theandrewbailey超过 4 年前
&gt; Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt.<p>Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;P-H-C&#x2F;phc-winner-argon2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;P-H-C&#x2F;phc-winner-argon2</a>
评论 #25289545 未加载
评论 #25289000 未加载
评论 #25289483 未加载
kemiller2002超过 4 年前
I always say the best piece of advice on this is, &quot;Don&#x27;t store passwords.&quot; Like shown in other comments, the landscape of what should be used changes frequently. Truthfully, I haven&#x27;t had to write anything that stores passwords for several years, and until now I hadn&#x27;t heard of Argon2. That&#x27;s frightening to me and shows how far out of the game I am now.<p>Finding a trusted 3rd party who&#x27;s responsibility is to stay on top of it, is definitely the way to go if you&#x27;re not in the security space. It&#x27;s scary how many people don&#x27;t understand the basics of hashing and encryption that have written authentication systems. When people ask me if we should do something like this, I normally say, &quot;If you&#x27;re asking me, then you probably already know the answer.&quot;
评论 #25288794 未加载
评论 #25289004 未加载
评论 #25289526 未加载