How does Web Authentication work? Series 2 of 4

Series Sections:

1. Section 1 - The Client and The Data Flow
2. Section 2 - Passwords and The Client-Server Relationship
3. Section 3 - Securing Server and Database and Sessions and Cookies
4. Section 4 - CSRF Attacks and OpenID Connect

Part 2: Passwords and The Client Server Relationship

Passwords

Houston we have a problem! The password is stored in plain text in our Database. This is bad and we should never store passwords in plain text. Before we discuss how we can encrypt the password you should read our blog post on creating a “safe” password.

Password Security Considerations

• Not found in a dictionary (this prevents a brute force attack)
• Add type=”password” to input field (keep someone else’s eyes from reading your password)
• Validate form data properly
  • Have a minimum character requirement
  • Make sure the password has complexity (numbers, letters, and symbols)
• Check against common passwords (You don’t want to let a user store “password” as the password
• Limit the number of password attempts the user is allowed to try (This prevents a brute force attack)
• Make sure a user has to re-authenticate before changing a password
  • Imagine you walk away from your computer and someone jumps on it and tries to change your password. If you make sure the person has to re-authenticate it protects you from this type of hack
• Safe error handling (Don’t give hackers info they could use against your site)

Hashing

OK. Back to our application.

Remember I said storing a password as plain text in the Database is bad. So let’s fix that by “hashing” our password. All this means is if your password is “Hello@u” you could run “Hello@u” through a hash algorithm tell it you want the hash length to be 61 and that algorithm would convert that string into a 61 character “hash”. See the example below:

Note: To hash a string of characters I need to provide the Hash Function 2 values:

1. The string of characters I want to hash
2. And the number of encrypted characters I want to the Hash function to generate. In the above example, we want a hash to be 61 characters in length.

Key Concepts when Hashing

• If you change the password from “Hello@u” to the same word plus a “!” tagged on to the end to form “Hello@u!” Hash Function will generate a new hashed string.
• If you provide the Hash Function with the same string and the same length of hash, it will generate the same hash.
• Is hashing encryption? No hashing is NOT encryption
• Hashing is a “one-way” process
  • This means it is very easy to go from a string of characters to a hashed string of characters but to go from the hashed string of characters back to the original string is VERY HARD and would take an enormous amount of computational power to get that original string
• Don’t hash truncated passwords. Some companies do this in production and all it does is introduce more risk and vulnerability when using password hashing

Watch out for “hash collisions”

If you take an entire book and use the hash function to generate a 61 character hash there is a chance (small chance) that you could get the same 61 character hash to form a 10 character password. To avoid this, we use something called salts and or increase the length of your hash.

What are Rainbow Tables?

“A rainbow table is a database that is used to gain authentication by cracking the password hash. It is a precomputed dictionary of plain text passwords and their corresponding hash values that can be used to find out what plain text password produces a particular hash. Since more than one text can produce the same hash, it’s not important to know what the original password was, as long as it produces the same hash.” (source)

• There are databases full of passwords with their hashed values. To prevent a rainbow table attack you need to check the user’s hash against the rainbow table hash. If the hash is found in the rainbow table, you generate another hash. You could also prevent rainbow tables from being effective by increasing the length of your hash.

Finally, let’s see what our hashed password looks like in our Database

- Not very exciting but you’ll see that we no longer are storing our passwords in plain text and we have substituted it with our 61 characters hashed and salted password. This is a major step forward in improved security!

The Client-Server Relationship

Now let’s talk about the connection between the client and the server

• We are using the Internet to make this connection
• But how exactly are we using the Internet to make this connection?
• As we send our digital mail from the client to the server how are we keeping it secure?
• Keeping our digital mail safe involves something called SSL.

SSL (Secure Sockets Layer)

Essentially SSL means that when you visit a website an encrypted link is created between the web server and your browser.

To explain this concept imagine I give $100 to my buddy Paul to pay my enemy, Peter.

1. Paul takes the money and runs to go pay Peter
2. But Peter was hiding behind a bush
3. Peter trips Paul
4. Paul falls and drops my $100
5. Peter steals the money and runs away

Did I just pay Peter to rob Paul?

If I used SSL in this transaction my $100 would have been 100% safe.

How? The full path Paul ran to pay Peter would be 100% secure and there would be no way Peter could trip Paul. That is the beauty of SSL.

IMPORTANT TIP: Anytime you use a credit card on a website you better see that secure lock in the address bar of your browser. It means it is using SSL. It means your transaction is encrypted and secure.

HTTP vs HTTPS

The old web HTTP1 was only using HTTP (Hypertext Transfer Protocol) but the new web HTTP 2 (Difference between HTTP1 and HTTP2) will eventually be only using HTTPS (which is just HTTP + SSL)

SSL Encrypts data

The first thing that SSL does is encrypts data.

What is encrypting data?

Remember how we discussed how our VikingsFanClub app creates a letter that has a Content-Type header and it has all the values the user filled out the form with. Now before the client and server share any data they will “talk” to each other and they will agree on an encryption process. At that point, the client-side will encrypt this data.

The Client Encrypts data

The Server Decrypts data

That encrypted string of characters will get sent to the server. The server will Decrypt the data to get the Content-Type Header with the object filled with the user data from their form.

SSL also performs Identification

The second step of SSL is to perform Identification. When the client and server talk to each other they don’t know each other and they don’t trust each other. That’s where the Certificate Authority comes in handy. The Certificate Authority has already established trust with the Client and with the Server. To be safe, the client can verify the server is who they say they are by going to the Certificate Authority. And the server can make sure the Client is who they say they are by also checking with the Certificate Authority.

Now back to our VikingsFan app!

1. The user signs up by filling out our form
2. The user submits the form
3. Our VikingsFan app packages the user info inside an object and creates a “letter” and slides our user object info inside the digital envelope
   1. Remember that letter has a header with a Content-type with meta-data about the user and then it has the user information itself
   2. The difference is now we are sending the “letter” in an envelope that is secured and sealed thanks to HTTPS (HTTP + SSL)

Using just HTTP can lead to a Sniffing Attack!

Note: (without HTTPS) - The digital envelope was more like a see-through envelope where our data wasn’t secure

• If a site is only using HTTP it is vulnerable to a Sniffing Attack
• To avoid that completely just set up HTTPS

Setting up HTTPS

Setting up HTTPS will cost money because you have to purchase a certificate but if you use LetsEncrypt, it’s completely free!

Series Sections:

1. Section 1 - The Client and The Data Flow
2. Section 2 - Passwords and The Client-Server Relationship
3. Section 3 - Securing Server and Database and Sessions and Cookies
4. Section 4 - CSRF Attacks and OpenID Connect