In this video, let's try to look deep into your password order that we have used previously, if you
can recall, previously reconfigurable, been of a password encoded that should implement and use no
password encoded.
So this is an indication to the spring framework that all our passwords validations should follow the
implementation provided in no password.
And for the reason that it is mentioned as deprecatory spring security, don't want us to use this for
any protection or any applications where we have a lot of sense to data inside that it will show as
deprecated.
First, let's try to look into it.
What is password encoder?
We have look into it in the previous video, but if you can see the code inside the password encoder,
it is from this package, which is like crypto package and it is an interface which has three methods.
The very first measure that framework will call is matches.
It will try to match with the password that we have received and whatever encoded password we already
have.
So in the process of matching spring security, also called encode implementation to convert this RA
password into encoded password so that it can compare the newly generated encoded password with the
already stored encoded password for similarities.
And you can see this method will never decode our what we stored inside the database.
The stored password itself is never decoded, which isn't truly an advantage in terms of hashing algorithms.
And at the same time we have an upgrade encoding method and you can see inside an interface we have
an implementation concrete method.
That's because from one point eight inside interface, we can have default methods with a different
implementation inside.
So by default, the implementation is to return false.
And now let's try to go and look into our know our password and we can see the normal password encoder
implements password encoder.
The encode method is doing nothing, just converting our car sequence of RAS password that we received
into a stream.
There is no end quote.
Encryption on hashing is happening, which means by default, spring security will not do anything to
your password and it will always return whatever will is as a string.
That's why this interface is not recommended for any applications where the main sense to data and even
you can see the matches also, it will simply try to compare whatever we receive, food and water we
stored in the database.
And in this scenario, that means whenever we try to create user or user update password using our user
details manager implementation, it will call this goal.
And while storing into the database also, it won't do encoding encryption or hashing it, it always
served it as a plaintext.
That's where matches also will end up comparing it as a plain string.
And we are using the equals method here.
So that's a no our password encoder.
Due to this reason we saved password inside our database in plain text.
One, two, three, four, five.
And even when users enter the same password, one, two, three, four, five, it will compare both
of them.
And since those are matching in terms of plaintext competition, it is allowing the authentication.
So there is no security enforcement happening here.
Everything all the passwords are maintained in the plain text, which is not a valid recommendation.
So that's why let's try to go and use decrypt password encoded in the coming videos so that our application
maintains the password in terms of hashes but not in the plaintext.
Thank you.
And get you in the next review, but.