Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our Approach to Employee Security Training

pagerduty.com

Post reply on HN
Print view View original

61–70 of 76 posts

Re: Our Approach to Employee Security Training

#61

Post by sverige »

IncRnd wrote: post #45
sverige wrote: post #30

Earlier quoted context omitted.

OK, so "rainbow table" is what we all call them, but frankly I've always found that name to be baffling. Why are they called that? What is the origin of the name? What do they have to do with rainbows? Yes, googling "magic list" will not produce the same results as "rainbow table," but it's a good substitute when teaching non-technical people the concept. It might even help them avoid googling unsuccessfully for the…

A rainbow table is named "rainbow table" due to the lines created on a graph when drawing a continuous line through hash and reduction function chain. The graph can visually appear like a rainbow. A hash function is a one way mapping, and so is a reduction (attempting to invert the hash function but usually failing). Think of it this way: Draw a line from plaintext P on the left to hash output H on the right. Then a…

This makes sense to me. Any idea when they were first called rainbow tables?

Re: Our Approach to Employee Security Training

#62

Post by cyberferret »

mightybyte wrote: post #21
flipp3r wrote: post #3

> Concepts such as rainbow tables can then be explained without having to refer to the actual name; we can just demonstrate that you can create a lookup and call it a “magic list”. Names are there for a reason. "magic list" instead of "rainbow table", seriously? You're teaching a concept and then giving it a slightly different name just to make it sound more edgy. People won't be able to find anything about "magic li…

Completely agree. In particular I think the word "hash" is easy to explain. Just tell them it's kind of like the process of creating corn beef hash. Something goes into the process, and when it comes it it's unrecognizable and and you can reverse the process to get a cow back.

> it's unrecognizable and and you can reverse the process to get a cow back.

I am assuming you meant to type "can't reverse the process" here? (and drop the extra 'and'). Apologies for being seemingly pedantic, but the distinction is important here for the very definition of a hash.

Re: Our Approach to Employee Security Training

#63

Post by Natsu »

alangpierce wrote: post #18
neotrope wrote: post #4

> 2. Don’t shy away from technical details. > The mere mention of the word “hashing” is probably enough to make non-technical employees’ eyes gloss over. So instead I just call it “Magic”. What..? Why state a principle and then tell us how you violate it a few sentences later.

I think the point is that technical terminology and technical details are different things, and the latter is much more important. The alternative is to say "hashing is a technical topic, and technical terms intimidate and confuse people, so we won't mention hashing". Instead, the article says that you should try to make hashing approachable and non-intimidating, since understanding the ideas around hashing will help…

I've taught this exact concept to a non-technical audience before. I simply told them it was like scrambling an egg--you can't "unscramble" it and then explained with hashing, you could scramble an identical egg and get identical results and compare the two scrambled eggs to see if they were identical before being scrambled.

That said, I do wonder how well they understood that explanation.

Re: Our Approach to Employee Security Training

#64

Post by _jal »

skissane wrote: post #34
slavik81 wrote: post #29

Earlier quoted context omitted.

Using the standard name can aid understanding by allowing the audience to connect what you're saying to what they already know. However, if the audience's existing knowledge is tainted by fears, misconceptions and confusion, then the connection may hinder more than it helps. In that case, it might be better to make up a new name so the explanation can stand on its own. I don't know if "magic" was the best choice, but…

One thing I dislike about medical doctors, is many of them try to "dumb things down" when talking to me. I'd much prefer they tell me the correct technical medical terminology. Some of it I already know what it means, and if I don't I can always ask them to explain further, or go look it up and read more about it. (My mother and brother are doctors, and I don't get the feeling they are dumbing things down if I ask th…

Take a notepad, write things down, ask questions. Not necessarily in that order. It is a prop, but it indicates you take this seriously and want to learn more.

Or skip the notepad and just ask questions. In my experience some doctors are just jerks or otherwise terrible at cooperative communication; others recalibrate their explanations.

Re: Our Approach to Employee Security Training

#65

Post by holdmywaffles »

jedberg wrote: post #56
ericpauley wrote: post #49

Earlier quoted context omitted.

In my experience (at a large institution) these phishing tests haven't flagged a user until personal info was actually entered, or some other vulnerable action was taken. Seems like there would be so many false positives otherwise.

Maybe they’ve gotten better since I started ignoring them. But back in the day they flagged you the moment you clicked.

As a security goon, you get pretty detailed reporting on who did what with the email... but you have to decide what to do with it. Punishing and mocking people doesn't work.

A good head of security should be _excited_ for someone who's interested in digging deeper. There's a lot of talk in our field about outreach for security-minded devs and sysadmins (usually called a security champion program).

Re: Our Approach to Employee Security Training

#66

Post by andai »

Natsu wrote: post #63
alangpierce wrote: post #18

Earlier quoted context omitted.

I think the point is that technical terminology and technical details are different things, and the latter is much more important. The alternative is to say "hashing is a technical topic, and technical terms intimidate and confuse people, so we won't mention hashing". Instead, the article says that you should try to make hashing approachable and non-intimidating, since understanding the ideas around hashing will help…

I've taught this exact concept to a non-technical audience before. I simply told them it was like scrambling an egg--you can't "unscramble" it and then explained with hashing, you could scramble an identical egg and get identical results and compare the two scrambled eggs to see if they were identical before being scrambled. That said, I do wonder how well they understood that explanation.

And the scrambles form a unique fingerprint!

Re: Our Approach to Employee Security Training

#67

Post by andai »

CaptainZapp wrote: post #59
wpietri wrote: post #58

Earlier quoted context omitted.

Hah! As I understand it, machines with TIP have a button they're supposed to press as soon as they see a threat. Then any fake threats go away. Weird that they didn't do that in your case.

Maybe there was such a button and they rescan it anyway? After all they have to ensure that there's no other dodgy stuff in there, which may have been obscured by the imposed image.

I hide my real gun behind the fake one.

Re: Our Approach to Employee Security Training

#68

Post by IncRnd »

sverige wrote: post #61
IncRnd wrote: post #45

Earlier quoted context omitted.

A rainbow table is named "rainbow table" due to the lines created on a graph when drawing a continuous line through hash and reduction function chain. The graph can visually appear like a rainbow. A hash function is a one way mapping, and so is a reduction (attempting to invert the hash function but usually failing). Think of it this way: Draw a line from plaintext P on the left to hash output H on the right. Then a…

This makes sense to me. Any idea when they were first called rainbow tables?

2003[1] by Oechslin[2] (extending Hellman's[3] idea):

We call our chains rainbow chains. They use a successive reduction function for each point in the chain. They start with reduction function 1 and end with reduction function t−1. Thus if two chains collide, they merge only if the collision appears at the same position in both chains. If the collision does not appear at the same position, both chains will continue with a different reduction function and will thus not merge. For chains of length t, if a collision occurs, the chance of it being a merge is thus only 1/t.

If you read these, you may get the idea that what people call Rainbow Tables really aren't Rainbow tables but Hash Lookup Tables. That's the price we unfortunately pay when people use the wrong words over time, like "Magic Tables" to describe data structures.

  [1] https://lasec.epfl.ch/~oechslin/publications/crypto03.pdf
  [2] https://lasec.epfl.ch/~oechslin/
  [3] https://ee.stanford.edu/~hellman/publications/36.pdf

Re: Our Approach to Employee Security Training

#69

Post by swiley »

slavik81 wrote: post #29
neotrope wrote: post #4

> 2. Don’t shy away from technical details. > The mere mention of the word “hashing” is probably enough to make non-technical employees’ eyes gloss over. So instead I just call it “Magic”. What..? Why state a principle and then tell us how you violate it a few sentences later.

Using the standard name can aid understanding by allowing the audience to connect what you're saying to what they already know. However, if the audience's existing knowledge is tainted by fears, misconceptions and confusion, then the connection may hinder more than it helps. In that case, it might be better to make up a new name so the explanation can stand on its own. I don't know if "magic" was the best choice, but…

I had a math book in high school that tried using a non standard name to make something sound less scary. I didn’t understand and couldn’t google about it because no one else called it that. I avoided college for a couple years partially because of how hard a time I had with math that year.

Re: Our Approach to Employee Security Training

#70

Post by philipov »

Natsu wrote: post #63
alangpierce wrote: post #18

Earlier quoted context omitted.

I think the point is that technical terminology and technical details are different things, and the latter is much more important. The alternative is to say "hashing is a technical topic, and technical terms intimidate and confuse people, so we won't mention hashing". Instead, the article says that you should try to make hashing approachable and non-intimidating, since understanding the ideas around hashing will help…

I've taught this exact concept to a non-technical audience before. I simply told them it was like scrambling an egg--you can't "unscramble" it and then explained with hashing, you could scramble an identical egg and get identical results and compare the two scrambled eggs to see if they were identical before being scrambled. That said, I do wonder how well they understood that explanation.

A non-technical audience's ability to understand depends entirely on their willingness to even try. Most people just don't care and want you to stop wasting their time, so they put no effort into internalizing an explanation. If you want to teach people security, first make them care about it beyond not getting caught: from an employee's point of view, they don't need to be faster than the tiger, they just have to be faster than their slowest colleague.
Post reply on HN