Our Approach to Employee Security Training • Hacker News Board

Re: Our Approach to Employee Security Training

#71

Post by sverige » Sun, May 06, 2018, 3:17 PM UTC

IncRnd wrote: post #68

sverige wrote: post #61

Earlier quoted context omitted.

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…

Thank you for this.

Re: Our Approach to Employee Security Training

#72

Post by Jsharm » Sun, May 06, 2018, 4:01 PM UTC

spc476 wrote: post #44

Jsharm wrote: post #28

Earlier quoted context omitted.

You're right there's some contradiction, but overall I agree technical subjects are nearly always too dumbed down. People are smart! Give them a chance! Boring!=technical. And you can definitely explain hashing in an easy way.

I would substitute "scramble" with "magic". Something like: "The password is scrambled [1] so no one can see what it was originally. Second, this scrambling method ensures the result is the same length as every other password. Third, that very similar passwords, like 'aaaa' and 'aaab' [2] come out very different looking. And it's impossible [3] to descramble it to the original password." [1] Using a mathematical conc…

I was thinking about this, is a good hashing analogy something like mixing paint? Ie a defined set of constituent colours will produce a particular colour paint. But you can't go from a mixed colour back to the constituents. The only way to find out what constituents are required to create a colour is to try lots of constituents.

Re: Our Approach to Employee Security Training

#73

Post by IncRnd » Sun, May 06, 2018, 4:59 PM UTC

sverige wrote: post #71

IncRnd wrote: post #68

Earlier quoted context omitted.

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…

Thank you for this.

You're welcome.

Re: Our Approach to Employee Security Training

#74

Post by u801e » Sun, May 06, 2018, 5:46 PM UTC

fjsolwmv wrote: post #51

u801e wrote: post #27

Are there any initiatives out there that offer training/guidance in designing systems where even if someone's credentials are compromised, it doesn't really matter. When there are systems out there that still store passwords in an insecure manner and don't require a second form of authentication, then all the training in the world about password hygiene and recognizing phishing attempts won't fix the actual problem.

In the research this is called "capabilities", limiting your account, not giving everyone root. Also, there is fraud detection, stuff like automatic alerts when the same credential is used in two places at once, or with unusual access patterns. Obviously it's impossible for compromising credentials to have no consequences -- if case, why do you have credentials?

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

Re: Our Approach to Employee Security Training

#75

Post by BrandoElFollito » Mon, May 07, 2018, 5:57 AM UTC

Jsharm wrote: post #72

spc476 wrote: post #44

Earlier quoted context omitted.

I would substitute "scramble" with "magic". Something like: "The password is scrambled [1] so no one can see what it was originally. Second, this scrambling method ensures the result is the same length as every other password. Third, that very similar passwords, like 'aaaa' and 'aaab' [2] come out very different looking. And it's impossible [3] to descramble it to the original password." [1] Using a mathematical conc…

I was thinking about this, is a good hashing analogy something like mixing paint? Ie a defined set of constituent colours will produce a particular colour paint. But you can't go from a mixed colour back to the constituents. The only way to find out what constituents are required to create a colour is to try lots of constituents.

Oh that's a very good one. I was using the "magic" approach so far but now I am fond to paint colors. Thanks!

Re: Our Approach to Employee Security Training

#76

Post by mightybyte » Sat, May 19, 2018, 1:59 AM UTC

cyberferret wrote: post #62

mightybyte wrote: post #21

Earlier quoted context omitted.

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.

Yep, thanks for the correction.