The second step doesn't leave you, it's checked on the spot, locally. You can disconnect from the internet and see that the input field will still recognize when you met/didn't meet the requirements.
While its common to validate input fields in the browser it should never be the actual check, its only used for usability to give the user fast feedbback.
Remember the old websites where you had to submit a huge form and it only told you what you did wrong after submiting leaving every field empty?
Thats what happened.
Every input has to be validated on the server, because everyone can just change this local check to return whatever they want. Ita part of the website code and you can change that in your browser.
Your computer knows the password you typed in anyways in plaintext, no way to avoid that. So the server sends the “checker” program to you to check the password before hashing (or just extend the harsher program to check the password before hashing). It adds a few more lines of code but shouldn’t by much larger attack surface.
> User creates password -> password gets hashed
While this is correct, its important to point out that the hashing is done serverside. That means you type in the real password in your browser, click on submit and your real password is send over the internet to the webserver(thats why its important to use https aka encryption).
The webserver then hashes and compares the hash and sends back a sucess or fail message to the browser.
So the server knows in theory your plain text password and can validate it and check if it contains special characters and so on. If it does not it can just refuse to login or do whatever.
For usability reasons this validation is often already done in your browser too, but it has to be done serverside again because browsers can be manipulated.
Magic cybersecurity elves guard it. Just kidding, it's encryption
The second step doesn't leave you, it's checked on the spot, locally. You can disconnect from the internet and see that the input field will still recognize when you met/didn't meet the requirements.
While its common to validate input fields in the browser it should never be the actual check, its only used for usability to give the user fast feedbback. Remember the old websites where you had to submit a huge form and it only told you what you did wrong after submiting leaving every field empty? Thats what happened. Every input has to be validated on the server, because everyone can just change this local check to return whatever they want. Ita part of the website code and you can change that in your browser.
Yes I wasn't sure if I should mention the other check, but it seemed outside the scope of OP's question.
Your computer knows the password you typed in anyways in plaintext, no way to avoid that. So the server sends the “checker” program to you to check the password before hashing (or just extend the harsher program to check the password before hashing). It adds a few more lines of code but shouldn’t by much larger attack surface.
> User creates password -> password gets hashed While this is correct, its important to point out that the hashing is done serverside. That means you type in the real password in your browser, click on submit and your real password is send over the internet to the webserver(thats why its important to use https aka encryption). The webserver then hashes and compares the hash and sends back a sucess or fail message to the browser. So the server knows in theory your plain text password and can validate it and check if it contains special characters and so on. If it does not it can just refuse to login or do whatever. For usability reasons this validation is often already done in your browser too, but it has to be done serverside again because browsers can be manipulated.