You can complete these exercises in JavaScript or Ruby.
- If you're using Ruby, refer to these RubyDocs:
... and you should probably work in irb.
- If you're using JavaScript, refer to these NPM libraries:
... and start with this Codepen.
We'll provide timing constraints on the board. If you're moving quickly and feeling confident, complete the Extension questions. But if you're not, make sure you complete all the non-Extension exercises first.
You've done some hash building in the physical space. Let's practice doing it with the machine, using better algorithms. Collaborating with the person next to you, experiment and discuss answers to these questions:
- What is the MD5 digest of your snack string?
- What is the Sha256 digest of the same string?
- Repeat both MD5 hashing and Sha256 hashing, but change the input to include a one-letter-off typo. What do you notice about the output? What if you add a blank space to the end of the string? What if you change the capitalization of one letter?
- Multiply your string 1000x (like "chipschipschipschips..." and hash it again through each algorithm. What's notable about the output as compared to previous runs?
Then, in your own notebook, jot quick notes to solidify your learning:
- How does a small change to the input of a hash change the output?
- Why does the answer to "A" matter?
- How does a massive change to the size of the input change the output?
- Based on this analysis, can you come up with three potential use cases for hash functions *besides* passwords?
Feeling good about hashing? Try answering these questions:
- Which algorithm (MD5 / Sha256) is faster? Can you prove it using a dataset of at least 200 inputs and calculating the percentage speed difference?
- Is the percentage difference consistent if you increase the size of each individual input data by 100 times?
- Is there a scenario where you'd want to intentionally choose a slower algorithm? Why?
Let's test your understandings by completing this section on your own. Use your pair as a resource if you get stuck, but try to complete the work on your own.
A hashing function is said to be "one-way" which is often useful in security, but it's not fool-proof. Say you hack into my application and are able to retrieve all my users' hashed passwords. You find that the account with username boss@example.com has this hashed password:
3e40106b8f4332e18d76e94124d9c82a
Based on the length of the digest you guess it's an MD5. You know that some users, particularly bosses, are lazy and they do dumb things like re-use their 4-digit ATM pin for their password. But the application required a password of eight digits, so they might have repeated the pin.
Work out answers to the following questions in your notebook:
- What's this user's password?
- Would the user's password have been "more secure" if they used eight letters rather than eight numbers? Explain your thinking.
A "rainbow table" makes this reverse engineering much faster.
- Can you generate a CSV file that has two columns: the first column contains all possible 8-digit codes following the 4+4 rule above, then the second column has the MD5 digest for that input.
- If you now have an MD5 digest for an input that is expected to follow the 4+4 rule, how long does it take you to "crack" a password using the rainbow table?
- Could you generate a similar table for the all words of eight or more letters in the dictionary? (hint: you have a text file dictionary on your filesystem at
/usr/share/dict/words) - Some developers choose to make passwords more obscure by applying the hashing algorithm more than once (ie: original input into the algorithm, then that output into the algorithm again). Can you expand your dictionary table with columns for double-hashing, quad-hashing, and octo-hashing? As our time is limited, you might need to constrain your input set ;)