Steve Smith talks about the entire process of logging into any web-site and how complicated it can truly be to code for.
Episode #3-37 released on June 8, 2013
Everyone knows how to log into a web-site. This is not what today's topic is all about. Today, I explain how the web-site reacts to you logging into that particular web-site, how it achieves it's functions, and why certain things are as they are.
First, usernames. There is a particular reason why a username needs to be unique. During the registration process we count the number of rows that have the same username as the one you desire. We define in our code that any value above 0 means that, that username already exists, hence you may not have it. However, if the number of rows is equal to 0, then you may have the username you desire. The username becomes something you have. This will be important soon.
The password, something not to be trifled with is required on all web-sites with a member area. Some sites may require a minimum length, some require you use lower and upper case letters, some enforce a minimum set of numbers, and some allow special characters. Sometimes, web-sites also enforce a maximum length of the password. While on the surface this may look like a great idea. This makes it easier to guess the password. This will also be important soon.
The combination of the username and password in order to search the database for a match is an important function to understand, and dissect. Looking up a username and password in a database is no different than looking up an article, episodes, or email message. What changes is the way we are suppose to treat the information. We have for the longest time stored passwords in clear text, which is an extremely bad idea to begin with. Then, we started to hash our passwords in our database, however, anyone can make a rainbow table. Then we started using static salts, which is also subject to rainbow table creation, before migrating to unique and random salts for all users. What is important to understand, is that the hash, and the salt are extremely important to the protection of a password, and how we store this information, as well.
A hashing algorithm is a unidirectional encryption method that cannot be reversed. It, however, always produces the same result. This is where a rainbow table comes into play. In order to create a rainbow table, we can take the password rules from the web-site we obtained the password lists from, and actually run a hashing algorithm that creates a list for all passwords possibilities using either a dictionary attack, or a straight counter style rolling of each character by one position until every possibility is obtained. The stronger the hashing algorithm, the longer it can take to do either attack, but with technology becoming faster and faster, and the possibility of sharing processes with many machines, throwing a wrench into the project is required to prevent the decoding of the entire database in a timely manner.
Using a unique salt with a strong hashing algorithm makes it harder for password cracking, but it is not impossible. Given enough cycles and time, a computer would eventually solve the result, and produce the salt with the password. This is why each user should have their own salt.
The way the salt is stored, as well as which hash is chosen is one the most important tasks of database management for the logging in process. Even though you can store each user's salt in the database with the username and password result, it is rarely a good idea to put them together in the same table. If ever that particular table, or the user table was to be obtained, then as long as they remained separated, there would be almost no issue. If the password results and salts are lost, then all users would still have to change their password.
Some of the most currently used hashing algorithms are MD5, SHA1, SHA2, SHA-256, and I personally use SHA-512.
Now, knowing all this, we must account for a theoretical login attempt, assuming the right username, wrong password. And, I make the presumption that the salt is in a different table. So, presuming the username exists in the database, we take the inputted password, combine with the salt stored in the other table, and compare the result of the hash with the hashed password result. If both match, success, in this case, wrong password.
In the case that the username doesn't exist, the code should be able to determine that the total of rows counted is 0, therefore user does not exist, however, to protect the other users, we must always present that the password and username combination is invalid, without ever explaining which of the two are wrong or non-existent.
Now, the reason why the username must be unique, is because, it is always possible for two users to have the same password. If the number of rows is greater than 1, than logging in should be just as impossible as if the number of rows matching was 0. Because, two users can have the same password, it is also important to have unique salts, in order to slow down the password cracking process. If two users had the same salt, username and password, there would be no way to differentiate between the two users, hence why once you register a username on a web-site, you own it, it essentially becomes something you have.
This is just a peak into some of the more complex relationships between the login attempt, and validation of account ownership.
Next week, I'll be explaining how to prevent the illicit scanning of your credit card's or debit card's NFC chips.
Remember to like this episode if you were interested in today's topic, share if you think someone else could benefit from the topic, and subscribe if you want to learn more. For the show notes of this episode and others, for more information on other ways to subscribe to our show, to subscribe to our weekly newsletter, and how to participate by submitting your questions, comments, suggestions, and stories, head over to TQAWeekly.com.
Host : Steve Smith | Music : Jonny Lee Hart | Editor : Steve Smith | Producer : Zed Axis Productions