Secure login based on challenge-response

Password is never being transfered via network in plaintext format.

Schema

Example of such exchange

Login: "soco" ; password: "abcd" ; sha_pass_hash: "B5D61F4C9BC30B075A8390ABA44EF9FCBD180716"

1. Client sends challenge request to server: .../ajax-armory.php?what=auth&action=challenge&login=SOCO
2. Server checks the account table and generates new record in challenges table
3. Server sends challenge string and challenge id to client: {"challenge":"la22lx14087or3twgqn531umdut0mk9n","id":"38"}
4. Client creates hash using SHA1(login:password) - getting same value as it is stored on server in sha_pass_hash. This hash is then hashed again by challenge string: SHA1(sha_pass_hash:challenge_string)
5. Client sends challenge response to server along with challenge id: .../ajax-armory.php?what=auth&action=response&challenge_id=37&response=AEEF82A4065CB74B591DD96310CC1BED44320D4A
6. Server checks by challenge id if challenge really exists, is not expired and IP matches the IP for challenge was created. Then gets sha_pass_hash from account table and makes same SHA1(sha_pass_hash:challenge)
7. If client response matches with servers, client is authenticated: {"response":"ok", characters: {}}

Password was never sent through network in plaintext or as sha_pass_hash. If someone gets this response, he can only login to catarmory as this user (if he shares same IP address). He can get the neither to the sha_pass_hash, nor account password - even while knowing challenge id, challenge random and username.

Weaknesses

This system is vulnerable only to loosing sha_pass_hash (from database). If somebody gets to usernames and encrypted passwords, he is able to spoof the login procedure. Most likely he will first try to bruteforce hashes - so protect your auth database! Beter way will be using SRP6 as Trinity does, but it requires using long integers in javascript an PHP, which support can't be guaranteed.