Storing Passwords
0612 TV w/ NERDfirst
https://www.youtube.com/watch?v=bfCb0pgIesQ

Transkript (automatisch erstellt)

0:00 [Music] hello and welcome back to another random Wednesday episode here on 0 6 1 2 TV today we're talking about storing
0:11 passwords and we're gonna try and approach this as quickly and pictorially as possible we'll be looking at some fairly common technical terms like
0:20 cryptography hashing we'll be discussing some of the pros and cons to the techniques used including common exploits like rainbow tables and you'll
0:29 hear me mention terms like salty so these are some of the key things I wanted to cover in today's video so without further ado let us jump right
0:39 in first and foremost why do we bother storing passwords let's say you're running some kind of online service of course you want your users to be able to
0:49 log in and how they log in is by supplying a password that password gets sent to your server and what your server does is it will have to look at the ends
1:00 at password compare it with the version you have saved and check to see if it matches or not of course if it does match that means yeah this is who they
1:10 claimed to be right and you allow their login to go through that's why we need to stop hazards we have to do this to authenticate our users so then we can
1:20 move on to the question of how how do we store our passwords of course the easiest and the most naive way is to well just store them right store them
1:31 exactly as they up this of course will work perfectly for authentication purposes if the user gives their password you can just well check it
1:40 directly against your database if it matches all as well of course this is in a case of day to day use in this context everything is fine but what if somebody
1:51 with a slightly more malicious intent comes along if they steal your database well that's trouble with a capital T because all the passwords are just lying
2:02 there in plain view not only will they have access to basically anyone's accounts on your machine don't forget people have the tendency to reuse
2:13 passwords that same password may compromise more than whatever is just on your machine this may also affect other services in which your user has signed
2:23 up - from things like social media to email and even worse - things like banking but actually the worst thing here is the email and the reason for
2:34 that is if they can somehow figure out the email of your user and somehow figure out their other accounts they can start sending for god password emails to
2:44 that email accounts which again makes it easier for them - yeah basically gain access to things they shouldn't have access to so yeah basically this is a
2:53 can of worms long story short don't do this never ever stop passwords in plain text so what is the alternative what is a safer way of storing your users
3:05 information remember you need to do this in order to authenticate your users clearly we have to store the information but protect it in a certain way perhaps
3:16 all we can do is we can grab the password and convert it somehow so that the original form isn't there anymore this is indeed what is done with storing
3:26 passwords people sometimes mistakenly call this encryption but this isn't actually encryption you see encryption refers to taking something right which
3:38 we'll call plaintext again and by putting it through an algorithm generate what is essentially a gobble mess called ciphertext the ciphertext looks like
3:48 nothing meaningful to the naked eye but if you enter the correct key or password you are able to decrypt it back to the original plaintext this is encryption
4:00 and this is not what is done for passwords instead a different procedure called hashing takes place it is conceptually not that different we have
4:11 our clean text and we put it through a hashing algorithm to get something that is again a gobble Menace in the context of hashing we will call this well a hash
4:20 the key difference between encryption and hashing is that you cannot reverse this process hashing is a destructive process you can
4:30 only go one way from the plain tanks to get the hash but you cannot recover the original plaintext from the hash itself hashing is essentially the technique we
4:41 use to protect our passwords in fact coming back to the context of security the hashing techniques used are called cryptography hashes essentially
4:52 cryptographic hashing methods take more precautions to ensure that your information is being hashed in a way that is more secure some examples of
5:01 this could include having small changes in the inputs creating very large changes in the output hash it can also involve basically avoiding collisions
5:12 which are instances of when multiple things hash to the same value and that is why in order to store your passwords cryptographic hashing is used it is
5:22 especially favored in this context because it is impossible to recover the original password out of the hash which of course gives us an even greater level
5:32 of confidentiality so in your server instead of storing passwords you will store the hash two versions instead so how this authentication won't know when
5:43 the user comes along they provide you with their password well essentially this steps are the same you grab the users password and you hash it first
5:52 this produces a hash which you can then check against whatever you have in your database again if these two things match then your user will be allowed to log in
6:04 thanks to the nature of cryptography hashes it is no longer as much for a problem if someone comes along and steals your entire database sure they
6:14 will see all the hashed values but if they try to provide the hash as a password that's not going to work because the authentication system hashes
6:24 that password what you've entered isn't going to be taken verbatim of course what you get at the end of the day will not match what is thought in the
6:32 database but because the hash has been hashed again and therefore this isn't going to allow the attacker access to your machine and it will also not
6:41 give them any way of figuring out what the original password is they're basically quite stuck of us there are certain limitations to all this now
6:53 our hash function needs to be deterministic what this means is if you put in something it will always give you the same result this of course is
7:02 necessary for everything we've described up to this points to work correctly this could pose a problem in certain contexts for example some passwords are more
7:13 common than others password for example is a very common one what this means is if multiple people use the same password their passwords are going to all be hash
7:24 the same in the database and this could pose some problems the attacker could formulate some kind of strategy out of this for example if they wanted to
7:34 target people who had very common passwords what your attacker could do is to get a list of the most common passwords which is something you could
7:42 easily find online and put them one by one through the hash function generally the hash functions that I used are not secret and what this means is your
7:53 attacker could potentially run this process on their own computer as a result of this they would generate a list of all of common hashes which come
8:02 from common passwords assuming that they have also compromised your server what they can then do is to simply match the two with the credential stolen from the
8:13 server as well as a list of common hashes computed by the hacker they could simply go on line by line and see if there any hashes they recognize for
8:22 example we've got one right here this could clue you in to the fact that this particular user is using this particular password so this isn't greet
8:33 and this particular attack is called it lookup table attack by pre-computing hashes your attacker could look up and potentially still figure out what the
8:43 passwords will that's of course not to say that cryptography hashing is then completely useless this is still infinitely better than storing clean
8:52 text passwords because it involves a lot more effort on the part of the attacker however as we can see here some flaws
9:00 still exist your attacker could take this a step further by creating a very large table of say every possible hash out of every
9:11 possible password of course some problems with this is that this table gets extremely latched we're talking gigabytes or even terabytes in size
9:18 which is why generally attackers don't use a lookup table directly instead using a lookup table they could construct what is known as a rainbow
9:28 table a rainbow table is a rear a percentage of the contents within a lookup table but set up in such a way that instead of having to have every
9:38 possible password and hash listed out only a small number of hashes and plane tanks are being stopped however the remaining ones can be computed using the
9:48 ones that are both actually present within the rainbow table itself so not only have attacked us found their way around you know a basic use of
9:57 cryptography hashing they've even found an efficient way to represent and manipulate with that information so that is not great of us despite this it is
10:08 important to note that they haven't cracked hashing what this means is hashing is still strictly a one-way process there is no notion of deriving
10:18 plaintext passwords directly back from the hashes right we're not doing an inverse of the hash function it is not really possible at least at our current
10:27 level of knowledge so that's not what's happening a rainbow table is still a fancy incarnation of a lookup table however since this process has become
10:37 efficient it is still a valid concern going back to the root cause of this problem remember that the whole issue here is recognizable hashes whether it's
10:48 because they're all derived from a common password or whether if it's just hash values generated out of shorter passwords by brute force
10:57 either way the key issue here is that the hashes are recognizable so what we can do is we can tweak up the passwords a little bit perhaps by appending a
11:08 little bit of stuff at the back of it I first remember a property of our hash functions even a small change in the original information
11:16 is going to create a vastly different hash at the end of the day and as you can see we now end up with yeah completely different and unique looking
11:26 hashes this is in fact what is done and this little extra thing we've sprinkle on at the end of our passwords I call salt here's our salts work salts are
11:39 randomly generated strings of text for each user each user has their own unique salt and as it turns out we can just store them in clean texts on our
11:49 database again the authentication process is basically the same your user comes along they supply their password and what we do is before we perform
12:00 hashing we need to join the two things together whatever password theft answer and whatever salt belongs to the user ID the whole thing is then put through our
12:12 hashing function the results again is match to see whether both that's the right person or not and if everything matches up nicely they'll be allowed to
12:21 login so not much difference with the authentication aspects but of course the question is is it secure interestingly we can have our salt start in clean
12:33 tanks like this even if our hacker comes along and steals it Oh in order to understand this we must first understand why rainbow tables are so effective in
12:43 the first place if we have a stolen table of unsalted hashes what we can then do is we can use a single rainbow table and basically try and figure out
12:53 all the passwords since a rainbow table is pre computed this could be a fairly fast process all the hard work has already been put in during the
13:03 construction of the rainbow table its computational cost when actually put in use is negligible however things are different when we salt our passwords now
13:14 the salted hashes here represent things that are too complicated for our rainbow table even if it was a simple password it is now combined with a complex salt
13:25 to create a complex flame text to start off with and what this means is a rainbow table or lookup table probably doesn't have the correct entry to figure
13:36 out what password this is of course since our attacker has the salt they could still attempts to figure it out they can still take all the common
13:46 passwords they could you know append it to the salts and basically try and generate all the hashes based on that one particular salt but now that is a
13:55 lot of work because essentially you have to build one rainbow table for each user each one of these tables cannot be reused because every user has their own
14:07 salt and because of this every user has their own set of potential password hashes what this means is this is extremely computationally expensive for
14:18 the attacker and that ladies and gentlemen is why passwords are stored with cryptography hashing and salt using these two methods together even if your
14:28 entire database has been compromised well not a lot is going to happen your attacker will not be able to efficiently recover the original plaintext passwords
14:39 and that's why these methods are used of us more can be done to make passwords even more secure for example certain methods involve using a hash function
14:50 not once but multiple times potentially thousands of times after combining the password and the salt the two things are hashed the result is hashed again and
15:01 again and again and again the purpose of this is to make things computationally expensive for the attacker when it's just one person logging in well we've
15:12 got to do 1,000 steps here but that's it and this can be done fairly quickly however for an attacker because they are guessing at potential passwords they're
15:23 gonna have to do this entire process many times over and then it's where this step adds up this is where things become really computationally expensive for
15:33 your attacker of course at the end of the day this process will produce a hash and again that is what is thought that's
15:41 what is used for that in keeping the user so yeah essentially that's it that's all there is for this episode about storing passwords hopefully this
15:51 has been insightful and hopefully this has cleared up some misconceptions and terminologies associated with the steps involved in this process that's all the
16:00 risk for this particular episode thank you very much for watching and until next time you're watching serial 6 wants you TV with nut first on net thank you
16:09 very much for watching if you like my work and are feeling generous you can shoot me a one-time donation on PayPal or sign up for a recurring one on
16:17 patreon of course you can simply like comments and subscribe you know that you for more videos links to my channel and a related playlists are on screen thank
16:26 you for your support