![]() Now, consider the requirements of the hacker who breaches our server and gains access to both our source code and our database. Now, we have a great way to protect user passwords, while still being able to validate the user when they login. Sure enough, the boolean rings True, and we have a match! If you do not have passlib already, which you likely do not since it is not part of the standard library, do a quick: pip install passlib Let's bring in the big guns with passlib. What we want instead is a way to generate unique hashes, where their source can be validated easily, but brute forcing will require a brute forcing per password, not a brute forcing for the entire database. From here, it's relatively quick work to break the entire database of encrypted passwords. ![]() ![]() This means someone can find out your salt. Consider that many reasons why someone has access to your database also mean that they have access to your source code. A good test for your encryption is to ask yourself: "If someone discovers my encryption method, is my security compromised?" In many cases, like with a cipher for example, the answer to this is "yes!" That's a problem. One of the adages for encryption is that you cannot depend on secrecy for security. This, again, can take a lot of processing, but this is by no means out of reach by today's standards. This means if someone cracks how you generated your salt, then they have now cracked all passwords by generating a hash table. The hash is always the same for the same password. This is pretty good, but there is inherent risk, still, and here's why: May you have a salt at the beginning, another for the middle of the password, and one more at the end even. Maybe it's input right in the middle, maybe at the beginning, maybe at the end. Here's an example of how salting works, building off our last example: Salting, while still used, initially started out pretty simple. What we need instead, is a way to generate unique hashes, yet find a way to validate that hash by asking merely if two hashes came from the same input, despite being very different hashes.īefore arriving there, however, people came up with an easier solution: Why not place a secret pattern of text into every entered password, that only we the server knew. These tables are big, but not too big to store on your laptop or netbook. It takes a bit longer to generate the tables. You could also create one yourself, by just generating hashes for combinations of characters. The problem here is that people created massive hash tables, notably referred to as hash-lookup tables, where you could just search for the hash, and then find the corresponding plain-text password. Initially, with validation in mind, you may think well isn't this a requirement anyway? How else can we achieve validation? You will find that the output is the same every time. The problem, however, arises with the following: Run the script two times, or five times. If you just saw that hash in a database, you'd have no idea what it meant. This was where a hash function was applied to what the user input, and that hash was what was stored as a password. One of the more primitive measures taken was simple password hashing. The problem is, with passwords, we actually need to be able to validate what a user enters in the future as the original password. So then how might we obscure passwords? Obscuring original text is easy enough, we can right a randomized algorithm that does this. Not only might someone who works for you steal user passwords, a hacker might, or even the host to your server might, if you are using a virtual private server, or shared hosting. In a perfect world, no one would invade a user's privacy, but this world is not perfect. If your database stores plain-text passwords, at the very least, you are going to see the passwords yourself, and so will anyone who has access to your server. To begin, you can probably understand why it is important to encrypt passwords to begin with. Not only is it important for security practices, it's also just pretty cool how it works! Because of this, you should know at least at a high level, how it works. Maybe you end up working in another language, or maybe passlib doesn't support the version of Python you are using in the future. While we have already incorporated the password hashing into our registration page, I wanted to take some time to go over what is actually happening.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |