
We didn't encrypt your password, we hashed it - mrzool
https://www.troyhunt.com/we-didnt-encrypt-your-password-we-hashed-it-heres-what-that-means/
======
mooreds
I get he's ranting about imprecise terminology, but really, what does this
knowledge gain the end user? Maybe I'm missing the point. Users don't care if
their password was hashed or encrypted or stored in an ice freezer in
Antarctica.

They care (sometimes, sometimes they don't act like it, see [https://www.ieee-
security.org/TC/SPW2020/ConPro/papers/bhaga...](https://www.ieee-
security.org/TC/SPW2020/ConPro/papers/bhagavatula-conpro20.pdf) ) that it was
compromised.

An end user doesn'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.

However, for the websites managing passwords, I'd suggest reviewing the NIST
guidelines:
[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf)

~~~
staticautomatic
Except when you hit a website that refuses your auto-generated strong random
password, which happens to me with shocking regularity.

~~~
JohnTHaller
My favorite is when the website accepts your long random password but then the
login fails. Because the set password function truncated the password before
hashing it but the login function doesn't do that.

~~~
OneLeggedCat
This still happens, in 2020, with breathtaking regularity. Several times a
year, a site won't accept my password, so I then start the whole "Will 20
characters work? No, that didn't work. Will 16? Nope... 15? Nope... 12? Nope.
Oops I skipped 14... AH YES FINALLY."

~~~
liability
This will never change until engineers can be held criminally accountable for
incompetence, particularly when personal information is involved.

Of course any proposal to ever hold a programmer accountable for literally
anything is always unpopular on HN, for obvious reasons.

~~~
_t0du
Because it's ridiculous to decide that the bottom of the decision graph should
be held responsible for the poor decisions made from above.

Engineers should only be held accountable for decisions they made personally.
The unfortunate reality is that, a terrifying amount of the time, terrible
decisions are handed to engineering teams as required implementation details
from managers, executives, product directors, etc. So should engineers be held
criminally accountable for their product manager demanding MD5 hashes on
passwords?

~~~
liability
An engineer should be willing to tell his boss _" No, because I would go to
jail"_ If the manager insists anyway, the engineer should be obliged to
refuse, even if that costs them their job.

Of course management should _also_ be held accountable, but until engineers
are forced to have some skin in the game they will continue to be as pliable
as wet noodles.

Consider this: who better to blow the whistle on management than an engineer
who knows they've been given an illegal order?

~~~
alexbanks
> An engineer should be willing to tell his boss "No, because I would go to
> jail"

I guess we just fundamentally don't agree on how power dynamics effect these
types of scenarios.

~~~
smichel17
I agree with the GP, but I also think it is poorly phrased. It's not that the
engineers should be _willing_ to say they'd go to jail, it's that they should
be _able_ to.

Right now, the conversation goes, management: "I want x". Engineer: "X is
insecure, we should do y instead". M: "Y will cost us X more than x, and it's
never going to matter for us, anyway."

This puts the engineer in a position where they need to argue and justify the
cost. Compared to "Sorry, I can't do that; it's illegal and I'd go to jail if
I did that and was found out." Now the engineer doesn't have to justify
anything. The law isn't a burden on the engineer here, it's a _shield_.

Yes, there are still some scenarios in which management insists. In my limited
experience, that's in gray scenarioa where it's arguable whether the law
applies. But the point is, it's much easier for an engineer to argue whether
the law applies, than whether it is worth the money.

I think you can see these effects in the lengths companies go to protect
healthcare data (hipaa) vs any other random personal data.

~~~
alexbanks
I guess my point is not that engineers should be exempt from being held
accountable for their work, but that engineers are frequently asked to do
things incorrectly/poorly/negligently and then assessed by their employers for
their willingness to comply. Sure, you can say "Just stand up to your
employer", but that's an incredibly dismissive stance on a complicated issue.
Yes, you should say no to requirements that are flat out illegal, but is it
ever that cut and dry? I'd be surprised to find it was ever that simple.

~~~
slavik81
According to my engineering professional association, it is that simple.
They'd have no qualms stripping me of my license to practice engineering for
knowingly approving an unsafe design, regardless of what effect that decision
would have had on my financial well-being.

The big difference is that companies need professional engineers. Professional
approval on certain things is required by law. I'm not sure that would be a
good idea for software, but that is what makes the system work for
professional engineers.

~~~
alexbanks
> They'd have no qualms stripping me of my license to practice engineering for
> knowingly approving an unsafe design

Presumably there would be repercussions at the government level if a company
repeatedly demanded engineers do things worthy of stripping their licenses
though, no?

~~~
slavik81
This varies by jurisdiction, but perhaps I oversimplified. There is another
reason that doesn't happen.

The individual engineer doing the work needs a license, but the company itself
also needs a permit to practice. The permit must be held by an engineer, who
is personally responsible for the engineering that occurs under their permit.

So, the permit holder needs to worry not just about their own ethical
behaviour, but that of all engineers in the company. They are incentivized to
ensure the company will hold the public safety paramount, or to walk away if
they cannot (thereby leaving the company without a permit).

If the company has a pattern of misbehaviour, it may be difficult to obtain a
permit.

~~~
alexbanks
_Exactly_. Tech companies regularly exist purely based off of illegal business
models (they call them _Disruptions_).

So, yes, we agree, if there are repercussions for a company regularly breaking
the law, then engineers can and should refuse work that has negative legal or
moral repercussions. But in the world of tech, that's not the case.

------
alerighi
In fact hashing the password is better than encrypting them!

If you encrypt a password, it means that somewhere you have a key that you use
to decrypt it to check if it'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.

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's the point of
protecting it?

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.

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's not the ideal solution, because then password have to be synced on all my
devices, not all websites/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's a mess).

~~~
tdrp
Regarding simple passwords, we added a check against the top 100K seclist
passwords when first registering, to keep users from using easily guessable
passwords (we also had an experiment where we checked if that password was one
of the frequently compromised ones).

Literally this converted into:

1- Users abandoning on sign-ups "oh how am I supposed to find a password I
will remember"

2- Users bashing us on the app store reviews: "make it super hard to sign-up"
even though we only ask for username and password, not even an e-mail

3- Users logging in, liking the app, then a few months later when they got
logged out for whatever reason, completely forgetting what their password was
and not having a fallback e-mail.

We ended up pulling it back. We just have a small note now that says "easily
guessable password" but allow them to proceed with registration.

~~~
cpeterso
You could make the minimum password length longer than the longest SecList
password. Then users can’t reuse any of those insecure passwords! Plus it’s
also a fast O(1) check. :)

~~~
IshKebab
Yeah that's at least 12 characters though. Quite annoying.

~~~
afiori
It is very easy to get long passwords, just double them

~~~
cpeterso
Or just append a long number like "password12345" (13 characters).

------
tmp538394722
> A password hash is a representation of your password that can't be reversed,
> but the original password may still be determined if someone hashes it again
> and gets the same result.

I love workshopping copy!

How about:

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.

~~~
wffurr
I think it's important to include the technical term "hash" at least once.
Then users can research the topic.

"Scrambled" is imprecise enough that it could mean either hashed or encrypted.
In radio usage, it specifically refers to encryption, so someone researching
"scrambling" would get confused very quickly by that explanation.

------
dvt
I'm not sure why implementing pepper (alongside, or even instead of, salt) is
so rare. It's arguably much easier to implement than salt, and protects
against both attacks described here.

The only caveat is that your database isn't coupled tightly with your
application code, so your pepper remains secret even if your DB is breached
(which is usually the case).

~~~
dec0dedab0de
pepper instead of salt is a bad idea because if your pepper is leaked the
attacker can brute force all of your passwords at once.

The main argument I've heard against pepper is because people are afraid of
losing the pepper. It either needs to be directly in your code which is easier
to leak, or out of band which is easier to lose.

edit: Does anyone else want to goto waffle house whenever they talk about
salting and peppering their hash? Too bad the closest one is an hour away.

~~~
dvt
> pepper instead of salt is a bad idea because if your pepper is leaked the
> attacker can brute force all of your passwords at once.

This isn't true, you could simply do encrypted_pw = md5(pepper +
md5(password)) or whatever.

Edit: Getting a bunch of comments on this, just want to clarify that I used
md5 purely to illustrate a one-way hashing function. In actual practice, you'd
use something else (HMAC with SHA256 most likely).

~~~
dathinab
> md5(pepper + md5(password)) or whatever.

(Ignore md5)

No, I strongly recommend not to do so. The reason you put an salt in is to
prevent multiple hashs to be the same (because people use the same password)
with a pepper you still protect against cross reverencing the hash with other
databases, but any two users in your database will still have the same hash
and people tend to reuse passwords (or similar passwords) so this is a very
real attack vector to get passwords without really braking any hash fully
(E.G.: user with known password on different platform => try out similar
passwords => broke hash for anyone with _similar_ password).

So a unique per hash specific salt is the most important thing to do.

Pepper/shared secret can make it additionally harder to crack any hashes as
while you know all salts (they are stored alongside the hash) you don't know
the pepper.

Lastly there is additional data (AD) (named sometimes differently). Which can
prevent some form of hash reuse attacks where you e.g. find some form of
attack which allows you to override hashes+salt in the db (but not more). Then
you could rewrite all hashes to known ones and get access. Tbh for many
systems if an attacker can do something like this they don't need to do that
anymore. But for other (often large and complex) systems it's helpful.

The idea behind AD is that you (somehow depending on algorithm) include some
additional data which needs to match. The most common example is to use the
user id (if immutable) as AD so this hash+salt(+pepper) is only usable for
given user and never for any other user.

If you ever write a auth sub-system for a big enterprise system I would
recommend you to use salt+pepper+AD(uid), for everything else I would think
salt+pepper is enough. _But never should you use a hash without unique salt
under any circumstance._ It's always the wrong path to take.(For password
hashing.)

Or at least that's my opinion.

~~~
blntechie
Is it worth it to salt in scenarios when the passwords (actually tokens)
themselves are guaranteed to be unique and instead only use pepper?

~~~
couchand
Short answer: if they are unique because they're a small sample from a large
space (e.g. UUID v4) no salt is needed. If they're unique but maybe
predictable, salt.

~~~
blntechie
Thanks! Yes, they are random GUID-like values and are short lived (2-4hrs).
Had a need to store them for a reason and decided to only add pepper to hash
considering they are unique and short lived anyway.

------
pmontra
> The original password is never stored thus keeping it a secret even from the
> website you provided it to

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.

~~~
hinkley
There was a class of password algorithm that used your password and some other
information as a seed for generating an asymmetric cypher, but the original
Stanford proposal was apparently a bit light and nobody ever implemented it. I
bumped into some new algorithms in the same category, but I'm blanking on the
clever name they used to describe them all.

The server would only ever have your 'public key'. I'm not sure where you get
the saltiness to prevent lookup tables but still let me log in from three
devices with the same credentials.

~~~
pauldino
I think you're referring to PAKE (password-authenticated key exchange). SRP
(secure remote protocol) might be the Stanford proposal you're referring to,
although it's actually fairly commonly implemented as far as PAKEs go (Apple
for instance uses it for their iCloud Keychain).

[https://blog.cryptographyengineering.com/2018/10/19/lets-
tal...](https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-
pake/)

~~~
hinkley
This is it, thanks. PAKE. No wonder I couldn’t remember it!

------
zokier
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 _proportional to the password strength_. 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.

[1] Napkin math: Single Titan RTX does some 65GH/s of MD5, so if you have
80bit password it would take in the order of 2^80/65e9 seconds = 500e3 gpu-
years to crack

~~~
10000truths
If you have a _random_ 80 bit password, yes. But passwords are the farthest
thing from random. Even high entropy passwords from a password generator will
only use the printable ASCII character set, which reduces the number of
possible values of a byte from 256 to 95. An 80 bit password from a
conventional random password generator would have an effective entropy of
(80/8)*log2(95) ~ 66 bits, which would take about 30 GPU years.

~~~
moron4hire
80-bit password is not the same thing as 10-ASCII-characters password. The
reduced alphabet space of only using printable characters is taken into
account when figuring the bit-edness of a password.

------
elchief
hashing is like a meat grinder

grind up a cow. store the ground beef somewhere

when a user wants to login, grind up the new cow in an identical manner.

compare the new ground beef with the stored ground beef.

if match (the new cow is a clone of the old cow), authenticate

~~~
roywiggins
That explains the advice to always salt and pepper your hash.

~~~
snypox
What a good analogy, right.

------
UnicycleSkewer
I wonder why it isn'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.

Unlike a pepper it is possible to change the encryption key if it is leaked. I
don't think changing a pepper for existing hashes is possible, but if they are
encrypted you can just reencrypt them with the new key.

So is there an obvious downside I'm not seeing to hash with a salt and then
encrypt?

~~~
dec0dedab0de
The only downside I think of is that it's not possible to recover from an
outage with just the code and a database backup.

~~~
UnicycleSkewer
I guess that is true, but if you store the encryption key in a secret store on
Azure or AWS, I wouldn't really worry about that.

Maybe the real question is why use a pepper over encryption?

They have the same downside (as you mentioned) but at least you can change the
encryption key without having all the users change passwords. I don't see any
advantage in using a pepper over encryption, except maybe implementation
complexity.

~~~
hinkley
Pepper, encryption, they both guard against drive-bys, which can happen for
sure (missing backups anyone?) but they're not the only thing that can happen.

Like any disaster preparedness situation, make sure your strategy doesn't
count on an asset you've already listed as unavailable.

------
Nightshaxx
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-"computer" 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.

~~~
bonoboTP
It may also be unclear what "reversing" means here. You have to remember that
most non-technical people don't think in the programmer style "input-output"
way. Say "reversing a hash" and the may think of reversing the string like
abc->cba.

Often you cannot do better in explaining it without doing a mini course. And
people would have to sit down, concentrate and work through the new concepts
and that's tiring, looks like school, "I was never good at math", and you lost
everyone. You can't make the average person understand hashing, mainly because
the don't care and will glaze over. You can dress it up with engaging stories
and metaphors, and they will remember the engaging story but not actually
build the right mental model if you actually poke at their understanding.

------
faeyanpiraat
Does any website/app require a password?

If your email is compromised, the attacker can request a password reset, then
log in that way.

Why isn’t it common to use “login emails” with a one time token login buttons
in the email?

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:

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.

Is this any less secure, or is it just not feasible for average users to
understand?

What am I missing?

~~~
mleonhard
I asked this exact question some years ago. I believe the answer has many
parts:

Effective security is tailored to the situation: the app, the users, and the
adversaries.

Login emails are slow and require multiple steps. The user must enter their
email into the website, switch to their email client, wait for the email, open
it, and click the link. If the user's email goes down, they cannot log in to
the website. Some folks get distracted while waiting for the email. Sometimes
a login email will get marked as spam. Sometimes a user permanently loses
access to their email account. These things reduce user engagement and
increase support costs, and the company makes less money.

There are many ways for attackers to obtain email: DNS, BGP, email server,
email server backups, user device backups, malware, re-used passwords, and
phishing.

There are only a handful of ways for an attacker to obtain passwords: malware,
password re-use, and phishing. Notice that this is a subset of the attacks on
email. And passwords have special mitigations. Some devices have password
managers that resist malware. Security teams have various options for reducing
password re-use.

Good authentication depends on something you know (password) and something you
have. Password managers turn something you know (password) into something you
have (device). Criminals rarely steal devices to gain access to online
accounts. So in practice, something you have is just as good as something you
know.

~~~
faeyanpiraat
I get the part where you list the possible inconveniences of email.

What I dont get is how having smaller attack surface for losing a password,
and using a secure password manager mitigates the attack vector of getting
access to my account with a password reset through my compromised email.

If I understand correctly you say that email is more vulnerable, so this only
strenghtens my point I guess?

~~~
mleonhard
Password reset is a rare event, so it has extra mitigations:

1\. Extra security checks. For example, if you buy a new laptop and use a
coffee shop's wifi try to reset your bank password, they will lock your
account. You will have to call and talk to a person and give extra personal
information to get it unlocked.

2\. Notify the user about the password reset. Use email, text, phone call, and
postal mail.

3\. Automatically lock the account if suspicious activity occurs in a time
period after password reset. Examples:

    
    
      - Orders over $100 shipped to new addresses.
    
      - Risky transactions: buying gift cards, buying plane tickets in foreign countries, changing the delivery address of a shipment.
    
      - Using a known device (with cookies/fingerprint) and the old password.
    

4\. Require extra confirmation for transactions. Examples: re-enter credit
card numbers, security codes, and personal id numbers (SSN in USA).

5\. Preserve user data so it can be restored to the state before the password
reset.

These mitigations work well enough for protecting accounts from fraudulent
password resets.

~~~
faeyanpiraat
Thanks, this was the missing puzzle piece.

------
laristine
Many comments complain how Troy explains about technical stuff like encryption
vs. hashing and the users don't care about or understand it. However, don'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.

The distinction between encryption and hashing can never get too much
education, both for the end users and the more technical developers/sysadmins.

~~~
thdc
If we're being extra pedantic, hashing is just using some function that maps
inputs to a set of values and is not necessarily hard to reverse and he
should've used the term cryptographic hash.

~~~
giantrobot
But you're talking about cryptographic hashes which are by design
difficult/impossible to reverse. Their unidirectional nature is what makes
them cryptographic hashes instead of just plain hashes.

------
isoskeles
> 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.

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).

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
_not_ encrypted, trying to get people to stop using that word on phone calls.
Early on, they'd ask questions like, "But aren't your passwords encrypted?!"
And you'd have to explain, no, they're not, they're hashed, which is most
likely _better_ than encrypted (although I'm open to being proven wrong on
that).

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 _best practices_ (not a
legal definition of anything we were liable for).

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, "What
is the best thing we can do to legally cover our asses?" Even if that means
saying factually incorrect or misleading things like, "Your passwords were
encrypted."

------
btilly
His explanation is STILL too technical. Here is his explanation:

 _A password hash is a representation of your password that can 't be
reversed, but the original password may still be determined if someone hashes
it again and gets the same result._

Compare to:

 _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 '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._

For the record I just asked my teenage son who doesn't know what a hash is
whether he understood either explanation. He understood mine, but not Troy's.
And he's a smart kid. If he doesn't understand an explanation, I'm pretty sure
most adults won't either.

~~~
talaketu
Your wordy metaphor misses the point that Troy Hunt was making - that the
original password can still be found out by someone other than the owner.

~~~
Izkata
Is that not this part?

> > but if my computer keeps guessing them, it can know when it is right. And
> my computer guesses really, really fast.

~~~
talaketu
That part doesn't follow from the metaphor.

And as far as operational security is concerned, this fixates on just that one
threat that the author talks about at the end, which depends on weak password.

------
c3534l
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'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't want
to hear my doctor confusing the pancreas for the liver and I don't want my IT
professionals calling SHA256 an encryption algorithm. Understanding the
difference is important. I'm not sure why the audience at hackernews finds
this so academic or controversial.

------
JubbaOnJeans1
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's a special place in
my heart for people who make security things readable

------
oshea64bit
A bit of a tangent, but even if hashing was hypothetically equivalent to
encryption, wouldn't it still be good practice for organizations to encourage
users to change their passwords after a data breach?

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't considered one today.

I think the idea "Well my password was _encrypted_ , so why should I have to
change it?" seems a bit silly.

------
dustinmoris
Why are we still using passwords anyway?

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's the 1st factor.

Secondly they have to be me, or at least somehow fake my face so that my
iPhone can match my FaceID. That's the second factor.

That is already a super convenient two factor authentication scheme. Why can't
websites not send a request which invokes my iPhones two factor auth model to
log in?

Passwords AND password managers should be made redundant.

~~~
bkircher
I can't change my face. I can change all my passwords, though. Also, I don't
own an iPhone.

~~~
tialaramex
You don't need to change your face.

Your face is only authenticating you to your device because that's what you
chose. If you don't want that (e.g. your identical twin sister loves pranking
you) you can just use a different authenticator. The remote web site
deliberately has no idea your face was involved, it just knows your identity
was verified on its behalf by the hardware storing your private key.

------
srtjstjsj
Troy doesn't understand users. I know how this stuff works and the blog post
had me snoozing. Users don't have room in their brain for both "encrypted" and
"hashed". All they care is if they are secure, and if some pro tells them the
vendor is lying.

Why should they be expected to know? They are receiving an email from a
professional IT specialist who couldn't even figure out how this stuff works.

It's the vendor's job to get it right, and lawyers and activists's role to
hold them accountable.

~~~
dathinab
The problem is if that users which don't understand the difference and worse
don't know there is a difference crate regulations and laws...

------
unlog
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?

~~~
social_quotient
Maybe still with a salt? Otherwise I’d think it would still be reasonably
hackable cause both things can (could) be known.

The only thing that bothers me here (not sure why) is something about the fact
that if the user changes their email you get a pass change as well and that
might signal an account take over if your system is analyzing behavior stuff
like that. Could be wrong on my gut feeling here.

~~~
user5994461
Hashing email + password is fine.

The email is the salt. It's different for every hash which is all that's
needed from a salt.

~~~
et-al
Unfortunately, email is not a unique salt in the context of the internet. If
the owner of the email uses the same password elsewhere (very likely), it's
probably already in a rainbow table.

So just generate and store a random salt instead.

~~~
user5994461
That is nonsense. You might want to check again what's a rainbow table and how
it's used, because it's not what you think ^^

It's possible that another service use the same hashing method and email as
salt and password. It's irrelevant at best when it comes to security. If the
password was cracked it would make it's way to dictionaries, the password is
compromised irrelevant of the salt and the hashing method.

~~~
et-al
The purpose of (properly) salting is to prevent against rainbow table attacks
when your users table with password hashes is leaked, right?

That's why OWASP advises that salts be _at least_ 16 characters long. This
requires an attacker to generate a (currently) unfeasible number of rainbow
tables.

However, if every web developer out there followed your advice, then the
number of rainbow tables ever needed is reduced to the number of emails;
assuming everyone uses the same hashing function. Sure there are a lot of
email addresses, but maybe the attacker only wants to target users at
@bigco.com. So now only 100 rainbow tables are required to cover the C-levels
and VPs there.

~~~
user5994461
If you know systems are doing SHA(password), you could generate a database of
precomputed passwords up to 10 characters. That's called a rainbow table. It
can take a year to generate one and take a terabyte to store. The benefits of
the table is to make lookup really fast.

You could still try to brute force up to 10 characters on the fly or try a
dictionary of known passwords. Having a precomputed table is much faster
though.

Systems have to use a salt per user like HASH(username + password) because
user+password won't be found in the table. This effectively break usage of
rainbow tables. The salt only needs to be unique per user account, an email is
good enough.

It's nonsense when you say to generate a table per user. It could take a
freaking year to generate a table! That's not feasible.

That being said. For something like Linux or Windows accounts, if it were
using something like HASH(username + password), it could be worthwhile to make
a table because the username is always "root", so that use case should use
something else than the username as salt. ^^

~~~
hansvm
And it takes a week for 9 characters and a few hours for 8. The point is that
with a random salt the amount of work that needs to be done is proportional to
the number of accounts you want to break across all services, not just one. It
isn't a ton of additional security (especially if an email account is
compromised...why is everything so terrible), but it is strictly better and
doesn't have failure modes like the same username being used in a billion
devices.

------
Ahmd72
He'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'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.

------
afarrell
Here is my take on explaining password hashing for a non-technical audience:

> 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.

This uses the folk understanding of entropy to be more memorable in a non-
misleading way. You can't un-scramble an egg hash.

------
saagarjha
> 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.

It's _good_ that they suggested changing passwords, though. I have a feeling
that if you call them out they're going to go back to "the passwords are
secure because they were encrypted".

------
Ice_cream_suit
The article explains salted hashes, reversing salted hashes and the benefit of
using bcrypt very well.

------
seppel
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?

------
greypowerOz
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?
)

So naively i understand that a non-salted hash for "password" is a terrible
idea, since two peoples hashes for "password" will be the same..

but i still struggle with the practical safety this gives in db breaches where
the salt is in the breach..

Troy seems to say that this makes the cracking process slower, which think i
see...

but is it fair to think that the KEY ISSUE is the uniqueness of the hashing
function for any given input string?

~~~
gknoy
It's not guaranteed to be unique.You can have multiple things that hash to the
same value.

~~~
greypowerOz
thanks, yeah that's what mean... but i see that the the core insight is that
using salted hashes has an exponential decrease in the ease of finding and
storing "hashed passwords" for a lookup tabke

So am i still in the right mindset to think that the "uniqueness" of every
hash/ lack of collisions is still a valid area?

ie that the hash function is really unlikely to produce the same hash
twice....

------
pkulak
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 "iloveyou", 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.

------
bitemealienboi
This is all so wrong. Even when you hash a password you should always salt and
pepper it as well.

------
bregma
Technically, a hash is a one-way encryption. If it's hashed, it's still
encrypted.

------
miles
This seems odd, especially coming from Troy:

> Take, for example, the following password:

> P@ssw0rd

> This is a good password because it has lowercase, uppercase, numeric and
> non-alphanumeric values plus is 8 characters long.

Calling it a good password, even with the later caveat that "hackers have
worked [character substitution] out", does not seem to make sense:

It's Time to Kill Your Eight-Character Password
[https://www.tomsguide.com/us/8-character-password-
dead,news-...](https://www.tomsguide.com/us/8-character-password-
dead,news-29429.html) "Any eight-character password hashed using Microsoft's
widely used NTLM algorithm can now be cracked in two and a half hours."

~~~
sigzero
I think he was only saying it was "good" because it had those elements and not
because "P@ssw0rd" is a "good password".

~~~
prophesi
Yeah I think that whole paragraph needs to be rewritten; one could also come
away thinking that substituting characters in a word with symbols is also a
"good" password.

------
JeanMarcS
It’s been a while since I’m doing both actually.

Since GDPR I tend to encrypt all not searchable data (address, sometimes even
names) in an encrypted JSON, including the password hash.

Someone accessing my database will just have an integer ID, a hashed login and
an encrypted field.

Not sure if it’s enough, but it seems ok to me.

------
bvinc
Someone should mention that one time that a leaked password database from
Adobe was actually encrypted, instead of hashed.

It lead to this XCKD comic:

[https://xkcd.com/1286/](https://xkcd.com/1286/)

~~~
wglb
That was a fun one. There were lots of lessons from that that I used in my
security awareness training. The bottom line was that all this stuff was in an
essentially-unencrypted backup file.

There were other lessons too, but that was the main one.

------
agustif
What would you guys recommend for encrypting a base64 file stored in database.

I've found about scrypt and LZ-String, but not sure what would be best
practice here.

~~~
TheDong
Neither scrypt nor lzma are encryption.

If you use scrypt, you won't be able to get the file back out ever again.

If you use lzma, it's compressed, not encrypted, and anyone who gets the
compressed data can trivially decompress it.

Consider using an nacl secretbox if you need to encrypt it.

Consider very carefully where you'll store the password.

Does the user input it each time they access the file (in which case use a
key-derivation-function on their password)? Do you encrypt it with an
application key? Per-user key stored in vault? Do you have a hardware
encryption tool available (an HSM) or something like aws KMS?

Your encryption is only as secure as you keep the encryption keys.

See also [0] for some suggestions.

[0]: [https://latacora.micro.blog/2018/04/03/cryptographic-
right-a...](https://latacora.micro.blog/2018/04/03/cryptographic-right-
answers.html)

~~~
agustif
Thanks for all the tips and the link, will research further and see what
better suits my needs.

For now I'm most worried about db being leaked so would look into db
encryption and prob I will go with application-key

------
rl3
One of the more esoteric security practices is client-side hashing, the mere
mention of which tends to draw ire:

[https://news.ycombinator.com/item?id=24026233](https://news.ycombinator.com/item?id=24026233)

~~~
LanceH
The cult of JWT really bothers me.

~~~
rl3
I want to like JWT, but in practice I find it overkill for many scenarios,
just contributing to further complexity and dependency bloat.

------
notyourday
I have a fundamental question...

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 "set-
password/is-this-my-password/trigger-x" endpoints exposed to the application
with per route/per source/per question rate limiting? This is 2020, not 2001.

~~~
dudus
Because while service oriented architecture is currently "hot" it's not a
requirement for many systems and monolith is still king in most corporate
environments.

It's not just because the decade counter changed that everyone must rewrite
their systems using the latest fad.

~~~
notyourday
If you have a single database, located on a single server you have a single
security domain. No amount of hand waving is going to create a magic security
boundary that will not be crossed by the most banal part of the application.

------
dustinmoris
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.

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:

> 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'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.

Troy completely dismisses this because it's not 100% scientifically correct in
the analogy. IMHO it's good enough for the layman to understand though which
is the point of his blog post no?

It strikes me that he's unable to admit that someone might have done something
slightly better than him, or just give credit where credit due.

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...

Arrogance annoys me so much that I actually dislike reading his posts...

------
riazrizvi
Not sure if there is any merit to this article.

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.

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?

So the statement, "a password hash is a representation of your password that
can't be reversed" 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/similar in size to the hash
range.

~~~
Tainnor
You're confusing run-of-the-mill hash functions used e.g. for hash maps with
_cryptographic hash functions_ which have an entirely different purpose and
therefore different characteristics (and conversely, using SHA256 to hash your
dictionary keys would be totally overkill).

Cryptographic hash functions are one-way in the sense that (unless they are
shown to be broken) it is not believed that there is a computationally
tractable way of recovering the unhashed input from the hash. You can always
brute force it, but even "just" for passwords, the input space is way too big
for that, especially if you use a salt - unless you use a very common
password, of course (even if limited to 26 letters and 8 characters that's
over 200 billion different passwords).

So, most of your comment is just wrong, except for the part about how Wattpad
stores passwords, which is just very likely wrong, since I can't prove it.

~~~
pjscott
> (even if limited to 26 letters and 8 characters that's over 200 billion
> different passwords)

Of course, if you're using a _fast_ cryptographic hash function then someone
with a good GPU can throw a surprising amount of brute force at the problem. A
Tesla M60, which is five years old, can do about 1.4 billion SHA-256 hashes
per second; Amazon will rent you a server with one of these for $0.75/hour,
and cracking a single 8-character lowercase alphabetic password should take
about 2.5 minutes at most. Half that on average.

(Functions like bcrypt help with this by being designed for slowness, and
newer ones like scrypt also try to use large amounts of memory with
unpredictable access patterns so they're harder to accelerate with
GPU/FPGA/ASIC hardware.)

~~~
Tainnor
This is all true, and this why we have bcrypt etc., but it was just an example
for illustration.

In real-life situations, the input space is much larger still (if you account
for longer passwords, case sensitivity, special characters etc.), as long as
your passwords are truly unguessable. And at some point, even a very fast
hashing algorithm won't be able to keep up. I don't know the exact
calculations, but I would expect MD5 to still be hard to break for truly
strong passwords (say, 20 random characters). The problem is more that people
don't actually choose strong passwords most of the time.

