11 ms·

> Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that your password could be recreated

by eridius 12y ago

> Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that your password could be recreated from the hashed form. Is this true even when the attacker is specifically focusing on a single account, or is it only computationally infeasible to recover passwords for accounts in general?

NobleLie 12y ago
Coincidentally, I was just looking into your question; this should answer your concern. "Since every user has their own unique random salt, two users who happen to have the same password get different salted hashes. [If] the dictionary attack is foiled, the attacker cannot compute the hashes of every word in a dictionary once and then check every hash in the table for matches anymore. Rather, the attacker is going to have to re-hash the entire dictionary anew for every salt. A determined attacker who has compromised the server will have to mount an entire new dictionary attack against every user's salted hash, rather than being able to quickly scan the list for known hashes." [0] [0]: http://www.developerfusion.com/article/4679/you-want-salt-with-that/3/ http://www.developerfusion.com/article/4679/you-want-salt-wi...
- eridius 12y ago
  Yeah, salts mean you can't use rainbow tables. But you can still attack a single user. The question is what "computationally infeasible" actually means. How much computing power would it take to crack a single user's password? How about if it's a weak one? A strong one? If the answer is "it would take $1000 worth of Amazon EC2 computing to crack a single weak password", well, that's certainly feasible to do if you have a specific target in mind.
  - azinman2 12y ago
    And given th usernames and emails are out there, it reveals (a) all the companies using slack, (b) potentially very high value targets. I wonder who they had specifically emailed. My guess is those people aren't using slack anymore.
  - Xylakant 12y ago
    The answer depends on the tuning parameters used for the bcrypt hashing (cost/work factor) and the length of the user password. Obviously a 1-character password will fall even with a high workfactor and a dictionary word will probably fall as well. This paper http://www.emsec.rub.de/media/crypto/veroeffentlichungen/2014/10/22/reconfig14_bcrypt.pdf http://www.emsec.rub.de/media/crypto/veroeffentlichungen/201... tags some numbers on breaking passwords with a low cost factor. Assuming a cost factor if 5 (12 would be more "real" world) and an 8 character password with an alphabet of 62 chars (uppercase, lowecase, 10 digits) the estimated cost to break a password within a month is in the millions with dedicated hardware designed for brcypt breaking (Fig 5). With a work factor of 12, an 8 character password will not break on EC2.
    - eridius 12y ago
      I knew bcrypt was tunable, and I guess I was hoping someone from Slack would actually pop up and say how their bcrypt was tuned (which I guess means what the cost factor is). But you do have some good info, I wasn't aware of what expected cost factors were and how secure a single password would be at those cost factors. I'm assuming that your "8 character password" is assuming a randomly-generated password. I'm curious what the expected cost would be of breaking a particularly weak one (e.g. a human-generated password, based on dictionary words although perhaps with mnemonic devices or letter/number substitutions). The paper you linked says their hardware computed 6511 passwords per second at a cost factor of 5, and based on the cycle costs listed, I'm thinking it does 52 passwords per second at a cost factor of 12. Assuming a particularly weak password, I don't know how many passwords a brute-forcer would expect to have to try before hitting the correct one.
- tracker1 12y ago
  running the top 10k passwords on each hash will likely get quite a few hits, and not take much compute time... the overlap to accounts that are owner/admin accounts is unknown.. just the same entirely possible. (not counting for slack's password complexity requirements)
  - eridius 12y ago
    Going by the paper linked in Xylakant's comment (https://news.ycombinator.com/item?id=9277780 https://news.ycombinator.com/item?id=9277780), if the cost factor was 12, using dedicated hardware would let you test 52 passwords per second. So that would take 192 seconds to try 10k passwords against a single hash. If you were to run this for a month straight you'd have tested 13675 accounts. Slack has over half a million daily active users (and I'm not sure if that stat actually means daily active accounts, or daily active people (who may have multiple accounts on different teams)). The paper goes into estimated costs as well, but I'm not going to dig through it to figure out how much it would actually cost to run that hardware for a month straight. And of course it's talking about dedicated hardware, which Slack's hacker almost certainly doesn't have.
emerongi 12y ago
It's feasible if you use a commonly used password or if the attacker knows specific information about you or your password. Otherwise, it is pretty much impossible. // this is about focusing on a single account. Nobody would ever bother with trying to crack the whole DB.
- tracker1 12y ago
  Not only that, but along with the email you may have higher value targets that you will spend more time checking or trying to brute force. Even if it's a gmail user, if you get them, and they use the same password on their mail, poof, you're in. What gets me is that banks of all places have the worst password abilities (for their web logins)... case insensitive, only letters and numbers.
jahewson 12y ago
The salt helps to defeat anyone who has pre-computed bcrypt tables for large numbers of passwords. It forces the attacker to have to compute all the hashes themselves, even for a single user.
Yen 12y ago
quick answer - It's probably computationally infeasable to gain access to any specific account, or all accounts in the database. It's probably feasible to gain access to at least one account in the database, if it has a weak password. Hashing functions like bcrypt are intentionally set up to be computationally expensive, so that when brute-forcing a password, attackers can only try, say, 1 thousand passwords per second, not 10 million, on any given computational unit. The exact numbers of attempts-per-second depends on the attacker's computer, and the exact setup of their password hashing. When trying to find the password for a particular hash, which is a hash of a strong password, there's really no better way than trying all possible passwords, hashing them, and seeing if they match. When attacking a whole database at once, sometimes you get lucky and some accounts have weak passwords, and those you crack quickly.
- deleted 12y ago
  [deleted]
biot 12y ago
Yes, depending on the work factor chosen. See http://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/#benchmarks http://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/#b... for a table of work factors and associated time to check a single password. The work factor is a trade-off involving burning CPU cycles, load on the servers processing logins, and user experience. If you choose a work factor resulting in each password verification taking half a second, it's essentially computationally infeasible to brute force any decently chosen password. Someone could go through the list of the top million passwords in a week of CPU time and, because each hash has its own randomly generated salt, the effort spent cracking one user's password yields no insight into anyone else's password; the entire effort needs to be repeated per user. If your password has sufficient entropy (eg: long and randomly generated, not appearing in any password lists) then -- barring some revolutionary mathematical breakthrough -- you don't need to worry about someone discovering your password before the heat death of the universe.

by eridius 12y ago

NobleLie 12y ago

Coincidentally, I was just looking into your question; this should answer your concern. "Since every user has their own unique random salt, two users who happen to have the same password get different salted hashes. [If] the dictionary attack is foiled, the attacker cannot compute the hashes of every word in a dictionary once and then check every hash in the table for matches anymore. Rather, the attacker is going to have to re-hash the entire dictionary anew for every salt. A determined attacker who has compromised the server will have to mount an entire new dictionary attack against every user's salted hash, rather than being able to quickly scan the list for known hashes." [0] [0]: http://www.developerfusion.com/article/4679/you-want-salt-with-that/3/ http://www.developerfusion.com/article/4679/you-want-salt-wi...

eridius 12y ago
Yeah, salts mean you can't use rainbow tables. But you can still attack a single user. The question is what "computationally infeasible" actually means. How much computing power would it take to crack a single user's password? How about if it's a weak one? A strong one? If the answer is "it would take $1000 worth of Amazon EC2 computing to crack a single weak password", well, that's certainly feasible to do if you have a specific target in mind.
- azinman2 12y ago
  And given th usernames and emails are out there, it reveals (a) all the companies using slack, (b) potentially very high value targets. I wonder who they had specifically emailed. My guess is those people aren't using slack anymore.
- Xylakant 12y ago
  The answer depends on the tuning parameters used for the bcrypt hashing (cost/work factor) and the length of the user password. Obviously a 1-character password will fall even with a high workfactor and a dictionary word will probably fall as well. This paper http://www.emsec.rub.de/media/crypto/veroeffentlichungen/2014/10/22/reconfig14_bcrypt.pdf http://www.emsec.rub.de/media/crypto/veroeffentlichungen/201... tags some numbers on breaking passwords with a low cost factor. Assuming a cost factor if 5 (12 would be more "real" world) and an 8 character password with an alphabet of 62 chars (uppercase, lowecase, 10 digits) the estimated cost to break a password within a month is in the millions with dedicated hardware designed for brcypt breaking (Fig 5). With a work factor of 12, an 8 character password will not break on EC2.
  - eridius 12y ago
    I knew bcrypt was tunable, and I guess I was hoping someone from Slack would actually pop up and say how their bcrypt was tuned (which I guess means what the cost factor is). But you do have some good info, I wasn't aware of what expected cost factors were and how secure a single password would be at those cost factors. I'm assuming that your "8 character password" is assuming a randomly-generated password. I'm curious what the expected cost would be of breaking a particularly weak one (e.g. a human-generated password, based on dictionary words although perhaps with mnemonic devices or letter/number substitutions). The paper you linked says their hardware computed 6511 passwords per second at a cost factor of 5, and based on the cycle costs listed, I'm thinking it does 52 passwords per second at a cost factor of 12. Assuming a particularly weak password, I don't know how many passwords a brute-forcer would expect to have to try before hitting the correct one.
tracker1 12y ago
running the top 10k passwords on each hash will likely get quite a few hits, and not take much compute time... the overlap to accounts that are owner/admin accounts is unknown.. just the same entirely possible. (not counting for slack's password complexity requirements)
- eridius 12y ago
  Going by the paper linked in Xylakant's comment (https://news.ycombinator.com/item?id=9277780 https://news.ycombinator.com/item?id=9277780), if the cost factor was 12, using dedicated hardware would let you test 52 passwords per second. So that would take 192 seconds to try 10k passwords against a single hash. If you were to run this for a month straight you'd have tested 13675 accounts. Slack has over half a million daily active users (and I'm not sure if that stat actually means daily active accounts, or daily active people (who may have multiple accounts on different teams)). The paper goes into estimated costs as well, but I'm not going to dig through it to figure out how much it would actually cost to run that hardware for a month straight. And of course it's talking about dedicated hardware, which Slack's hacker almost certainly doesn't have.

emerongi 12y ago

It's feasible if you use a commonly used password or if the attacker knows specific information about you or your password. Otherwise, it is pretty much impossible. // this is about focusing on a single account. Nobody would ever bother with trying to crack the whole DB.

tracker1 12y ago
Not only that, but along with the email you may have higher value targets that you will spend more time checking or trying to brute force. Even if it's a gmail user, if you get them, and they use the same password on their mail, poof, you're in. What gets me is that banks of all places have the worst password abilities (for their web logins)... case insensitive, only letters and numbers.

jahewson 12y ago

The salt helps to defeat anyone who has pre-computed bcrypt tables for large numbers of passwords. It forces the attacker to have to compute all the hashes themselves, even for a single user.

Yen 12y ago

quick answer - It's probably computationally infeasable to gain access to any specific account, or all accounts in the database. It's probably feasible to gain access to at least one account in the database, if it has a weak password. Hashing functions like bcrypt are intentionally set up to be computationally expensive, so that when brute-forcing a password, attackers can only try, say, 1 thousand passwords per second, not 10 million, on any given computational unit. The exact numbers of attempts-per-second depends on the attacker's computer, and the exact setup of their password hashing. When trying to find the password for a particular hash, which is a hash of a strong password, there's really no better way than trying all possible passwords, hashing them, and seeing if they match. When attacking a whole database at once, sometimes you get lucky and some accounts have weak passwords, and those you crack quickly.

deleted 12y ago
[deleted]

biot 12y ago

Yes, depending on the work factor chosen. See http://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/#benchmarks http://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/#b... for a table of work factors and associated time to check a single password. The work factor is a trade-off involving burning CPU cycles, load on the servers processing logins, and user experience. If you choose a work factor resulting in each password verification taking half a second, it's essentially computationally infeasible to brute force any decently chosen password. Someone could go through the list of the top million passwords in a week of CPU time and, because each hash has its own randomly generated salt, the effort spent cracking one user's password yields no insight into anyone else's password; the entire effort needs to be repeated per user. If your password has sufficient entropy (eg: long and randomly generated, not appearing in any password lists) then -- barring some revolutionary mathematical breakthrough -- you don't need to worry about someone discovering your password before the heat death of the universe.