• What exactly is stored in a database when we use bcrypt to hash passwords?

    See Bcrypt

    A 60-character string consisting of 29 characters of prefix and 31 characters of encrypted password.

    The prefix looks like '$2b$12$IkhVgnCtC/HGtKLDA3QMEO'

    where the parts are delimited by dollar signs

    2b means that it's encrypted using Bcrypt

    12 is the work factor

    The rest of the prefix is 22 characters of salt

    The 31 characters at the end is the encrypted value.

  • Is the primary purpose of a salt to defend against attacks that use precomputed tables?

    Yes. That and duplicate passwords.

  • still a bit confused about salt

    Because the salt is random, it means we can't precompute the encrypted values of common passwords like password and secret and 123456.

    Even if one person uses the same password on multiple sites, the salt means they will be encrypted differently

    If two people use the same password on a single site, the salt means they will be encrypted differently

  • Could you please explain in a little more detail how hashpw() works? It takes encoded password and encoded salt value for account creation but it takes encoded password and encoded hash value for login or checking. I am wondering how it produces a 60 character long hashed value either way although the second argument is different.

    It just extracts the 22 characters of salt from the 60 character string and ignores the stuff it doesn't need. The rest of the hashing algorithm is the same. 

    
    def hashpw(plain, prior):
        prefix = prior[0:29]
        [_, alg, work, salt ] = prefix.split('$')
        if alg != '2b':
            return 'not bcrypt'
        val = blowfish(plain+salt)
        for i in 2**work:
             val = blowfish(val+plain+salt)                
        return val
  • How does the hashing algorithm bcrypt work and salt generation?

    Salt generation is just creating a random string. The hashing algorithm is iteration of a fast secure hashing algorithm. See algorithm at Wikipedia.

  • Can we review the inserting into the database example?

    Sure. The basic idea is to optimistically insert and deal with an error if it occurs. So 

    
try: 
    INSERT INTO users(uid, name) values(null, 'fred');
except:
    you can't
    versus 
    
SELECT uid FROM users WHERE name = 'fred';
// if found
   you can't    
else
    INSERT INTO users(uid, name) values(null, 'fred');
    The reason is concurrency. We *will* talk about this more at a later lecture, but I have found that teaching the second way and then trying to convince students the first way is better is a not successful.
  • I'm a bit confused about the Weasley twins example. If they are making the account at the same time, why does it matter that it gets confused about who can insert because in the end only one of them will be able to have the username regardless?

    It matters because they'll both be logged in as the same UID, and so they'll be storing info into the same account.

  • Can you show the different formatting of how entering a password appears on a website? Eg. In the terminal when we enter our passwords they don't appear (even though they're being typed in) for security, in other websites I've seen each letter appear before they get turned into a symbol for security purposes

    That's a feature of the OS (operating system) and/or the browser. Pretty much outside our control.

  • How is two factor authentication coded into web applications?

    Great question! I honestly don't know, but let's speculate:

    1. get the username in /step1, which
    2. looks up the phone number or fob number and
    3. sends them a text with a code
    4. they submit the code to /step2, which
    5. sends them a password form
    6. they submit the form to /step3, which
    7. logs them in