191–200 of 526 posts
Earlier quoted context omitted.
If you get the user table, you can log in. If you can log in as (some) users. If you can do that, you can see (some) chat history. edit you can log in if and when you crack some of the hashes.
Incorrect. You can't login with a password hash, you need a password.
Looks like they require Google Authenticator or Duo Mobile app to do two-factor auth. I'm not interested. Why can't they be like Github and just send me a text message? I don't want a dependency on some other company's product to make Slack more secure.
[0] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al...
Earlier quoted context omitted.
It's the most common vulnerability. https://www.owasp.org/index.php/Top_10_2013-A1-Injection
It's the most common vulnerability on the web . It's certainly not the most common vulnerability in projects built under popular non-php frameworks. Under that model, it's harder to create a situation where a SQL injection is possible than not. Edit: Slack's in PHP, I thought it was in RoR for some reason. Oops.
Earlier quoted context omitted.
I think this just goes to show exactly why these systems will become more commonplace. There are only so many security experts to go around. Having all the very best concentrated on a smaller set of services seems like it makes more sense than trying to get a security expert for every service.
I agree, but can't deny self-hosted means your security lapses see less fanfare, which has value to the biggest and most lumberingest risk-adverse organizations
Looks like they require Google Authenticator or Duo Mobile app to do two-factor auth. I'm not interested. Why can't they be like Github and just send me a text message? I don't want a dependency on some other company's product to make Slack more secure.
I hate to be the negative guy, and they were hashing passwords better than 90% of the sites, but it would be SO easy to completely neutralize password leakage when the attacker only has access to the database. https://blog.filippo.io/salt-and-pepper/ tl;dr: Hardcode a second salt in your application code or in an environment variable. Then a database dump is not enough anymore to do any kind of bruteforce. It's simpl…
I generally disagree with hardcoded salts, you should assume everything is compromised in a successful attack. But I'm actually commenting here because I don't see how you can retroactively apply the second salt to a hashed string. Could you please elaborate or share a link? Later edit: I'm referring to your example in your link: salt = urandom(16) pepper = "oFMLjbFr2Bb3XR)aKKst@kBF}tHD9q" # or, getenv('PEPPER') hash…
After hashing the password he is storing the hash along with the users random salt, not retroactively applying the salt a second time.
I hate to be the negative guy, and they were hashing passwords better than 90% of the sites, but it would be SO easy to completely neutralize password leakage when the attacker only has access to the database. https://blog.filippo.io/salt-and-pepper/ tl;dr: Hardcode a second salt in your application code or in an environment variable. Then a database dump is not enough anymore to do any kind of bruteforce. It's simpl…
I generally disagree with hardcoded salts, you should assume everything is compromised in a successful attack. But I'm actually commenting here because I don't see how you can retroactively apply the second salt to a hashed string. Could you please elaborate or share a link? Later edit: I'm referring to your example in your link: salt = urandom(16) pepper = "oFMLjbFr2Bb3XR)aKKst@kBF}tHD9q" # or, getenv('PEPPER') hash…
There's nothing wrong with nesting algorithms (see the Facebook hash onion), so you can use the following scheme:
bcrypt(bcrypt(password, salt), pepper)
bcrypt(old_hash, pepper)So they didn't get the password, ok. But they still have my name, my email, my skype. This completely sucks.
Earlier quoted context omitted.
Exactly!!! Encrypting user data should be a common practice like hashing passwords.
You never decrypt a password however. You only compare the hashed version of the claimed one to the stored hashed version, a one-way operation. What could you do with a one-way encrypted phone number? I'm not able to enter a phone hash to make a call.
The previous comment did make the encryption / hash distinction - though I can totally understand how his post might have been misread that he was recommending the same mechanisms for both sets of data.
Looks like they require Google Authenticator or Duo Mobile app to do two-factor auth. I'm not interested. Why can't they be like Github and just send me a text message? I don't want a dependency on some other company's product to make Slack more secure.