Quiz

1. Nothing! this is very interesting though :)

   I agree! It's good to know what the experts suggest, what the standards are and why they are useful.

2. I don't think I quite get why an extremely slow hashing algorithm would help increase security? Could you review that one more time?

   For sure. The goal is to thwart brute-force attacks. Since brute-force requires trying lots and lots of passwords, slowing the attacker down is critical.

   If it takes a millisecond to hash a password, the attacker can try a million passwords per second.

   If it takes a second to hash a password, the attacker can try one password per second.

3. For our projects, we have password as varchar(50). Should we switch our passwords to be char(60) ? Can you explain why this number is important with respect to the hashing

   It makes a tiny amount of difference: a bit less overhead (time and space) for char(60) versus varchar(60). So it might be worth doing, because in this class we are trying to think about best practices, and the best practice is that if something is fixed-length, use fixed-length fields.

   But, honestly, it's negligible.

4. Why does bcrypt store the salt inside the hashed password?

   Convenience of the programmer. It's nice to have one return value from the hashpw function and only one thing to store in the database.

5. Are there other effective ways of handling the little snippet of concurrency issue? Or would doing something like a mutex, for example, be unnecessary for this handling?

   Great question! Yes, a mutex would solve the problem of concurrency. The weakness of that is that if we have several web applications running, all in separate processes, we then have to coordinate mutexes across multiple processes. That's much harder.

   Since the DBMS is a single point of access, and the INSERT/EXCEPT technique even works across processes, let's do that.

6. How can we make sure a user doesn't reuse a previously used password, even though bcrypt creates a new unique hash each time?

   Another great question! We could have a second table of old passwords (1:N relationship with the USER table), and we check that their "new" password doesn't successfully hash to any of those old values, then we can accept the new password.

7. Would we place the code for hashing the passwords in gitignore?

   I'm not sure why you would think so; there must be some misconception. I can think of two, but I could be wrong.

   1. You're concerned that the code for hashing passwords will reveal the passwords.

      That's not the case. The hashed passwords are in the database; the contents of the database is a matter of security. It should be kept secret. But it's not being put in Github. Github only saves files in your directory.

      Of course, if you mysqldump the contents of the database to your directory and then commit and push that dumped file to Github, that would be bad. So don't do that.

   2. You're concerned that the algorithm itself should be kept secret.

      Historically, people did that: they created a "secure" algorithm and kept it secret. But often their algorithm wasn't as secure as they thought, and their data was compromised.

      In part, this is because security experts never saw their algorithm. The experts could have warned them.

      This approach is now derisively known as security through obscurity

      The modern thinking is to have strong, public algorithms, designed by experts, where the "private" stuff is either unnecessary (as with Bcrypt) or hidden by design, as with, say, your private key in public-key encryption. (The public key algorithm is in the clear, but to compromise the security, you need to know the private key, and you don't.

   Are either of these guesses correct?

8. none right now, walkthrough in class will help

   Let's do it!