22 ms·

We didn't encrypt your password, we hashed it

362 points by mrzool 6y ago

agustif 6y ago
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.
- iso8859-1 6y ago
  did you read the article? there is no reason to encrypt passwords. scrypt is a popular KDF, i think you'll be fine with that.
  - agustif 6y ago
    Yes I did read the article, It's not a password, it's a PDF file, it's contents I store them as plain base64 now, but I'd rather have store them in a more secret fashion in case of a leak... If that makes sense...
    - iso8859-1 6y ago
      for the encryption itself, you can use e.g. LibSodium or AES (in a sensible mode!!!). of course, you'll need a key too, which is where you can use a KDF. but without knowing more about your threat model, it is hard to tell you how to do the key derivation.
      - agustif 6y ago
        Hey thanks, well I'm a bit out of my area here but that sounds helpful and will research it, thanks!!
      - StavrosK 6y ago
        Most of that is too low-level, libsodium/nacl is closer to what they want.
    - StavrosK 6y ago
      libsodium?
- TheDong 6y ago
  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-answers.html https://latacora.micro.blog/2018/04/03/cryptographic-right-a...
  - agustif 6y ago
    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
- cogman10 6y ago
  What are you trying to accomplish? I don't know why you are base64 encoding things before sending them to the DB. Just use a binary blob. scrypt is a hashing algorithm, not an encryption algorithm. So that doesn't seem like what you want. LZ-String is a compression algorithm, that's trivially reversible. The problem you'll run into is that the "right" encryption algorithm is constantly changing. Probably the best thing to do would be to not do it yourself, instead, rely on encryption capabilities of your DB if provided. If you opt to doing your own encryption, then be prepared to constantly maintain and update it. Pushing that responsibility onto the DB makes that burden a simple "make sure your DB is up to date" Which you should be doing anyways.
pmontra 6y ago
> 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.
- mooreds 6y ago
  > Hence, one different password per site to protect also against the sites themselves. Preferably one generated by a password manager, large and random and totally unrelated to any other password of the user.
- hinkley 6y ago
  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.
  - dinosaurdynasty 6y ago
    Do you mean <https://en.wikipedia.org/wiki/Zero-knowledge_password_proof> https://en.wikipedia.org/wiki/Zero-knowledge_password_proof>?
  - tialaramex 6y ago
    The Stanford proposal you're talking about was named pwdhash. This approach is sometimes called a "Deterministic password manager" and that might be the phrase you wanted. There are several problems with this approach, especially with regard to the need to sometimes change passwords. But the point your parent was making is that in the modern era (certainly this century) none of this was necessary, there are asymmetric PAKEs which render it unnecessary for a site to know your password at all in order to confirm that you still know what it is.
bvinc 6y ago
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/
- tialaramex 6y ago
  Terrible crypto design is a recurring feature of Microsoft products too, e.g. the original LANMAN password hash has a maximum password length of 14 characters and just treats all passwords as two separate 7 byte values to verify. If we use MD5(password) then brute force of a 14 character random password (say using a 64 symbol character set) isn't really viable because you need to try about 2^84 values. MD5 isn't an acceptable password hash, but using a strong random password was enough to save us. But if we use LMhash(password) that same password can be brute forced in just 2^43 operations. This design is so bad that there's no way for the user to protect themselves. This popularized Rainbow Tables. You may use a time-space tradeoff for any hashing scheme that doesn't have salt, or doesn't have enough salt compared to how much it's used, but for most schemes a strong random password overwhelms the power of the time-space tradeoff anyway. Rainbow Tables tilt this tradeoff so that it's more favourable in exchange for a modest reduction in effectiveness† and for LANMAN they're enough to turn it from "If you had a super computer and hundreds of gigabytes of disk space you could crack any Windows password hash near instantly" to "If you have a mid-range PC with 5GB of hard disk space and download this software you can crack 99.9% of Windows password hashes in a few minutes". †For a lot of pre-computation effort you can get all the effectiveness back. But that's not important here.
- wglb 6y ago
  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.
JeanMarcS 6y ago
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.
dvt 6y ago
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).
- edflsafoiewq 6y ago
  > It's arguably much easier to implement than salt Salting is easier since it can be completely wrapped up in the key derivation function. The programmer doesn't have to know anything about it, they just use generate_key(passwd) and check_password(passwd, key).
- zemnmez 6y ago
  you really shouldn't be implementing your password hashing algorithm from basic crypto primitives. s/bcrypt works right out of the box with no config.
- mberning 6y ago
  I have wondered the same thing. Make it a piece of data that comes in from the environment or a secrets manager. It’s not bulletproof, but if done correctly seems like it makes the whole hashing scheme a little better.
  - lookingfj 6y ago
    If you are doing this isn't it pretty much the same as encrypting it with a key?
    - liambuchanan 6y ago
      encryption is non-deterministic
      - iso8859-1 6y ago
        if that was true, this article wouldn't exist: https://en.wikipedia.org/wiki/Deterministic_encryption https://en.wikipedia.org/wiki/Deterministic_encryption
saagarjha 6y ago
> 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".
miles 6y ago
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-29429.html https://www.tomsguide.com/us/8-character-password-dead,news-... "Any eight-character password hashed using Microsoft's widely used NTLM algorithm can now be cracked in two and a half hours."
- samsgro 6y ago
  Troy is sarcastically explaining that this is a "good password" according to older password complexity rules, but a horrible password given predictable password substitution logic. Password complexity rules accomplish little. Obligatory xkcd comic link: https://xkcd.com/936/ https://xkcd.com/936/
- i-am-curious 6y ago
  Won't you add a seed before hashing. With a 8 byte seed that's 16 effective characters, probably impossible to crack.
  - kohtatsu 6y ago
    You add a salt, which is stored plaintext alongside the password.
  - __s 6y ago
    By seed you mean salt. Salts are stored in plaintext, so they don't increase the entropy of the password. Instead they make it so that each password hashes uniquely so that everyone with the same password gets different hashes. They also mitigate rainbow tables by effectively requiring the attacker to create a rainbow table per target
    - i-am-curious 6y ago
UnicycleSkewer 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.
- est31 6y ago
  I don't see any downsides. As you point out, upgrading hashed peppers isn't as beautiful. Yes, you can just introduce a new pepper and wrap the old hash into another hash using the new pepper, but you'll still have to keep the older pepper around to obtain the old hash during checks, creating risks if the attacker gets access to the older pepper and an old db backup. With AES usage, you can throw the old key away once all of your db has migrated and you've updated your key backups. Just make sure you use a suiting AES mode. If it turns out that you xor'd all hashes with the same stream that depends on your pepper only, it's not really helpful :).
notyourday 6y ago
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 6y ago
  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 6y ago
    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.
unlog 6y 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?
- social_quotient 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        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.
        6y ago
deleted 6y ago
[deleted]
mooreds 6y ago
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/bhagavatula-conpro20.pdf https://www.ieee-security.org/TC/SPW2020/ConPro/papers/bhaga... ) 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.SP.800-63b.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
- staticautomatic 6y ago
  Except when you hit a website that refuses your auto-generated strong random password, which happens to me with shocking regularity.
  - bigyikes 6y ago
    Your password must contain at least one special character. Except !, that isn’t allowed.
    - tdrp 6y ago
      The scariest one is when ' is not allowed.
      - jniedrauer 6y ago
        Must include 1 special character, except for the following: ;`'"-
        tdrp 6y ago
        "Our client-side Javascript should be enough to prevent any SQL injection attempts" /s
riazrizvi 6y ago
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.
- penagwin 6y ago
  > so why would anyone use it Because once you salt it (use a different salt for each hash, which solved your collision issue) and purposely slow it down (through multiple rounds,etc) it effectively ruins precomputing the hashes because of how many permutations there are. Of course this depends on which hashing algorithm you use. Md5? You can do millions a second. Bcrypt? You can make one hash take 100ms, that’s 10a second. They also use a random salt for each hash - so precomputed hashes will only work for that hash. The issues you highlighted are very real for md5, but there’s a reason md5 is not recommended for passwords.
- Tainnor 6y ago
  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.
zokier 6y 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 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 6y ago
  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 6y ago
    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 6y ago
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
- tobyhinloopen 6y ago
  Now I want a burger, but it’s midnight. Thanks
- roywiggins 6y ago
  That explains the advice to always salt and pepper your hash.
  - snypox 6y ago
    What a good analogy, right.
- jaza 6y ago
  Mince meat all looks the same to me, so it seems like a poor hashing medium, I would be passing auth 100% of the time, regardless of the cow. (Or dog! Or human!)
- sdflhasjd 6y ago
  An analogy I like to use is a sum of numbers: You take your letters and substitute them for numbers, A = 1, Z = 26. Like a checksum, you add all the letters together. The same word produces the same sum each time, but if I had the sum, I wouldn't know for certain what the original word was.
alerighi 6y ago
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).
- YetAnotherNick 6y ago
  You generally encrypt the hash of the password. Pepper can be thought as a form of encryption.
  - tialaramex 6y ago
    Who is this "you" that will "generally encrypt the hash" ? And no, pepper is not encryption. Encryption is reversible, you can decrypt the ciphertext with the key. Hashing isn't encryption / Confidentiality isn't integrity / RAID isn't backup / Income isn't profit Not knowing the difference doesn't mean there isn't a difference.
    - couchand 6y ago
      What the GP describes is absolutely correct. It may not be all that common but it is a known pattern. That you haven't heard of it doesn't mean it doesn't exist. > An alternative approach is to hash the passwords as usual and then encrypt the hashes with a symmetrical encryption key before storing them in the database, with the key acting as the pepper. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#peppering https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
srtjstjsj 6y ago
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 6y ago
  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...
isoskeles 6y ago
> 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."
laristine 6y ago
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 6y ago
  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 6y ago
    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.
seppel 6y 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?
pkulak 6y 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 "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.
greypowerOz 6y 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? ) 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 6y ago
  It's not guaranteed to be unique.You can have multiple things that hash to the same value.
  - greypowerOz 6y ago
    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....
- torstenvl 6y ago
  Not having a salt means that hashes can be precomputed for common passwords and the exercise of cracking passwords is a simple text search in your precomputed table. Having a salt means that the universe of password:hash correlations is different for each password entry.
- hnick 6y ago
  Rainbow tables: https://en.wikipedia.org/wiki/Rainbow_table https://en.wikipedia.org/wiki/Rainbow_table They are just trying to avoid a quick lookup in a pre-computed table. Adding a salt means they have to start from scratch. Uniqueness is not really a factor, reversibility is. Given a hash will be fixed-length, and passwords can be an arbitrary length, you get a very large number of passwords mapping to each hash. But the key is to make them hard to find. So for the server it's good to have a strong (which often means slow to compute) and non-broken scheme. Something like MD5 is just too fast to compute, if someone is targeting you in particular (and not the entire breach) you might have a bad time anyway. Some schemes have a work factor meaning the computer basically repeats calculations a lot to waste time, which a cracker would also have to do. This factor can be updated to keep up with computing power over time. On the client the best you can do is not reuse passwords, make them long, and try not to overlap with any known wordlists (dictionaries, past breaches, etc).
rl3 6y ago
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 6y ago
  The cult of JWT really bothers me.
  - rl3 6y ago
    I want to like JWT, but in practice I find it overkill for many scenarios, just contributing to further complexity and dependency bloat.
- rl3 6y ago
  More reactionary downvotes, please. Downvote this, too.
btilly 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.
- smartbit 6y ago
  Here another alternative https://news.ycombinator.com/item?id=24381061 https://news.ycombinator.com/item?id=24381061 Wonder which one your teenage son likes better? Of course the answer can be skewed one way or the other knowing which one was written by his parent :-)
c3534l 6y 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'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.
Nightshaxx 6y 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-"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 6y ago
  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.
oshea64bit 6y ago
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.
tmp538394722 6y ago
> 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.
- siscia 6y ago
  I actually like this one! Great work! I never hear about the term "workshopping copy" but I believe it is one of those underrated skills that is fundamental in communication online.
- wffurr 6y ago
  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.
dustinmoris 6y ago
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 6y ago
  I can't change my face. I can change all my passwords, though. Also, I don't own an iPhone.
  - tialaramex 6y ago
    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.
  - Jaruzel 6y ago
    This is why I don't like bio-metrics... I can have a near infinite number of passwords, but I only have 1 face, or 10 fingers. When all of my fingerprints are compromised, and the system only allows fingerprint login, now what do I do ?
- tialaramex 6y ago
  iOS 14 is announced to include a platform authenticator for WebAuthn that does exactly this. Pixel family and similar Android phones already do this.
- snypox 6y ago
  What happens if your face gets deformed in an accident? You unlock your phone with a pincode a re-add your face id?
dustinmoris 6y 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. 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...
Ice_cream_suit 6y ago
The article explains salted hashes, reversing salted hashes and the benefit of using bcrypt very well.
faeyanpiraat 6y ago
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?
- GordonS 6y ago
  > If your email is compromised, the attacker can request a password reset, then log in that way. Doesn't this answer your own question? (ideally email password reset should also require MFA) As another, non-security point, occasionally it can take a good few minutes for emails to arrive in your inbox. Though to be fair, that's sometimes the case for SMS too.
  - faeyanpiraat 6y ago
    I dont see how it would answer my question. If you can log in with a password, you have 1 way to get hacked (lose the pw). If you can also log in through a pass reset, then you have 2 ways to get hacked. MFA helps, but if I remember correctly Troy shared disappointing statistics about it’s usage by the general public.
- mleonhard 6y ago
  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.
Ahmd72 6y ago
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 6y ago
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.
bregma 6y ago
Technically, a hash is a one-way encryption. If it's hashed, it's still encrypted.
bitemealienboi 6y ago
This is all so wrong. Even when you hash a password you should always salt and pepper it as well.
JubbaOnJeans1 6y 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's a special place in my heart for people who make security things readable

362 points by mrzool 6y ago

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.

iso8859-1 6y ago
did you read the article? there is no reason to encrypt passwords. scrypt is a popular KDF, i think you'll be fine with that.
- agustif 6y ago
  Yes I did read the article, It's not a password, it's a PDF file, it's contents I store them as plain base64 now, but I'd rather have store them in a more secret fashion in case of a leak... If that makes sense...
  - iso8859-1 6y ago
    for the encryption itself, you can use e.g. LibSodium or AES (in a sensible mode!!!). of course, you'll need a key too, which is where you can use a KDF. but without knowing more about your threat model, it is hard to tell you how to do the key derivation.
    - agustif 6y ago
      Hey thanks, well I'm a bit out of my area here but that sounds helpful and will research it, thanks!!
    - StavrosK 6y ago
      Most of that is too low-level, libsodium/nacl is closer to what they want.
  - StavrosK 6y ago
    libsodium?
TheDong 6y ago
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-answers.html https://latacora.micro.blog/2018/04/03/cryptographic-right-a...
- agustif 6y ago
  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
cogman10 6y ago
What are you trying to accomplish? I don't know why you are base64 encoding things before sending them to the DB. Just use a binary blob. scrypt is a hashing algorithm, not an encryption algorithm. So that doesn't seem like what you want. LZ-String is a compression algorithm, that's trivially reversible. The problem you'll run into is that the "right" encryption algorithm is constantly changing. Probably the best thing to do would be to not do it yourself, instead, rely on encryption capabilities of your DB if provided. If you opt to doing your own encryption, then be prepared to constantly maintain and update it. Pushing that responsibility onto the DB makes that burden a simple "make sure your DB is up to date" Which you should be doing anyways.

pmontra 6y ago

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

mooreds 6y ago
> Hence, one different password per site to protect also against the sites themselves. Preferably one generated by a password manager, large and random and totally unrelated to any other password of the user.
hinkley 6y ago
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.
- dinosaurdynasty 6y ago
  Do you mean <https://en.wikipedia.org/wiki/Zero-knowledge_password_proof> https://en.wikipedia.org/wiki/Zero-knowledge_password_proof>?
- tialaramex 6y ago
  The Stanford proposal you're talking about was named pwdhash. This approach is sometimes called a "Deterministic password manager" and that might be the phrase you wanted. There are several problems with this approach, especially with regard to the need to sometimes change passwords. But the point your parent was making is that in the modern era (certainly this century) none of this was necessary, there are asymmetric PAKEs which render it unnecessary for a site to know your password at all in order to confirm that you still know what it is.

bvinc 6y ago

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/

tialaramex 6y ago
Terrible crypto design is a recurring feature of Microsoft products too, e.g. the original LANMAN password hash has a maximum password length of 14 characters and just treats all passwords as two separate 7 byte values to verify. If we use MD5(password) then brute force of a 14 character random password (say using a 64 symbol character set) isn't really viable because you need to try about 2^84 values. MD5 isn't an acceptable password hash, but using a strong random password was enough to save us. But if we use LMhash(password) that same password can be brute forced in just 2^43 operations. This design is so bad that there's no way for the user to protect themselves. This popularized Rainbow Tables. You may use a time-space tradeoff for any hashing scheme that doesn't have salt, or doesn't have enough salt compared to how much it's used, but for most schemes a strong random password overwhelms the power of the time-space tradeoff anyway. Rainbow Tables tilt this tradeoff so that it's more favourable in exchange for a modest reduction in effectiveness† and for LANMAN they're enough to turn it from "If you had a super computer and hundreds of gigabytes of disk space you could crack any Windows password hash near instantly" to "If you have a mid-range PC with 5GB of hard disk space and download this software you can crack 99.9% of Windows password hashes in a few minutes". †For a lot of pre-computation effort you can get all the effectiveness back. But that's not important here.
wglb 6y ago
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.

JeanMarcS 6y ago

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.

dvt 6y ago

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

edflsafoiewq 6y ago
> It's arguably much easier to implement than salt Salting is easier since it can be completely wrapped up in the key derivation function. The programmer doesn't have to know anything about it, they just use generate_key(passwd) and check_password(passwd, key).
zemnmez 6y ago
you really shouldn't be implementing your password hashing algorithm from basic crypto primitives. s/bcrypt works right out of the box with no config.
mberning 6y ago
I have wondered the same thing. Make it a piece of data that comes in from the environment or a secrets manager. It’s not bulletproof, but if done correctly seems like it makes the whole hashing scheme a little better.
- lookingfj 6y ago
  If you are doing this isn't it pretty much the same as encrypting it with a key?
  - liambuchanan 6y ago
    encryption is non-deterministic
    - iso8859-1 6y ago
      if that was true, this article wouldn't exist: https://en.wikipedia.org/wiki/Deterministic_encryption https://en.wikipedia.org/wiki/Deterministic_encryption

saagarjha 6y ago

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

miles 6y ago

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-29429.html https://www.tomsguide.com/us/8-character-password-dead,news-... "Any eight-character password hashed using Microsoft's widely used NTLM algorithm can now be cracked in two and a half hours."

samsgro 6y ago
Troy is sarcastically explaining that this is a "good password" according to older password complexity rules, but a horrible password given predictable password substitution logic. Password complexity rules accomplish little. Obligatory xkcd comic link: https://xkcd.com/936/ https://xkcd.com/936/
i-am-curious 6y ago
Won't you add a seed before hashing. With a 8 byte seed that's 16 effective characters, probably impossible to crack.
- kohtatsu 6y ago
  You add a salt, which is stored plaintext alongside the password.
- __s 6y ago
  By seed you mean salt. Salts are stored in plaintext, so they don't increase the entropy of the password. Instead they make it so that each password hashes uniquely so that everyone with the same password gets different hashes. They also mitigate rainbow tables by effectively requiring the attacker to create a rainbow table per target
  - i-am-curious 6y ago

UnicycleSkewer 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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.
est31 6y ago
I don't see any downsides. As you point out, upgrading hashed peppers isn't as beautiful. Yes, you can just introduce a new pepper and wrap the old hash into another hash using the new pepper, but you'll still have to keep the older pepper around to obtain the old hash during checks, creating risks if the attacker gets access to the older pepper and an old db backup. With AES usage, you can throw the old key away once all of your db has migrated and you've updated your key backups. Just make sure you use a suiting AES mode. If it turns out that you xor'd all hashes with the same stream that depends on your pepper only, it's not really helpful :).

notyourday 6y ago

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 6y ago
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 6y ago
  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.

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

social_quotient 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.
      - 6y ago

deleted 6y ago

[deleted]

mooreds 6y ago

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/bhagavatula-conpro20.pdf https://www.ieee-security.org/TC/SPW2020/ConPro/papers/bhaga... ) 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.SP.800-63b.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

staticautomatic 6y ago
Except when you hit a website that refuses your auto-generated strong random password, which happens to me with shocking regularity.
- bigyikes 6y ago
  Your password must contain at least one special character. Except !, that isn’t allowed.
  - tdrp 6y ago
    The scariest one is when ' is not allowed.
    - jniedrauer 6y ago
      Must include 1 special character, except for the following: ;`'"-
      - tdrp 6y ago
        "Our client-side Javascript should be enough to prevent any SQL injection attempts" /s

riazrizvi 6y ago

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.

penagwin 6y ago
> so why would anyone use it Because once you salt it (use a different salt for each hash, which solved your collision issue) and purposely slow it down (through multiple rounds,etc) it effectively ruins precomputing the hashes because of how many permutations there are. Of course this depends on which hashing algorithm you use. Md5? You can do millions a second. Bcrypt? You can make one hash take 100ms, that’s 10a second. They also use a random salt for each hash - so precomputed hashes will only work for that hash. The issues you highlighted are very real for md5, but there’s a reason md5 is not recommended for passwords.
Tainnor 6y ago
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.

zokier 6y 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 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 6y ago
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 6y ago
  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 6y ago

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

tobyhinloopen 6y ago
Now I want a burger, but it’s midnight. Thanks
roywiggins 6y ago
That explains the advice to always salt and pepper your hash.
- snypox 6y ago
  What a good analogy, right.
jaza 6y ago
Mince meat all looks the same to me, so it seems like a poor hashing medium, I would be passing auth 100% of the time, regardless of the cow. (Or dog! Or human!)
sdflhasjd 6y ago
An analogy I like to use is a sum of numbers: You take your letters and substitute them for numbers, A = 1, Z = 26. Like a checksum, you add all the letters together. The same word produces the same sum each time, but if I had the sum, I wouldn't know for certain what the original word was.

alerighi 6y ago

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

YetAnotherNick 6y ago
You generally encrypt the hash of the password. Pepper can be thought as a form of encryption.
- tialaramex 6y ago
  Who is this "you" that will "generally encrypt the hash" ? And no, pepper is not encryption. Encryption is reversible, you can decrypt the ciphertext with the key. Hashing isn't encryption / Confidentiality isn't integrity / RAID isn't backup / Income isn't profit Not knowing the difference doesn't mean there isn't a difference.
  - couchand 6y ago
    What the GP describes is absolutely correct. It may not be all that common but it is a known pattern. That you haven't heard of it doesn't mean it doesn't exist. > An alternative approach is to hash the passwords as usual and then encrypt the hashes with a symmetrical encryption key before storing them in the database, with the key acting as the pepper. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#peppering https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

srtjstjsj 6y ago

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 6y ago
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...

isoskeles 6y ago

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

laristine 6y ago

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 6y ago
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 6y ago
  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.

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

pkulak 6y 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 "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.

greypowerOz 6y 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? ) 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 6y ago
It's not guaranteed to be unique.You can have multiple things that hash to the same value.
- greypowerOz 6y ago
  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....
torstenvl 6y ago
Not having a salt means that hashes can be precomputed for common passwords and the exercise of cracking passwords is a simple text search in your precomputed table. Having a salt means that the universe of password:hash correlations is different for each password entry.
hnick 6y ago
Rainbow tables: https://en.wikipedia.org/wiki/Rainbow_table https://en.wikipedia.org/wiki/Rainbow_table They are just trying to avoid a quick lookup in a pre-computed table. Adding a salt means they have to start from scratch. Uniqueness is not really a factor, reversibility is. Given a hash will be fixed-length, and passwords can be an arbitrary length, you get a very large number of passwords mapping to each hash. But the key is to make them hard to find. So for the server it's good to have a strong (which often means slow to compute) and non-broken scheme. Something like MD5 is just too fast to compute, if someone is targeting you in particular (and not the entire breach) you might have a bad time anyway. Some schemes have a work factor meaning the computer basically repeats calculations a lot to waste time, which a cracker would also have to do. This factor can be updated to keep up with computing power over time. On the client the best you can do is not reuse passwords, make them long, and try not to overlap with any known wordlists (dictionaries, past breaches, etc).

rl3 6y ago

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 6y ago
The cult of JWT really bothers me.
- rl3 6y ago
  I want to like JWT, but in practice I find it overkill for many scenarios, just contributing to further complexity and dependency bloat.
rl3 6y ago
More reactionary downvotes, please. Downvote this, too.

btilly 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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.
smartbit 6y ago
Here another alternative https://news.ycombinator.com/item?id=24381061 https://news.ycombinator.com/item?id=24381061 Wonder which one your teenage son likes better? Of course the answer can be skewed one way or the other knowing which one was written by his parent :-)

c3534l 6y 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'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.

Nightshaxx 6y 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-"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 6y ago
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.

oshea64bit 6y ago

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.

tmp538394722 6y ago

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

siscia 6y ago
I actually like this one! Great work! I never hear about the term "workshopping copy" but I believe it is one of those underrated skills that is fundamental in communication online.
wffurr 6y ago
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.

dustinmoris 6y ago

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 6y ago
I can't change my face. I can change all my passwords, though. Also, I don't own an iPhone.
- tialaramex 6y ago
  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.
- Jaruzel 6y ago
  This is why I don't like bio-metrics... I can have a near infinite number of passwords, but I only have 1 face, or 10 fingers. When all of my fingerprints are compromised, and the system only allows fingerprint login, now what do I do ?
tialaramex 6y ago
iOS 14 is announced to include a platform authenticator for WebAuthn that does exactly this. Pixel family and similar Android phones already do this.
snypox 6y ago
What happens if your face gets deformed in an accident? You unlock your phone with a pincode a re-add your face id?

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

Ice_cream_suit 6y ago

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

faeyanpiraat 6y ago

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?

GordonS 6y ago
> If your email is compromised, the attacker can request a password reset, then log in that way. Doesn't this answer your own question? (ideally email password reset should also require MFA) As another, non-security point, occasionally it can take a good few minutes for emails to arrive in your inbox. Though to be fair, that's sometimes the case for SMS too.
- faeyanpiraat 6y ago
  I dont see how it would answer my question. If you can log in with a password, you have 1 way to get hacked (lose the pw). If you can also log in through a pass reset, then you have 2 ways to get hacked. MFA helps, but if I remember correctly Troy shared disappointing statistics about it’s usage by the general public.
mleonhard 6y ago
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.

Ahmd72 6y ago

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 6y ago

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.

bregma 6y ago

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

bitemealienboi 6y ago

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

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