Well, I can't even reset my password. I suspect that's because my registered e-mail address uses the "foo+bar@gmail.com" format (which I use for easier filtering), and something on Slack doesn't like sending those (no e-mail on my inbox, spam folder or filter matches)
Slack was hacked
501–510 of 526 posts
Re: Slack was hacked
#502Earlier quoted context omitted.
It can help in the following scenarios: 1. Hacker steals db but does not compromise web servers (because the hmac pepper key lives on the web servers and not in the db) 2. Hacker can run SQL Injection via web server, but cannot otherwise access web server memory/process 3. HMAC key is stored in a hardware security module and hacker cannot gain physical access
All of the above cases are also helped by just by regular symmetric encryption. Why make things more complicated than necessary?
How is HMAC more complicated than encryption?
Re: Slack was hacked
#503Earlier quoted context omitted.
Maybe it's time for Slack to adopt the Axolotl ratchet, too.
I'd love for them to do that, but there's a couple of problems that they'd have to overcome first. First: Slackbot. This is a Slack-run bot that's in every channel; team owners can customize it to do various things, like scan messages for keywords and give out canned responses. Even if Slack adopted some variant of encrypted chat, each message would still need to be readable by Slackbot, so Slack would still have the…
The first could be solved by having the activation part of the bot run on the clients themselves, and only send those messages in a readable way to the server.
As for the second, the server could ask one of the clients to re-encrypt the channel history with the newcomer's key. It would only fail if nobody was online the moment you joined the channel (and you still could get it later).
Re: Slack was hacked
#504Earlier quoted context omitted.
Because you can't trust SMS-based two-factor authentication. http://en.wikipedia.org/wiki/Multi-factor_authentication#SMS... http://webcache.googleusercontent.com/search?q=cache:UiwfUal...
How does Google Authenticator prevent malware on my phone from approving a login?
That's outside the scope of the tool. You're supposed to prevent malware from compromising your phone. At the very least this scheme requires an attacker to implant malware on your phone as opposed to just monitoring/intercepting communications to and from it.
Re: Slack was hacked
#505Earlier quoted context omitted.
> There's nothing wrong with nesting algorithms This is really vague. What kind of algorithm? With itself, or just anything inside anything else? Passing the raw output of any common cryptographic hash (SHA-x) to bcrypt, for example, completely destroys its security, as bcrypt input is null-terminated. (What happens when you nest DES in A*, anyway?)
Obviously you have to use type safety. You can't cast a binary string to a null-terminated string, you have to convert. That's a problem unrelated to hashing. I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is a great idea.)
> That's a problem unrelated to hashing.
It (poor implementation) is definitely related to implementing pepper on top of a secure password hash, though, which everybody is already doing differently.
> I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is a great idea.)
“algorithm” is, again, really vague. (So is “nesting”.) But for something contrived and not snarky, here:
h = sha512_hex(password)
sha512_hex(bcrypt(h, gen_salt()) +
bcrypt(h, gen_salt()) +
bcrypt(h, gen_salt()) +
bcrypt(h, gen_salt()))
Re: Slack was hacked
#506Earlier quoted context omitted.
Careful. If an attacker is ever able to observe the output for a very short password - one byte, say - then only one byte of your secret salt is used, and the attacker could begin brute-forcing the secret salt starting with the first byte. XOR could also result in NULL bytes anywhere in the hash input, which could drastically weaken passwords,. For example, bcrypt ignores any password characters after the first NULL…
>Careful. If an attacker is ever able to observe the output for a very short password - one byte, say - then only one byte of your secret salt is used, and the attacker could begin brute-forcing the secret salt starting with the first byte. Can you be kind enough to explain with a very simple example? I would appreciate understanding your point - Thank you
Using the scheme above, a password of "a" would result in a hash H('a' ^ x) where x is the first byte of the secret salt. The attacker can simply test all possible values of x (there are only 256) to determine the value of that byte. Knowing the first byte, the attacker can then look at a two-byte password and repeat the process to brute-force the second byte.
(It's also possible to brute-force more than one byte at a time; it would just take longer. For example if the shortest password the attacker can observe is 6 bytes then they would need to try 2^48 possibilities.)
Re: Slack was hacked
#507Earlier quoted context omitted.
If anyone from Slack is reading this, the encryption should be an option, even if it means disabling or substantially slowing the search feature.
If they encrypted it, Slack would have to hold the key, so that all users in an org can then read existing messages.
No, it could be a private key shared among users.
Re: Slack was hacked
#508Earlier quoted context omitted.
Skype is really bad for text chat. - It is closed-source, obfuscated, and untrustworthy overall ( https://www.eff.org/secure-messaging-scorecard ). - The supported (Windows and Mac) versions have obnoxious ads, and the Linux version is buggy and 32-bit-only. - Since it’s P2P-ish (which makes sense for audio and video calls), you can’t send a message to someone who’s offline and expect them to be notified (say, via e-…
- It is closed-source, obfuscated, and untrustworthy overall ( https://www.eff.org/secure-messaging-scorecard ). and Streak is open source? - The supported (Windows and Mac) versions have obnoxious ads, and the Linux version is buggy and 32-bit-only. I have the Mac version of Skype, where are the ads? - Since it’s P2P-ish (which makes sense for audio and video calls), you can’t send a message to someone who’s offline…
Yes, I know. What point are you trying to make here? curiously asked:
> is there anything that slack does you can't do with skype?
So I named some things. Mostly being not P2P. I also prefer IRC over Slack, although you do need to have some system in place for staying connected all the time or receiving logs to make it workable for everyone.
Anyway, re: your points:
> and Streak is open source?
Slack? No, but I don’t have to allow arbitrary code to run free on my computer to use it.
> I have the Mac version of Skype, where are the ads?
Maybe they’re gone. Windows certainly still has them.
> etcetera
Sure, it’s P2P. That’s a fine excuse, but it also doesn’t make Skype good.
Re: Slack was hacked
#509Earlier quoted context omitted.
I'm definitely not an expert, but my understanding is that a per-user salt, which Slack was using, protects against brute-forcing bad passwords. So assuming a reasonable work factor, it really should be computationally unfeasible to retrieve these passwords. That said, I'll change mine, because why not.
A per-user salt doesn't prevent brute forcing bad passwords. The purpose of a per-user salt is to prevent brute forcing all of the passwords simultaneously. Without it, you could just hash a password once and check against all the passwords. With the salt, you have to hash each guess for each user. It certainly increases the work, but with bad passwords, its likely you'll always crack a few in a large dump. If you ha…
Of course, thanks. Guess I wrote that without actually thinking about it. Now, a pepper would prevent brute forcing weak passwords, assuming it wasn't compromised, but that's not relevant here. And regardless I agree with your logic regarding forcing a reset.
Re: Slack was hacked
#510Earlier quoted context omitted.
It's not "thou shalt not talk about cryptography." It's "cite your sources."
If you're pointing out a gaping flaw, you don't need a source. If you're suggesting a standard security measure, you don't need a source. To insist on something novel, yes you want a source.
I would agree, except "standard security measures" aren't and you lead to travishamockeries like the pepper nonsense. Which is why I default to, "cite your sources."