Comment

moseschrute@lemmy.world ⁨6⁩ ⁨months⁩ ago

I’m not a security expert, but password hashing is mostly to slow down someone from getting all the passwords. You can’t reverse the hash, but you can generate hashes until you find a match. When hashing, you can dial in how much compute it would take someone to try and solve all the hashes in your database. If you used a good password, it will be more difficult to solve your hashed password. But it’s best to change your password as Plex suggests.

So it depends on how secure a password is and how strong of hashing Plex used when storing the hashed passwords. I have no idea if this is like a “this will take a year” or “this will take a billion years” to solve all the hashes. Maybe someone with a security background could chime in.

source

Sort:hotnew top

phoenixz@lemmy.ca ⁨6⁩ ⁨months⁩ ago
Not entirely

Firstly you don’t “generate hashes until there is a match”. You can generate hashes until the end of the universe and you’ll still have only a fraction of all possible hashes.

What typically is used are large lookup tables with hashes from known passwords. You can then take that table, take a hash you got, and look it up.

So firstly, hashes should be salted, and if salted correctly, it’s already extremely much harder to use because these tables no longer work. There are few more things you can do but that pretty much is a hard wall already.

The problem is that many corporate systems out there have horrible security. They either use a hash that has been known to be broken since a long time ago (hello LinkedIn), don’t use salting (hello linkediiiiiinn), or don’t use hashing at all.

It’s because of idiots like these that there are so many accounts with password tables out there

What to do?

Use password managers. Now all your site’s have different, safe passwords and you only need to know one. Use 2FA where possible and supported

source
- moseschrute@lemmy.world ⁨6⁩ ⁨months⁩ ago
  Can you also use a list of common passwords and a ruleset you apply to those common passwords, and then hash(applyRule(commonPassword)) == compromised hash ?
  
  source
  - phoenixz@lemmy.ca ⁨6⁩ ⁨months⁩ ago
    That’d basically how these hash tables work, they have the account and hash and known password so you can do rapid lookups
    
    source
  - AA5B@lemmy.world ⁨6⁩ ⁨months⁩ ago
    I’m not entirely sure what you mean but my password manager alerts when the hash of one of my passwords matches one from a dark web data dump, and prompts me to replace it with a newly generated one.
    
    I’m sure it’s not a unique feature
    
    Admittedly I do have a few bad password, a combination of I don’t see how I could care (like a Reddit alt account) and sites that break the password change automation (yeah I’m lazy)
    
    source
    moseschrute@lemmy.world ⁨6⁩ ⁨months⁩ ago
    I wonder how that works. The point of password hashing is to uniquely scramble your password. So userOneHash(“password”) should give a different output than userTwoHash(“password”) even if they use the same password. So your password manager shouldn’t really be able to generate the same password hash since an infinite number of hashes can be generated from the same password.
    
    source
    -> View More Comments
mic_check_one_two@lemmy.dbzer0.com ⁨6⁩ ⁨months⁩ ago

You can’t reverse the hash, but you can generate hashes until you find a match.

That’s called a rainbow table attack, and that’s why you should salt your hash. This salt basically appends a unique string of characters to every password before it goes into the hash. Let’s say your users are dumb and use “password” for their password. If a hacker has pre-generated a rainbow table, (which is extremely time and resource intensive), then they’ll instantly crack that as soon as they get a match on those common passwords. Even if they haven’t generated a rainbow table, they can just look for identical hashes and guess that those users are using common passwords.

But if you salt it, it’ll slow the hackers down drastically by invalidating their pre-generated table. Each user has their own salt stored alongside the username and hash, so User 1’s hash actually saw “password19,jJ03pa5/-@“ while user 2’s hash saw “passwords)205JrGp02?@-“. Because each of their salts are unique, their resulting hashes are unique too. Even though they used the same password. Now the hackers need to crack the hash for each user, by incorporating the existing salts for each user. They’ll start with the weak and common passwords first, which is why it’s still best practice to use strong passwords. But they can’t actually start the rainbow table process until after they have hacked the info, and they’ll need to create fresh tables for every single user.

source
- BackgrndNoize@lemmy.world ⁨6⁩ ⁨months⁩ ago
  So is this user specific salt word stored in a table somewhere, how does the company decrypt a salted password otherwise, and so if the salt is also stored somewhere alongside the encrypted password, couldn’t the hacker get his hands on both the salt and the password and use that to figure out the password?
  
  source
  - mic_check_one_two@lemmy.dbzer0.com ⁨6⁩ ⁨months⁩ ago
    Yes, the salt is stored right alongside the username and hashed password. The point of the salt isn’t to be unknown; It’s to make every single password unique before it gets hashed, which invalidates the hackers’ pre-generated rainbow tables. It forces them to re-generate their table for each user. Even identical passwords will create different hashes, because the salt is different for each user. Essentially requiring the hacker to brute force every single password, even after they have the database downloaded.
    
    Basically, the hash algorithms are known. There are a few common ones, but they’re all reliable. A rainbow table is generated by running potential passwords through each hash, and saving the results. For a simplified example: maybe for a certain hashing algorithm, “password” generates the hash “12345”. I have a pre-generated table with millions of potential passwords that tells me as much. And I have repeated this for all of the most popular hashes. This gigantic database (literally hundreds of GB in size) of millions of potential passwords and resulting hashes for the most popular algorithms is my rainbow table. This took hours of cooking my CPU to generate.
    
    So I hack an unsalted password database, and find a bunch of hashes that are listed as “12345”. I can now guess that they’re probably using that specific hash algorithm, and can immediately crack a bunch of passwords purely because I have already brute-forced them before I hacked anything.
    
    But now let’s say it’s a salted hash instead. When I hack the database, my pre-generated rainbow tables are useless. Because now “password” is not being hashed as “12345”. It’s being hashed as something entirely different, because the salt is added before it gets hashed. Even if multiple users use “password”, it still doesn’t help me because each of their salts is unique. So even if two different users use “password”, they’ll each return different hashes. So I need to recreate my rainbow table for every single user. Even if two users both used “password” I’ll still need to check each one individually, with their unique salts.
    
    This doesn’t completely invalidate the breach, but it drastically slows down my ability to access individual accounts. The goal is simply to slow me down long enough for the company to be able to send out “hey, change your password” notifications, and for the users to do so. Without a salt, once I have the database, I instantly know which hash the company is using. And I can immediately access a bunch of accounts using my pre-generated rainbow table. But with the salt, I’m still forced to crack each user individually.
    
    To be clear, weak passwords will still crack faster. A good password guessing attack doesn’t just brute force. It starts with known lists of common/popular/weak passwords, because that known list of weak passwords will often get you into an account extremely quickly.
    
    source
  - Amir@lemmy.ml ⁨6⁩ ⁨months⁩ ago
    If the hash is unique per person, hackers need to build a new table per person. It doesn’t matter if the hackers can get their hand on the salt; the point is that they cannot try the common passwords easily for all users; it takes N times as long where N is the number of users with a different salt (hopefully all of them)
    
    source
  - WhyJiffie@sh.itjust.works ⁨6⁩ ⁨months⁩ ago
    the salt does not need to be encrypted. the point of it is that it makes a generic rainbow table useless, because the crackers need to compute hashes themselves for all passwords.
    
    as they said, the purpose of hashing is to slow down the crackers, because they need to find the string that produces that hash. a rainbow table cancels that, it makes password lookup for an account almost instantaneous. but a rainbow table is only really useful for unsalted hashes, because for salted hashes a different rainbow table is needed that takes the salt into account.
    
    source
- ClanOfTheOcho@lemmy.world ⁨6⁩ ⁨months⁩ ago
  Best explanation of salt I’ve ever seen. Thanks!
  
  source
  - uninvitedguest@lemmy.ca ⁨6⁩ ⁨months⁩ ago
    NaCl
    
    source
Waraugh@lemmy.dbzer0.com ⁨6⁩ ⁨months⁩ ago
If they are following best practices then individual hashes should be salted and the database of hashes should be peppered so even if singing brute forces an offline copy of the hashes they wouldn’t result in actual useable passwords.

source
- moseschrute@lemmy.world ⁨6⁩ ⁨months⁩ ago
  I don’t think that’s how salts work. I might be wrong, but I think it works like this
  
  Password + Salt -> Hash
  
  “p@ssword” + “hakf” -> “hifbskjf”
  
  “p@ssword” + “jkjh” -> “gaidjshj”
  
  “p@ssword” + “afgd” -> “afgdufj”
  
  Notice how those 3 users use the same password, but the different salts results in 3 different hashes. That doesn’t make it any harder to crack a single hash, but it means I have to crack the same password 3 times.
  
  source
  - sugar_in_your_tea@sh.itjust.works ⁨6⁩ ⁨months⁩ ago
    You missed the part about pepper. Pepper is something that’s added, like salt, but that isn’t stored with the password. A low security version of this is an environment variable, but it could also be a secure hardware device on the machine.
    
    So it’s more like this:
    
    “p@ssword” + “hakf” + “pepper” -> “hifbskjf”
    
    “p@ssword” + “jkjh” + “pepper” -> “gaidjshj”
    
    If an attacker only has the salt, they’ll “crack” the password into something that’s not the original password: brute_force(“higbskjf”, “hakf”) - > “kdrnskk”. The idea is that it might take a few days for the attacker to recognize the error, and by then the security team has already responded and locked the backdoor.
    
    Even if the passwords are peppered, users should assume their password is compromised and change them. But peppering may prevent a cascade effect from reused passwords.
    
    source
    moseschrute@lemmy.world ⁨6⁩ ⁨months⁩ ago
    I actually didn’t realize pepper was a thing. I mostly do frontend. But that’s really interesting!
    
    source
  - Waraugh@lemmy.dbzer0.com ⁨6⁩ ⁨months⁩ ago
    That’s all you can do though, extend the time it takes to brute force, so I’m not sure what the distinction being made is.
    
    source
    ramjambamalam@lemmy.ca ⁨6⁩ ⁨months⁩ ago
    Response time is critical.
    
    source
    moseschrute@lemmy.world ⁨6⁩ ⁨months⁩ ago
    
    even if someone brute forces an offline copy of the hashes they wouldn’t result in actual useable passwords
    
    I think maybe I misunderstood this part. I thought you were suggesting that salted hashed passwords were uncrackable but maybe I misunderstood this
    
    source
    -> View More Comments