Slack was hacked • Hacker News Board

Re: Slack was hacked

#521

Post by JimmaDaRustla » Mon, Mar 30, 2015, 2:08 PM UTC

typedweb wrote: post #457

JimmaDaRustla wrote: post #256

Earlier quoted context omitted.

Where in the original example was encryption involved? The salt and pepper were only ever used in a hashing algorithm.

The pepper is the key to the encryption, not a hashing algorithm.

Thanks for just ignoring my question - THERE IS NO ENCRYPTION IN THE ORIGINAL ARTICLE, so WHY are you restating that encryption is involved at all?

Straight from the original artical:

  hashed_password = scrypt(password, salt + pepper)

or

  hashed_password = scrypt(scrypt(password, salt),pepper)

Absolutely zero encryption going on here. Therefore, no ability to "decrypt" the pepper result. The pepper IS NOT a key for encryption. Period.

Re: Slack was hacked

#522

Post by ntucker » Mon, Mar 30, 2015, 6:41 PM UTC

saurik wrote: post #514

ntucker wrote: post #378

Earlier quoted context omitted.

Yeah, what I'm getting at is that those posts don't actually come right out and say your code should be calibrating itself regularly. They talk about selecting a work factor by benchmarking your current hardware, but they leave it there, and one might come to the conclusion that once they've measured their hardware, they put "13" in a config file and call it done. I'm advocating for advice like "Don't think about wor…

This doesnt make any sense: the goal of this work factor is to make things slower for the opponent , not my own servers. My estimation of the computational power available to my opponent has nothing to do with how large the web servers I chose to use happen to be.

The recommendation is to make it as slow as you can tolerate, which is based on how fast your web servers are.

Re: Slack was hacked

#523

Post by yellowapple » Mon, Mar 30, 2015, 8:39 PM UTC

homakov wrote: post #402

zaroth wrote: post #365

Earlier quoted context omitted.

"In fact the root of the problem was default Sinatra dependency 'rack-protection'". They were doing the input sanitation, but it wasn't the very first thing in the processing pipeline, since "best practice" was to pipe everything through 'rack-protection' first. Homokov was first to state, this was really a black-swan type bug which 99.9% of the time makes it into production. Apparently, they were doing the "right th…

The parent meant "This probably could've been prevented by disallowing non-number inputs" in SDK libraries. Yes, if SDK would cast everything to digits it wouldn't be possible. It is also quite obvious security-in-depth for a 2FA API. Now they do it. *HomAkov

Or even just input validation on the form itself before passing on to the API, which is more of what I was getting at. I don't know about the details of Authy's setup, but I know that AJAX (for example) supports enforcement of specific value types in text fields.

Basically, the form itself could have (and maybe even should have) required numeric-only values, seeing as Authy's codes are either 6 or 7 digits long and contain no alphabetical or special characters.

Re: Slack was hacked

#524

Post by rudolf0 » Mon, Mar 30, 2015, 10:27 PM UTC

ircmaxell wrote: post #450

rudolf0 wrote: post #255

Earlier quoted context omitted.

A properly implemented, simple pepper can only help password security and can't hurt it. Obviously you first must be using a good, slow algorithm (bcrypt, scrypt, or PBKDF2 with high work factor), but a pepper will only help you. (Let's assume the pepper is an AES key which all hashes are encrypted with.) Yes, many times a dedicated attacker who has read access to your database will also have read access to your sour…

> A properly implemented, simple pepper can only help password security and can't hurt it. Well, yes. But what is the definition of "properly"? There are definitely constructions of "pepper" that look simple, but drastically hurt overall security: bcrypt(hmac(password, key), salt) If hmac returns raw bytes, you're in real trouble: http://blog.ircmaxell.com/2015/03/security-issue-combining-b... It's sort of like the d…

I am well aware of that misuse, as I've exploited it during a CTF before. :)

I would consider using the raw byte-output version of a function a very blatant example of "improper implementation".

Also, I agree regarding encryption. In my example I was actually referring to the random AES key as a pepper, even though it'd probably be better called an "application secret".

Re: Slack was hacked

#525

Post by wolf550e » Tue, Mar 31, 2015, 12:10 AM UTC

dhfromkorea wrote: post #341

mike_hearn wrote: post #176

Earlier quoted context omitted.

You mean like how Authy specialised in two-factor authentication, but still managed to have basic string concatenation bugs that rendered their entire 2FA system bypassable?

hey, that causes some immediate stir in my mind as a user of Authy. Could you share any reference to the incident you mentioned?

http://sakurity.com/blog/2015/03/15/authy_bypass.html

Re: Slack was hacked

#526

Post by kordless » Thu, Apr 02, 2015, 5:13 PM UTC

kolev wrote: post #381

kordless wrote: post #319

Earlier quoted context omitted.

That cow left the barn a while ago.

Oh, yeah? You haven't heard of Let's Chat [0], for example? [0] http://sdelements.github.io/lets-chat/ P.S. To clarify, Let's Chat is not IRC-based, but it's slackish and supports XMPP.

That's awesome. Would love to do a container for it.