Viewers: in countries Watching now:
PHP is a popular, reliable programming language at the foundation of many smart, data-driven websites. This comprehensive course from Kevin Skoglund helps developers learn the basics of PHP (including variables, logical expressions, loops, and functions), understand how to connect PHP to a MySQL database, and gain experience developing a complete web application with site navigation, form validation, and a password-protected admin area. Kevin also covers the basic CRUD routines for updating a database, debugging techniques, and usable user interfaces. Along the way, he provides practical advice, offers examples of best practices, and demonstrates refactoring techniques to improve existing code.
In this movie, we'll learn about encrypting passwords. Hashing is the term for the process of taking a string of data and apply a mathematical function to it to produce a unique string of output. Which is known as a hash. Hashing is often used for encryption but that's not its only use. For example, it can be used to create unique identifiers or to quickly determine if a large amount of data has changed. But what we're interesting in using it for is password hashing. That is, applying an algorithm to a password, to generate an encrypted string. Knowing an encrypting hash won't give away the password and the original password can't be reverse engineered even with lots of computing power.
And the hash that it generates for each password will be unique, so that it can only be recreated by using the same password with the same hashing algorithm. In short, the only way to have a password match will be to know the original password and that's what we want. Now the most important rule about passwords is never ever, ever store passwords in the database as plain text, always encrypt them. If they're in plain text, then anyone who gains access to your database will have every user's password. And its not just hackers on the outside that you have to be concerned about.
Authorized users are a concern too, any site administrator or employee or person with database access, has the potential to know all user passwords. A data backup your ISP makes for you or hard drive that doesn't get wiped completely before being sold or discarded. Both have serious potential for leaking passwords. And these are not just theoretical examples, they've happened. It's not just your site security that you put at risk, if you don't encrypt your passwords. Many users use the same username and passwords on multiple sites. If a user uses the same password on your site as for their bank account, you don't want to be the one providing a hole in the bank security.
So please, do it for all of us other site developers, if not for yourself. Make sure that you always encrypt passwords before storing them. Now, we're not just going to be encrypting them, we're going to be using one-way encryption. It won't be possible for anyone to get the original password out of the encrypted string, including us. It works because the principle is the same inputs to the same hashing algorithm will always result in the same output. So we'll take the password, we'll encrypt it, and then we'll store the result in the database. Then when a user comes to our site and tries to log in, we'll take their attempted password, we'll pass it to the same hashing algorithm.
And then we'll see if the output matches what we have stored. If the output is the same, then we know that the input was correct. If the output's different, we'll know that the input wasn't. Now there are dozens of hashing algorithms out there. Before we pick one, we need to first consider how secure do we need our site to be? I mean, I can keep $100 in my house, just lock the doors, and feel pretty secure that no one's going to take it. But if I have $100 million, then I'd probably be out shopping for some pretty fancy security systems. In the same way, encryption level is specific to each developer. I'll provide a good standard set of best practices that will meet the needs of 99% of you.
The other 1% typically work for organizations, like financial institutions or government agencies. And if that's you, then your organization probably has published guidelines for what additional encryption or security you'll need. Now out of the dozens of hashing algorithms, all for different uses not all of them are suitable for password hashing. Here are a few popular and respected choices we have MD5, SHA-1, SHA-2, Whirlpool, Tiger, AES and Blowfish. Now MD5 used to be a good choice and lots of people used it, but it's not recommended anymore.
A security flaw has been discovered in it. The weakness is not simple to exploit, but it is enough to make it less than ideal, especially since we have other candidates. SHA-1 is a good choice. There is a theory about a possible weakness in it, but no exploit has actually been found. It's still just a theory. So, it does still remain secure enough for our purposes. But we also have SHA-2, which is a stronger version of SHA-1. It comes in two versions, SHA 256, and SHA 512, neither of which has any known weaknesses yet.
I've heard that the US government is moving to SHA-2 as a minimum level of encryption. Whirlpool, Tiger, and AES are all three other very popular choices that offer very strong security, any of them would work great. However, we're going to go with the last one, which is Blowfish. Blowfish offers a high-level of security, it's in the public domain, there's no patent, so it's free to use, which is part of why it became very popular. And it's included with PHP 5.3 and later, so we have it built in and ready to go. And then, the other attribute that makes it a great choice for password security is the fact that it's slow. Now you may be thinking, wait a minute, slow? Don't I want my code to run as fast as possible? I don't want my website to be slow. Well, here's a case where you'd do, slower is better. And that's because if someone is coming to your site. And they're running a computer program that's just trying every password under the sun, just to see if they can brute force their way in, and just guess passwords.
You want that process to be as slow as possible for them. You don't want them to be able to try thousands of passwords per minute. You wanted to slow it down so they can only try thousands of passwords per hour. Where as they might have been able before to break into your site in 48 hours time, now it can slow them down to point where it takes them 10 or 12 years for them to do it. But it's not so slow that it's going to impact users. To our users there'll just be a brief pause while it compares and then it will come back with the results. And that pause is okay, it's perfectly acceptable. But to a hacker whose trying to run thousands and thousands of attempts per hour, it'll throw a real wrench in their plans.
So, slow in this case is a good thing. Now that we know which algorithm we're going to be using, let's talk a little about algorithms in PHP. It's a little bit of a history lesson. In PHP3 we had md5, and for a long time, that's what a lot of people used. It was a great algorithm for a long time, until people started finding problems with it. SHA-1 then became very popular. That came out in 4.3, and a lot of people used that for a while. Notice that the functions are named after the algorithm. But there's so many algorithms out there, there's dozens. And we don't really want to have a function for each and every once. So instead, in PHP 5.1.2, we got a new function called hash. And you tell hash what algorithm you want to use and then the password. So, we don't have to have a function for every single one under the sun. Now hash is very fast and it supports many algorithms. You want a full list of those algorithms, there's another function called hash_algos that'll return a list of them to you. But notice that I said it's very fast.
It's suitable when we want to make a hash of something for other purposes besides passwords. When we want to do it with passwords, we're going to use crypt. Crypt is introduced in PHP 5.3 and it's slow. It only supports six algorithms, one of which is Blowfish. And even the algorithms like MD5 that it uses aren't identical to what hash uses. What I mean is, hash does an MD5 process on something once, whereas crypt might do the MD5 on it seven times. That's part of what makes it slower.
But the end result that comes back at the end, is not going to be the same. It may not generate the same hash if you use hash or if you use crypt. They have different purposes. They're using a same hash, but in different ways. Now, notice that whereas in hash, we pass in the algorithm we want to use, in crypt, we don't provide that. There's not a space for that. Instead there's this thing called salt. We'll talk about that in the next movie. We'll talk about what salt is, and in that salt, we're going to also tell it what algorithm crypt should be using.
Find answers to the most frequently asked questions about PHP with MySQL Essential Training .
Here are the FAQs that matched your search "" :
Sorry, there are no matches for your search "" —to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.