Let us breakdown our previous replies for you: once our server gets the "plaintext" password over HTTPS [...] so your password is never actually exposed to us.
After you get the plaintext password, you do something with it and it is never exposed to you. Sure.
That's one of the most contradictory conversation i had in a while.
You admit that your server receives the password in plain text, but refuse to accept that you have access to it.
Our custom build framework has built in CSRF AND SQL injection filters in place [...]
Do you even know how CSRF works ?
Thanks for confirming that you actually have no clue.
BOB123 Majority websites on the internet don't need to encrypt passwords beforehand using javascript because it will store your password as the hash LOL and if the server SQL gets dumped the encrypted hash is your password LOOL.
I've checked out sendbit.io and their security measures are just fine as far as i know about CSRF they've got good measures in places
<input class="form-control form-control-lg" type="text" hidden value="7569c690dd4722ab1f58dbf32a09bd8e02a1b948e4a720e3bb1ba059b6347ce7" name="csrf_token">
So I've got a question for you BOB123 if you had a website would you generate hashed passwords beforehand so incase you DB gets leaked all passwords are actually useable or would you encrypt them after the request is made so if the DB gets leaked all passwords are hashed properly rather than just JAVASCRIPT hashing.
How old are you? I must say you're good with your inspect elements but that does not make you a security audit expert there are kids on youtube who make more sense than you.
Have you got any websites you've built because I would love to take a look at
