So in this video, let's try to look into what is encoding encryption and hashing mechanisms and how
they can be useful to our password management in any application.
So the very first, a basic approach that any application follow is encoding.
So encoding is a process or mechanism, converting data from one form to another form.
So there is nothing related to cryptography here, like they don't encrypt converting to some form where
others can't understand it, just that they follow an algorithm like and we have a data one, two,
three, four, five.
So instead of sending plaintext out, which is a very simple way of understanding for users to understand
who are intercepting requests, I may follow a process or algorithm that I will encoded to by releasing
it.
Like instead of sending one, two, three, four, five, I will send to my back in five, four, three,
two, one and in the back and I'll have a logic or algorithm to reverse it again to see what is somewhat
general.
So this is one of the basic way of protecting your password or any information where you don't want
anyone to read or understand without any effort.
But encoding lacks all properties like it lacks confidentiality, integrity and authenticity.
The reason is anyone can decode you're encoding request data that you and I may send some data password,
but decoding it is very easy if someone knows that this is the encoding approach that I'm following.
So encoding is a process where we can get data from one form to another form.
That doesn't mean people can't understand what is my general text or plaintext that I initially sent
so that there are good mechanisms for decoding and converting into your general text.
So that's why encoding should not be used for securing data or any passwords that you don't want to
expose for public.
But we do use this encoding.
So encoding we use mostly like converting data from one form to another form, like for compressing
my data.
Like I want to send a data to the backend, but instead of sending it original form, like an image
or audio, I can proceed like into a binary format, which means I encode into a binary format and I
send to back and and my backend will have a decoding mechanism to derive.
That would, for most of the encoding that we have is base64 encoding Unicode ASCII and which usually
Web application use for their Eurail parameters that they expose in the browser or sending any header
information in history tips.
So for all such requests or all such scenarios, we use encoding.
But as our discussion encoding clearly is not eligible to maintain our passwords, it clearly can't
protect our passwords from hackers or some unwanted people who want to try to access the passwords.
So then let's look at the and I would say encryption is the next advanced question of encoding, because
even in encryption, the reverse is possible.
Like if I encrypted text, like one, two, three, four has been encrypted into some random encryption
text while encrypting it, I use a key.
So I may use any algorithm for that algorithm.
I passing secret key, which my encryption algorithm uses to encrypt and who want to decrypt our versa
to what they should know.
The key that I used initially.
So without the key, it is impossible almost to decrypt my encrypted value to the ordinary text.
That means this is far better than encoding because encoding there is no secret.
So if everyone knows, like what is the algorithm that I'm using, like base64 or ASCII Unicode, they
can easily decode it.
But here, even though they know my algorithm, they can't be corrupted because it is associated with
their secret key.
But again, in encryption, we have two different categories.
One is symmetric and other one is asymmetric.
It's symmetric encryption algorithm.
A single secret key will be maintained by both parties, like whoever is encrypting at one site and
whoever is taking that encryption data and try to decrypt it, they follow the same secret.
So this you can use if you are sure that no one can misuse urogenital key in such scenarios, we can
go to symmetric encryption.
Suppose things like there are two backend applications are microsurgeons.
They're trying to communicate with each other and one micro services is trying to encrypted and sent
to the microcircuits to and microcircuits through with trying to decrypt it using the same key user
by microcircuits do.
In this scenario, if you own both Microsoft, which one and Microsoft Vista, then you are free to
use the same secret because anyway's both Microsoft Services is maintained by the same organization
of same web application and there is no harm of using the same secret.
And as long as the key protector who should be good with this encryption mechanism.
But again, here there is a problem.
Whatever security measures that you can use, you have to store this key in some way, either in your
environmental variables or a system variables or in some your external properties.
There are several things can easily understand it.
So if someone knows the key incarcerator means they can easily decrypt our passwords.
That's why encryption symmetric approach also is not apt for our password management.
Now let's look into the asymmetric encryption algorithm.
So in asymmetric, what will happen is there'll be two keys.
One is less public and the other one is less private.
The person of the system which has publicly is responsible to use that and encrypted and publicly is
accessible to anyone.
Like, whenever I access any Web application or any website, you might be seeing History Tips, which
is a SSL, are peerless certificates.
So what are we see that green color in our browsers that indicate a public certificate installed on
my browser for that Web site.
But when I have my public certificate or public key on my browser, I can enter my username and credentials.
They will be encrypted and be sent to the backend server which maintains that website.
So my backend application will have a private key and only who has private key can decrypt the data.
It is generally encrypted by a public so someone can copy or take my public.
There is no harm because using public key you can only always encrypted data but can't decrypted in
asymmetric encryption algorithms.
So public and private key is responsible for encryption.
But again, this has the same problem as symmetric encryption is who knows the private key that can
easily be crypto data or password and they can hack your application.
So again, encryption also is not suitable for password management.
And the scenarios where you see encryption in our day to day basis is symmetric encryption.
You can see whenever you try to store some secure data in your database, like credit card information
or my sensitive information like data on my phone number, but not the password, because password is
very sensitive in nature.
And with that password, anyone at.
Your application, and similarly in asymmetric encryption, it is used in tailor security's VPN stretch,
where two different parties maintain different keys, which is public and private.
The reason that why we are not maintaining the same keys.
There are two different parties and I'm of the application and I maintain parity.
I'm not sure whether the other third party will maintain the same secrecy towards me.
That's why I will never share my private key to anyone.
Instead, I will give a public key to them using which they can encrypt.
And whoever has the private key associated to the public, you only can decrypt that information.
But again, as we discuss, encryption is not suitable for password management, then what is suitable?
Let's look at the hasheem.
Like we discussed, even in the encoding and encryption, the reverse is possible.
Like someone knows the key are encoding algorithm that can easily reverse to my genetic text that I
have stored in the database are sent over.
But caching is a powerful algorithm and a mechanism and a process where it hashes whatever input that
you give, it will hashes using a hashing function and it is not reversible.
That means once you generated a hash out of a string and you have a hash inside your database and stored
it, no one can reverse it and see the original text.
That's the beauty of hash.
But you can see how that a switch can be compared.
Think of a scenario very first time the user entered his password by whilst at that time I generate
a hash password and vegetables.
No, even Tomizawa Observer can see that encrypted hashing text inside the database.
It's useless for him because he can't reverse it to see the original text next time the user is trying
to login into the Web application using the password associated to him.
So now he entered the same password.
One, two, three, four, five.
So now my application will try to generate a hash out of it and it will try to compare the hash that
was stored in their database and the hash that we have in our hand based upon what user entering the
browser.
If both hashes matches, then that means the password is simple.
There is a very good chance is the hash of the board what we stored in the database and what we received
from the user.
But the same text can look different.
But their hash value, which used to be the hashing mechanism, will be same that way.
When they try to compare the hash of the same text, they will always return the both hash or matches,
which indicates that these are from the same text again.
So that means hash and can be leveraged for our password management.
And one of the other approaches that you can always see for caching in the Web is in most of the website.
When you try to download the files or software terms, they'll give you a checksum associated to that
file.
That means this is a hash based upon the content that we have on the file and who are downloaded and
make sure after download it in the process of downloading from the network, No.
One, change the data and it we can always rely on the hashing function to generate the hash and compare
with the what it has that I provided on the website.
So that will tell you, OK, there is no change of data and what additional and what I learned or saying.
So now it's very clear encoding and encryption to they have scenarios where we can leverage them, but
they are clearly losers in terms of password management.
The clear winner here during password management is harshing.
The reason is there is no way for users to reverse it and see the original text.
I hope you are understanding this.
Let's try to understand in the next video with the hashing out big security works.
Thank you by.