[flipp3r]

> 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 lists" when they want to read more about rainbow tables. Let alone the completely mad communication you'll get with people in the company.

> We implemented magic sodium suffix in our application this week, attackers won't be able to use magic lists when our magic data leaks.

>> What?

> You know, irreversible magic?

>> ...

[merrington]

How many non-engineers would you expect to take the interest/time to investigate rainbow tables after this? Also, if you follow the link to the actual presentation (https://sudo.pagerduty.com/for_everyone/#hashing for the lazy) then you'll see the author DOES indeed call it hashing, before switching to "magic" so as to make it easier for individuals without a technical background to not have to constantly think about what the term means.

Also, if you continue to RTFA,

> That said, I didn’t want to mislead people. So we chose to be clear to them that there is a technical term; it’s just not going to be important for the rest of the content.

If it's someone job to provide reports/updates on something related to the concept, yes they should know it, for anyone else in a non-technical role, why does it really matter?

[fjsolwmv]

It doesn't make it easier though. Hashing makes a hash of the password -- chops it and scrambles it so you can see what it came from. Calling everything "magic" just conflates everything with e everything else, confusing everyone.

[flipp3r]

> Also, if you continue to RTFA,

I RTFpresentations even. Naming Hashing and then switching to Magic is just confusing for everyone involved. Again; it completely ruins effective communication.

> for anyone else in a non-technical role, why does it really matter?

They're getting security training on the topic of hashing. How does it not matter?? Employees will have to adjust their communication to toddler level anytime they need to talk about security to others.

[scrollaway]

> They're getting security training on the topic of hashing. How does it not matter??

They're getting taught good password health. You don't need to know what hashing is to know good password health.

I shouldn't get upset over comments but it's headdeskingly frustrating to read comments like yours from people who should know better and who, ultimately, contribute to worse personal security for everybody. Comments like yours are one of the causes behind many people turning their head away at security, not bothering because the barrier of entry is too high and they're made to feel like if they don't have it perfect why bother.

Damn it. The guy communicated pretty damn well if he got 30 employees switching to password managers on their own without actually saying it's required. So instead of criticizing, take it as an opportunity to learn and revise your beliefs.

[sillysaurus3]

There's no reason to get personal. We're all on the same side here.

[alangpierce]

To be clear, the "magic list" thing is focused on non-engineers, who likely will never need to read or write the term "rainbow table" as part of their job, they just need to be convinced that it's important to use a password manager. The presentation also mentions the technical terminology but switches to less intimidating terminology afterward.

The presentation for engineers uses "hash", "rainbow table", etc without ever using the less intimidating terminology: https://sudo.pagerduty.com/for_engineers/

[alexcnwy]

I think you totally miss the point. Explaining something by analogy can be the most effective way of "getting it". Everyone is different. You definitely cannot make such a bold statement about whether the approach was valid.

[SilasX]

When teaching about bitcoin, I say “scrambler function” instead of “hash function” because it better conveys the intuition of what they do — even though it’s longer and non-standard. (Most people I talk to don’t immediately associate “hash” with “make a hash of the whole thing” ie mess it up).

Although I also make sure to give the “decoder ring” and the end to list the actual standard terms for the concepts discussed.

[sverige]

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 origin of the actual name. (If you know the origin, I'd love to know, and so would the people at Wikipedia.)

[IncRnd]

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 line from H back to P2 (plaintext 2 on the left), which is the output of the reduction function over H. Draw a line from P2 to H2 (output of the hash function over P2). Do this for a little bit of the chain, and you will visually have a rainbow.

You can also get banding, when drawing them linearly instead of left to right, when taking closed chains into consideration.

If someone sees such a graph of a rainbow table, that explains the concept directly. Caching in a table is just the implementation.

[sverige]

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

[IncRnd]

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

[sverige]

Thank you for this.

[IncRnd]

You're welcome.

[ams6110]

A real rainbow represents all colors: the full spectrum. A rainbow table has all possible passwords within its spectrum (8 characters, alphanumeric, or however it's defined).

A non-technical term I might use is to call a rainbow table a "reverse phone book for passwords"

[sverige]

Fair enough, but many (probably most) of the people this training is aimed at have no idea what a reverse phone book is. I haven't seen a physical copy of one for a couple of decades.

Do you have a source for the origin of the name, or is it just what comes to your mind when you think of it?

[tCfD]

Iirc they acquired that nickname because early rainbow tables, which were in plain text or another simple uncompressed format, looked very much like ASCII rainbow patterns in a text editor due to the iterative nature of the key, salt, and hash stepping.

[ams6110]

I don't have a source, but the analogy seems obvious to me. If you're more curious, I guess you could do your own research?

[sverige]

I have, actually. I can't find a reliable source for the origin of the name, even in the original papers written to describe them.

[fjsolwmv]

There's no need to comment if you aren't sharing any information or ideas.

[fjsolwmv]

The people in the training haven't used "magic" recently either, seeing as magic doesn't exist.

[zachrose]

Devising a new, more familiar name for something like hashing is a good idea here because it communicates that “this is a complex thing handled by specialists, but it’s implications are important to us.”

[mightybyte]

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.

[cyberferret]

> 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.

[mightybyte]

Yep, thanks for the correction.

[cbhl]

Concepts can have more than one name. An important part of preparing a training or presentation is understanding your audience, and using names that resonate with them.

If this had been a freshman college crypto class, the word "oracle" (https://security.stackexchange.com/questions/10617/what-is-a...) may have been used instead, to indicate that the exact details of hash reversing can be abstracted away and that the key detail is that it's much faster than brute force would suggest.

[techman9]

> That said, I didn’t want to mislead people. So we chose to be clear to them that there is a technical term; it’s just not going to be important for the rest of the content.