TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

We didn't encrypt your password, we hashed it

362 pointsby mrzoolover 4 years ago

36 comments

mooredsover 4 years ago
I get he&#x27;s ranting about imprecise terminology, but really, what does this knowledge gain the end user? Maybe I&#x27;m missing the point. Users don&#x27;t care if their password was hashed or encrypted or stored in an ice freezer in Antarctica.<p>They care (sometimes, sometimes they don&#x27;t act like it, see <a href="https:&#x2F;&#x2F;www.ieee-security.org&#x2F;TC&#x2F;SPW2020&#x2F;ConPro&#x2F;papers&#x2F;bhagavatula-conpro20.pdf" rel="nofollow">https:&#x2F;&#x2F;www.ieee-security.org&#x2F;TC&#x2F;SPW2020&#x2F;ConPro&#x2F;papers&#x2F;bhaga...</a> ) that it was compromised.<p>An end user doesn&#x27;t have any control or knowledge over the password storage mechanism for any sites, so the best thing is to use a strong random password generating password manager--because that is something the end user can control.<p>However, for the websites managing passwords, I&#x27;d suggest reviewing the NIST guidelines: <a href="https:&#x2F;&#x2F;nvlpubs.nist.gov&#x2F;nistpubs&#x2F;SpecialPublications&#x2F;NIST.SP.800-63b.pdf" rel="nofollow">https:&#x2F;&#x2F;nvlpubs.nist.gov&#x2F;nistpubs&#x2F;SpecialPublications&#x2F;NIST.S...</a>
评论 #24381097 未加载
评论 #24379568 未加载
评论 #24379892 未加载
评论 #24383045 未加载
评论 #24379742 未加载
评论 #24382456 未加载
评论 #24381215 未加载
评论 #24380909 未加载
alerighiover 4 years ago
In fact hashing the password is better than encrypting them!<p>If you encrypt a password, it means that somewhere you have a key that you use to decrypt it to check if it&#x27;s valid on the user login. It means that there is a way that you (or more importantly an attacker) can use to decrypt the passwords.<p>Instead if you use a good hashing algorithm is practically impossible to find the password given the hash. Yes if the password is really simple you can get it, but come on, if the password is really simple what&#x27;s the point of protecting it?<p>By the way I think that we should phase out password anyway, I mean that I prefer to implement in the applications that I develop a password-less authentication: when you want to sign in a mail (or an SMS) is sent to you, you click on a link with a temporary token and you are authenticated.<p>No password to remember, not having to implement forgot password, change password, recover your password, not having to store the password, not having the user have to choose a password, and I hate choosing password (in fact I ended up using a password manager that generates random passwords for me, but it&#x27;s not the ideal solution, because then password have to be synced on all my devices, not all websites&#x2F;apps have forms made correctly to support password manager, and the password manager extension (Bitwarden) goes in conflict with the integrated Firefox password manager so I end up having password saved in the password manager and other in Firefox and it&#x27;s a mess).
评论 #24379636 未加载
评论 #24379880 未加载
评论 #24379619 未加载
评论 #24379830 未加载
评论 #24380031 未加载
评论 #24379774 未加载
评论 #24380417 未加载
评论 #24380474 未加载
评论 #24379693 未加载
评论 #24380415 未加载
tmp538394722over 4 years ago
&gt; A password hash is a representation of your password that can&#x27;t be reversed, but the original password may still be determined if someone hashes it again and gets the same result.<p>I love workshopping copy!<p>How about:<p>To mitigate events like this, we only store a scrambled version of your password. Though your actual password can’t be simply unscrambled from the leaked data, it is possible it could be deduced by a guess and check process - especially if you are using a weak or common password.
评论 #24382886 未加载
评论 #24382772 未加载
dvtover 4 years ago
I&#x27;m not sure why implementing pepper (alongside, or even instead of, salt) is so rare. It&#x27;s arguably much easier to implement than salt, and protects against both attacks described here.<p>The only caveat is that your database isn&#x27;t coupled tightly with your application code, so your pepper remains secret even if your DB is breached (which is usually the case).
评论 #24379565 未加载
评论 #24379175 未加载
评论 #24379229 未加载
评论 #24379146 未加载
评论 #24379312 未加载
评论 #24379310 未加载
pmontraover 4 years ago
&gt; The original password is never stored thus keeping it a secret even from the website you provided it to<p>Never stored, hopefully, but the website has a chance of seeing it everytime one signs in. A malevolent site or developer or admin could store the password somewhere or try to reuse it on a number of other well known sites. Hence, one different password per site to protect also against the sites themselves.
评论 #24379493 未加载
评论 #24379461 未加载
评论 #24379430 未加载
评论 #24380613 未加载
zokierover 4 years ago
The difference between hashing and encrypting that I did not find quite spelled out enough in the article is that with leaked hashes there is a risk of cracking <i>proportional to the password strength</i>. High entropy passwords will not get cracked even if they are hashed with the MD5 which pretty much represents worst case scenario[1]. With encryption, it is very much all or nothing scenario; if the database gets cracked then all of the passwords get revealed.<p>[1] Napkin math: Single Titan RTX does some 65GH&#x2F;s of MD5, so if you have 80bit password it would take in the order of 2^80&#x2F;65e9 seconds = 500e3 gpu-years to crack
评论 #24380001 未加载
elchiefover 4 years ago
hashing is like a meat grinder<p>grind up a cow. store the ground beef somewhere<p>when a user wants to login, grind up the new cow in an identical manner.<p>compare the new ground beef with the stored ground beef.<p>if match (the new cow is a clone of the old cow), authenticate
评论 #24379776 未加载
评论 #24381466 未加载
评论 #24383230 未加载
评论 #24379564 未加载
UnicycleSkewerover 4 years ago
I wonder why it isn&#x27;t best practice to hash with a salt and then encrypt the passwords using something like AES. The encryption key can be stored in the secrets manager and be injected via environment variables.<p>Unlike a pepper it is possible to change the encryption key if it is leaked. I don&#x27;t think changing a pepper for existing hashes is possible, but if they are encrypted you can just reencrypt them with the new key.<p>So is there an obvious downside I&#x27;m not seeing to hash with a salt and then encrypt?
评论 #24379530 未加载
评论 #24379440 未加载
评论 #24379519 未加载
评论 #24379329 未加载
Nightshaxxover 4 years ago
So I tried to show this article to my mom and she had no idea what it was saying. When you introduce terms (and you are targeting non-&quot;computer&quot; people) you have to clearly define them right away. For instance she was really confused that hashing was used as both a verb and a noun.
评论 #24380867 未加载
faeyanpiraatover 4 years ago
Does any website&#x2F;app require a password?<p>If your email is compromised, the attacker can request a password reset, then log in that way.<p>Why isn’t it common to use “login emails” with a one time token login buttons in the email?<p>The only downside I see is that it is harder to log in on a machine where you do not want to access your emails; for example like this:<p>On the machine with no email access the site would have to show a qr code, and a phone where you are already logged in would have to scan it, to approve the login.<p>Is this any less secure, or is it just not feasible for average users to understand?<p>What am I missing?
评论 #24382817 未加载
评论 #24382475 未加载
laristineover 4 years ago
Many comments complain how Troy explains about technical stuff like encryption vs. hashing and the users don&#x27;t care about or understand it. However, don&#x27;t forget that many readers of his blog are the technologically literate and can appreciate the nuances of this content. In fact, I find this particular post quite easy to understand for any beginners who want to learn about about password security.<p>The distinction between encryption and hashing can never get too much education, both for the end users and the more technical developers&#x2F;sysadmins.
评论 #24379868 未加载
isoskelesover 4 years ago
&gt; Saying that passwords are “encrypted” over and over again doesn’t make it so. They’re bcrypt hashes so good job there, but the fact they’re suggesting everyone changes their password illustrates that even good hashing has its risks.<p>This is correct, but I am going out on a limb and guessing that legal counsel had something to do with the wording here (which is perplexing because I tend to expect legal definitions of terms to be more specific).<p>I was at an organization that also had a data breach, and legal counsel advised us to write a similar email when disclosing publicly that the breach occurred. I was personally on multiple phone calls with legal counsel about this, and it was quite frustrating to try and explain the difference between encryption and hashing, or stay on point with the fact that our passwords were <i>not</i> encrypted, trying to get people to stop using that word on phone calls. Early on, they&#x27;d ask questions like, &quot;But aren&#x27;t your passwords encrypted?!&quot; And you&#x27;d have to explain, no, they&#x27;re not, they&#x27;re hashed, which is most likely <i>better</i> than encrypted (although I&#x27;m open to being proven wrong on that).<p>They were, also, mostly useless on explaining what their perspective of encryption was. I never got an explanation from counsel, and at best, I was linked to a blog post that suggested some security <i>best practices</i> (not a legal definition of anything we were liable for).<p>The sad thing is, with a data breach like that, you probably do (and should) feel terrible for your customers, anyone who trusted you with their emails, passwords, etc. But the laws surrounding it are confusing enough to make it easy for some people to push this out of their mind and just focus on, &quot;What is the best thing we can do to legally cover our asses?&quot; Even if that means saying factually incorrect or misleading things like, &quot;Your passwords were encrypted.&quot;
btillyover 4 years ago
His explanation is STILL too technical. Here is his explanation:<p><i>A password hash is a representation of your password that can&#x27;t be reversed, but the original password may still be determined if someone hashes it again and gets the same result.</i><p>Compare to:<p><i>A hash is like a fingerprint of your password. Your fingerprint tells me very little about you. You might be a man or a woman, tall or short, young or old. But if you show up, I can tell that you still have the same fingerprint. Likewise a hash doesn&#x27;t tell me your password, but if my computer keeps guessing them, it can know when it is right. And my computer guesses really, really fast.</i><p>For the record I just asked my teenage son who doesn&#x27;t know what a hash is whether he understood either explanation. He understood mine, but not Troy&#x27;s. And he&#x27;s a smart kid. If he doesn&#x27;t understand an explanation, I&#x27;m pretty sure most adults won&#x27;t either.
评论 #24380527 未加载
评论 #24381310 未加载
c3534lover 4 years ago
I occasionally help new programmers figure out the basics of coding online and not understanding the difference between hashing and encryption is one of the biggest points of confusion I see. They&#x27;re fundamentally different things and knowing the difference is something that you should learn sometime after learning for loops and some time before learning trees and graphs. This is something the general public is very much confused about and if, as a professional, you get his wrong it very much makes you look bad. I don&#x27;t want to hear my doctor confusing the pancreas for the liver and I don&#x27;t want my IT professionals calling SHA256 an encryption algorithm. Understanding the difference is important. I&#x27;m not sure why the audience at hackernews finds this so academic or controversial.
JubbaOnJeans1over 4 years ago
Someday, when I grow up, I want to write like Troy Hunt. There was nothing new for me in that article and yet enjoyed reading it. There&#x27;s a special place in my heart for people who make security things readable
oshea64bitover 4 years ago
A bit of a tangent, but even if hashing was hypothetically equivalent to encryption, wouldn&#x27;t it still be good practice for organizations to encourage users to change their passwords after a data breach?<p>A good hashing algorithm today could be useless down the road if computation becomes orders of magnitudes faster, or RSA becomes trivial to reverse, etc. Similar to how MD5 was initially designed as a cryptographic hash function, but isn&#x27;t considered one today.<p>I think the idea &quot;Well my password was <i>encrypted</i>, so why should I have to change it?&quot; seems a bit silly.
dustinmorisover 4 years ago
Why are we still using passwords anyway?<p>I want to log in everywhere with my iPhone. My iPhone has my FaceID stored locally, so in order to log in somewhere with my account someone has to be in possession of my iPhone first. That&#x27;s the 1st factor.<p>Secondly they have to be me, or at least somehow fake my face so that my iPhone can match my FaceID. That&#x27;s the second factor.<p>That is already a super convenient two factor authentication scheme. Why can&#x27;t websites not send a request which invokes my iPhones two factor auth model to log in?<p>Passwords AND password managers should be made redundant.
评论 #24381930 未加载
评论 #24383402 未加载
评论 #24381961 未加载
评论 #24382259 未加载
srtjstjsjover 4 years ago
Troy doesn&#x27;t understand users. I know how this stuff works and the blog post had me snoozing. Users don&#x27;t have room in their brain for both &quot;encrypted&quot; and &quot;hashed&quot;. All they care is if they are secure, and if some pro tells them the vendor is lying.<p>Why should they be expected to know? They are receiving an email from a professional IT specialist who couldn&#x27;t even figure out how this stuff works.<p>It&#x27;s the vendor&#x27;s job to get it right, and lawyers and activists&#x27;s role to hold them accountable.
评论 #24380167 未加载
unlogover 4 years ago
Question, is it good to hash passwords as = password + email (so changing email requires input of password) + site wide long random string (this string is same for every user), thoughts?
评论 #24379436 未加载
评论 #24379370 未加载
Ahmd72over 4 years ago
He&#x27;s right about one thing, hashing is mostly for data integrity and encryption for confidentiality. So if passwords are leaked and the organization says don&#x27;t worry, fortunately your password is encrypted but its better to change it, just in case when in reality they hashed it, they are just misleading their customers and not even trying to improve the password security they have in place.
afarrellover 4 years ago
Here is my take on explaining password hashing for a non-technical audience:<p>&gt; Making a password hash gives you a scrambled text that nobody can turn back into your password but that anybody can use to check if a password guess is your real password.<p>This uses the folk understanding of entropy to be more memorable in a non-misleading way. You can&#x27;t un-scramble an egg hash.
saagarjhaover 4 years ago
&gt; They’re bcrypt hashes so good job there, but the fact they’re suggesting everyone changes their password illustrates that even good hashing has its risks.<p>It&#x27;s <i>good</i> that they suggested changing passwords, though. I have a feeling that if you call them out they&#x27;re going to go back to &quot;the passwords are secure because they were encrypted&quot;.
Ice_cream_suitover 4 years ago
The article explains salted hashes, reversing salted hashes and the benefit of using bcrypt very well.
seppelover 4 years ago
What are people using to store API tokens (eg. hmac based secrets)? My understanding is that it is symmetric so you need to store it in a recoverable way -- which always means you can leak it. What are better ways?
greypowerOzover 4 years ago
my non-crypto intuition on hashes is that the key idea is that there should only be one hash that matches my password (no collisions i think is the word? )<p>So naively i understand that a non-salted hash for &quot;password&quot; is a terrible idea, since two peoples hashes for &quot;password&quot; will be the same..<p>but i still struggle with the practical safety this gives in db breaches where the salt is in the breach..<p>Troy seems to say that this makes the cracking process slower, which think i see...<p>but is it fair to think that the KEY ISSUE is the uniqueness of the hashing function for any given input string?
评论 #24380659 未加载
评论 #24380241 未加载
评论 #24380235 未加载
pkulakover 4 years ago
Seems like a rant against hashing, but using bcrypt at level 10 (like he demonstrates) is just so much better than encrypting. Level 10 takes about a full second on hardware from a couple years ago, which was the last time I checked. Yes, you can verify that one of them is &quot;iloveyou&quot;, when you already know that, but any kind of dictionary attack, at one per second, is not going to be a good time. And like he said, if you encrypt, and lose the key too, game over.
bitemealienboiover 4 years ago
This is all so wrong. Even when you hash a password you should always salt and pepper it as well.
bregmaover 4 years ago
Technically, a hash is a one-way encryption. If it&#x27;s hashed, it&#x27;s still encrypted.
milesover 4 years ago
This seems odd, especially coming from Troy:<p>&gt; Take, for example, the following password:<p>&gt; P@ssw0rd<p>&gt; This is a good password because it has lowercase, uppercase, numeric and non-alphanumeric values plus is 8 characters long.<p>Calling it a good password, even with the later caveat that &quot;hackers have worked [character substitution] out&quot;, does not seem to make sense:<p>It&#x27;s Time to Kill Your Eight-Character Password <a href="https:&#x2F;&#x2F;www.tomsguide.com&#x2F;us&#x2F;8-character-password-dead,news-29429.html" rel="nofollow">https:&#x2F;&#x2F;www.tomsguide.com&#x2F;us&#x2F;8-character-password-dead,news-...</a> &quot;Any eight-character password hashed using Microsoft&#x27;s widely used NTLM algorithm can now be cracked in two and a half hours.&quot;
评论 #24379265 未加载
评论 #24379464 未加载
评论 #24379267 未加载
评论 #24379259 未加载
评论 #24379452 未加载
评论 #24379301 未加载
评论 #24379255 未加载
JeanMarcSover 4 years ago
It’s been a while since I’m doing both actually.<p>Since GDPR I tend to encrypt all not searchable data (address, sometimes even names) in an encrypted JSON, including the password hash.<p>Someone accessing my database will just have an integer ID, a hashed login and an encrypted field.<p>Not sure if it’s enough, but it seems ok to me.
bvincover 4 years ago
Someone should mention that one time that a leaked password database from Adobe was actually encrypted, instead of hashed.<p>It lead to this XCKD comic:<p><a href="https:&#x2F;&#x2F;xkcd.com&#x2F;1286&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;1286&#x2F;</a>
评论 #24380538 未加载
评论 #24380270 未加载
agustifover 4 years ago
What would you guys recommend for encrypting a base64 file stored in database.<p>I&#x27;ve found about scrypt and LZ-String, but not sure what would be best practice here.
评论 #24379402 未加载
评论 #24379398 未加载
评论 #24379347 未加载
rl3over 4 years ago
One of the more esoteric security practices is client-side hashing, the mere mention of which tends to draw ire:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24026233" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24026233</a>
评论 #24387524 未加载
评论 #24380351 未加载
notyourdayover 4 years ago
I have a fundamental question...<p>Why is the auth database a part of the application to begin with? Why is it not externalized away behind a single service with a bare minimum &quot;set-password&#x2F;is-this-my-password&#x2F;trigger-x&quot; endpoints exposed to the application with per route&#x2F;per source&#x2F;per question rate limiting? This is 2020, not 2001.
评论 #24379585 未加载
dustinmorisover 4 years ago
One thing that always annoys me when I read a Troy Hunt blog post or when he tweets something is how stubborn and unable to admit that someone else said something clever or that he did something wrong.<p>The comments of this blog post have some really really good suggestions how someone can much easier explain a hash that even children would understand:<p>&gt; A hash is like a fingerprint of your password. Your fingerprint tells me very little about you. You might be a man or a woman, tall or short, young or old. But if you show up, I can tell that you still have the same fingerprint. Likewise a hash doesn&#x27;t tell me your password, but if my computer keeps guessing them, it can know when it is right. And my computer guesses really, really fast.<p>Troy completely dismisses this because it&#x27;s not 100% scientifically correct in the analogy. IMHO it&#x27;s good enough for the layman to understand though which is the point of his blog post no?<p>It strikes me that he&#x27;s unable to admit that someone might have done something slightly better than him, or just give credit where credit due.<p>Reminds me of so many other blog posts where this happened as well and his infamous claim that HTTPS is faster than HTTP and when people call him up on it he argued that HTTP2 is faster than HTTP1 and going in circles...<p>Arrogance annoys me so much that I actually dislike reading his posts...
riazrizviover 4 years ago
Not sure if there is any merit to this article.<p>The author thinks passwords are not encrypted on Wattpad, because they ask you to change passwords on other sites where you have used the same password. The reason is more likely that Wattpad uses a common encryption algorithm. The hackers chance of gaining access to your other accounts using the same password is now much higher, especially if you use a relatively easy to guess string. Because using a fast computer they can run through common encryption algorithms with each guess of your password at their leisure... Once they have a match, they can login to your other sites.<p>Also hashing is nothing like encryption. To clarify hashing, is used to map very large data types to far smaller ones of just a few dozen (or few thousand) character strings, for the sake of speedy lookups. Hashing algorithms are not one way, you can determine the possible input values used to generate the hash. In the case of (relatively speaking) very small input data types like passwords, there is likely a 1:1 ratio of input password to hash, making it effectively a plain text password. So why would anyone use it? What evidence is there to suggest Wattpad would use an obviously ineffective method for encrypting passwords?<p>So the statement, &quot;a password hash is a representation of your password that can&#x27;t be reversed&quot; and other statements about the security of hashing, is just incorrect - for passwords. I agree that hashing is statistically 1-way for large inputs like big strings or images, since then the possible inputs that match to a particular hash is very very large. It is not so for small ones, like passwords, where the data type is smaller&#x2F;similar in size to the hash range.
评论 #24379789 未加载
评论 #24379593 未加载