Zum Inhalt springen
L

Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).

Storing Passwords

0612 TV w/ NERDfirst16:29 792 Aufrufe veröffentlicht Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

Transkriptautomatisch erstellt · 98 Zeilen
Herunterladen
  1. [Music] hello and welcome back to another random Wednesday episode here on 0 6 1 2 TV today we're talking about storing
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. passwords people sometimes mistakenly call this encryption but this isn't actually encryption you see encryption refers to taking something right which
  22. 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
  23. 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
  24. 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
  25. 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
  26. the key difference between encryption and hashing is that you cannot reverse this process hashing is a destructive process you can
  27. 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
  28. use to protect our passwords in fact coming back to the context of security the hashing techniques used are called cryptography hashes essentially
  29. cryptographic hashing methods take more precautions to ensure that your information is being hashed in a way that is more secure some examples of
  30. this could include having small changes in the inputs creating very large changes in the output hash it can also involve basically avoiding collisions
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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
  37. 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
  38. 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
  39. 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
  40. 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
  41. 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
  42. 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
  43. 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
  44. 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
  45. 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
  46. 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
  47. 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
  48. 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
  49. 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
  50. 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
  51. 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
  52. passwords will that's of course not to say that cryptography hashing is then completely useless this is still infinitely better than storing clean
  53. text passwords because it involves a lot more effort on the part of the attacker however as we can see here some flaws
  54. still exist your attacker could take this a step further by creating a very large table of say every possible hash out of every
  55. possible password of course some problems with this is that this table gets extremely latched we're talking gigabytes or even terabytes in size
  56. 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
  57. 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
  58. 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
  59. 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
  60. 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
  61. 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
  62. 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
  63. 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
  64. 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
  65. 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
  66. 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
  67. 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
  68. 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
  69. 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
  70. 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
  71. 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
  72. 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
  73. 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
  74. 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
  75. 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
  76. 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
  77. 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
  78. 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
  79. 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
  80. 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
  81. 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
  82. 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
  83. 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
  84. 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
  85. 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
  86. 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
  87. 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
  88. 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
  89. 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
  90. 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
  91. 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
  92. 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
  93. 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
  94. 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
  95. 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
  96. 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
  97. 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
  98. you for your support

Zum Nachlesen

Salt (Kryptologie)Salt (englisch für Salz) bezeichnet in der Kryptographie eine zufällig gewählte Zeichenfolge, die an einen gegebenen Klartext vor dessen weiterer Verarbeitung ( … Rainbow TableJede dieser Ketten startet mit einem initialen Kennwort, welches durch eine Hashfunktion geleitet wird. Der resultierende Hash wird wiederum durch eine … SchlüsselableitungDie gebräuchlichste Verwendung von Schlüsselableitungsfunktionen ist der Passwort-Hash bei der Passwortverifizierung. Schlüsselableitungsfunktionen weisen … Challenge-Response-AuthentifizierungAlice ergänzt diese Zahl N um ihr Passwort, wendet eine kryptologische Hashfunktion oder Verschlüsselung auf diese Kombination an und sendet das Ergebnis an Bob …