Das Konzept klingt für mich jetzt nicht so gut. Halt wie selbst ausgedacht, was bei Kryptografie eher schlecht ist.
Der Auffälligste Schwachpunkt ist die MitM-Attacke, also wenn der Bneutzer in einem offenen WLAN ist, dann kann jeder das gehashte Passwort mitlesen und das dann wieder an deine API schicken.
Einfachste Lösung: Zur Authentifizierung schickt der Server einen (kryptografischen!!!) Zufallswert (Nonce), eine User-ID und nen Zeitstempel in UTC. Der Client hasht nun das Ergebnis von "Zeitstempel + Nonce + UserID + Passworthash" und schickt es zur Authentifizierung zurück. Der Server kann dieselbe Operation durchführen und den Request authentifizieren.
Für die bessere Lösung brauchst du zunächst "API Keys" (kryptografischer Zufall, 256bit oder so). Also der Benutzer loggt sich online ein, und kann dort API-Keys generieren (und auch löschen). Ein API-Key besteht aus einer (z.B. fortlaufenden ID) und dem 256bit Schlüssel. Er generiert einen Key und Copy-Pasted diesen in deine Anwendung. (Dass der Key hier übers Netzwerk geht ist nicht ganz so schön)
Für einen Request kann der Client nun den Request zusammenbauen, inkl. Timestamp und API-Key ID und alles in einen String tun.
Jetzt kannst du die Daten mit dem API-Key verketten und Hashen. Der Server kann das gleiche tun, und weiß damit, dass der Request von diesem API Key kam. Dann noch prüfen, dass der API-Key tatsächlich zu dem Konto gehört und es sollte passen. Den letzten Timestamp speichern und nur Anfragen annehmen, die einen höheren Timestamp besitzen.
Schau dir auch mal diesen Post an:
www.thebuzzmedia.com...auth-authentication/
Geht alles sehr in die Richtung von OAuth ...