Sto progettando un'API in PHP / MySQL che, per la sua progettazione, non memorizzerà la password di un utente nel database e quindi non genera token di autorizzazione per il client da conservare. La ragione di ciò è di impedire qualsiasi possibilità di ottenere informazioni sensibili non crittografate in caso di compromissione del database.
I dati sensibili dell'utente vengono crittografati utilizzando la propria password, in modo che la decrittografia dei dati non possa essere eseguita con qualsiasi cosa memorizzata nel database (potenzialmente compromesso). Al momento ho implementato alcune funzioni di sicurezza:
- Come precedentemente descritto, i dati sensibili vengono crittografati utilizzando AES utilizzando la password hash SHA-512 dell'utente (la password viene fornita con ogni richiesta come dati del modulo), oltre a un po 'di sale extra.
- È richiesto HTTPS e sono consentite solo le richieste POST.
- Gli account utente sono identificati dagli indirizzi e-mail (tagliati e con custodia inferiore nella memoria) e richiedono la verifica prima dell'uso.
- Le password degli utenti devono avere una lunghezza minima di 8 caratteri.
- Alla fine, sarà necessario un token API per l'utilizzo di app di terze parti tramite l'intestazione Authorization. Le app di terze parti sono limitate dal fatto che non possono creare, verificare o eliminare account.
La mia domanda è, è abbastanza? Non sono un esperto di sicurezza e l'ultima cosa che voglio fare è progettare qualcosa con una supervisione importante. La mia preoccupazione principale è che la password dell'utente sia fornita con ogni richiesta, anche se sarebbe solo tramite SSL.
Modifica
Per chiarire, gli utenti saranno in grado di cambiare le loro password purché abbiano ancora quella attuale. Viene effettuata una richiesta contenente l'indirizzo e-mail dell'utente, la password corrente e la nuova password. La richiesta è autenticata come normalmente, utilizzando l'indirizzo e-mail e la password corrente. La convalida viene eseguita sulla nuova password (applicando anche il minimo di 8 caratteri) prima di continuare.
In primo luogo, così come è fatto quando l'utente desidera recuperare le proprie informazioni sensibili, le informazioni vengono decifrate usando la loro password corrente. Nel suo stato decrittografato, le informazioni vengono quindi crittografate utilizzando la nuova password e i dati sensibili vengono sovrascritti nel database.
A questo punto, non vi è alcun record memorizzato della password precedente e non può più essere utilizzato. Una modifica della password non può essere eseguita da un amministratore o, in ogni caso, senza la password che è stata utilizzata per crittografare in precedenza le informazioni. Se la password viene persa, non è possibile eseguire nulla.