> 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.
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 people understand why strong passwords and password managers are important.
That said, I do wonder how well they understood that explanation.
I don't know if "magic" was the best choice, but you can still explain all the details of how it works even if you call it something else.
(My mother and brother are doctors, and I don't get the feeling they are dumbing things down if I ask them for medical advice.)
A professional who talks about technical details, even if I don't completely understand those details, gives me the impression that they know what they are talking about, and that makes me feel confident in their abilities.
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.
 Using a mathematical concept known as "hashing"---see [link] for futher information.
 These are bad passwords; used for an example only.
 Not quite impossible, but very darned near impossible. See [link] for more information.
Yes. One of the best trainings I've been on was in my first job.
40+ minutes on... how to adjust your chair, by the health and safety manager. From how to position the arms, to spinning the chair over and adjusting the springyness of the tilt, to levelling the height against a screen. Almost 2 decades later, I remember the take-aways clearly.
Heck, that can even make it easy to slip discussion of "salting" in there.
I can highly recommend giving it a try. The first few levels of difficulty are easy to spot, but it's been eye opening for me how sophisticated phishing emails can get.
It reminds me of the luggage-scanner technology Threat Image Projection: https://www.rapiscansystems.com/en/products/rapiscan-threat-...
Basically I think there's an optimum frequency window for humans detecting and responding to problems. Once real occurrences drop below that frequency, we need to supplement with simulations. Fire drills are the obvious example, but I think we could use a lot more of it.
Yeah, thanks to those I once was asked what that huge hypodermic needle is doing in my hand luggage. I didn't really have a clue and it disappeared, when they scanned it for the second time.
It was an European airport with reasonable security scanners so overall it was a quite funny experience.
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 hate those tests. I've been doing anti-phishing work since before the term was coined, and I fail every one of those tests. Why?
Because I load up a virtual env and click on every link in them to see how good of a phish it is.
I suspect this is a problem limited to a very small set of people, but none the less, it's annoying when our head of security comes over and says, "shouldn't you know better?"
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).
Why don't you enjoy the opportunity to show off your cleverness to head of security?
Instead, it's a matter of understanding that most attacks involve several pivot points; and that these pivots are possible because we treat internal networks as if they are "safe spaces" where we can let our guard down.
Obviously it's impossible for compromising credentials to have no consequences -- if case, why do you have credentials?
For systems that only require a username and password to log in, someone else obtaining/guessing my credentials would have the consequence of someone being able to access my account. But if there's a second credential I have to enter in addition to the username and password, then someone trying to use the username and password alone would not be able to access the account.
Where I work, this second credential is the RSA token along with a PIN. But this could also be accomplished by using a client side TLS certificate on the work provided device or U2F with a work issued Yubi key.
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.
> You know, irreversible magic?
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?
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.
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.
The presentation for engineers uses "hash", "rainbow table", etc without ever using the less intimidating terminology: https://sudo.pagerduty.com/for_engineers/
Although I also make sure to give the “decoder ring” and the end to list the actual standard terms for the concepts discussed.
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.)
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.
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.
A non-technical term I might use is to call a rainbow table a "reverse phone book for passwords"
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?
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.
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.
What Rich has done amazingly well here is use the correct term, but then made the “magic” analogy that allows the concept to be more easily understood by people not within engineering. Think sales, marketing, HR, biz dev, etc.
For those who are interested, they can look up more about hashing afterwards. But for everyone, the concept of how hashes are used was taught with high retention rates.
Ie, the value isn't in the word choice itself, but rather in signalling that you empathize with your audience's discomfort.