It's a simple algorithm I made (afaik).
P = input password
1) C = Generate some thousand characters
2) A = sha3 hash of C
3) B = C encrypted with P
4) store A/B somewhere
To login:
1) pull B out and decrypt with input password
2) hash it and compare to A
3) if equal then it is sec.
The wonderful thing about this is that you first have to crack the large hash that is the several thousand characters inorder to even begin bruteforcing the password. It's simple and effective.
There are a few things majorly wrong with this.
1. This method will take a lot longer than simply taking say, the sha256 hash on the client side (which is secure enough for at least 10^50 millenia) and transmitting it, checking the hash against the hash in the database, and then going from there.
2. If someone is monitoring the packets being sent by the client, then your method just gave away their password. You're also doing it wrong by this logic of being "more secure." If you want it to be as secure as you want it to be, he needs to just use loving SSL so transmissions can't be intercepted.
3. Using point #1 you could also perform a DoS with much less effort by overloading the puny server with login requests.
4. Your method is no more secure than a regular hash as it completely relies on the input password alone and nothing else. You're overcomplicating things for no reason.
What's worse is you've suggested this somewhere else before and I've told you these exact same points.
And adding onto point one, if you used sha512 it would be enough to last for 10^37 universe lifetimes.
