Alcuni sistemi di terze parti offrono una gestione delle sessioni esplicitamente per questo scopo.
Ad esempio, Google potrebbe richiedere l'autenticazione a due fattori se gli utenti lo configurano e, per le app (come la tua?) che non supportano TFA, hanno password specifiche dell'app o una sorta di sessione permanente.
Potrebbero esserci più di un tipo, ad esempio l'accesso a Stack Exchange ha richiesto a SE una piccola quantità di dati da Google, ma potrebbero ottenere molto di più se l'utente lo ha consentito. D'altra parte ci possono essere altre API o possibilità di sessioni a lungo termine che richiedono semplicemente all'utente di reinserire la propria password quando succede qualcosa. (che è raro)
Ciascun servizio di terze parti (Google, Facebook, ecc.) avrà le sue diverse opzioni qui.
Se continui a determinare che in modo permanente è necessario memorizzare una password , allora sì, la crittografia a due vie è la strada da percorrere .
AES-128 (o superiore) è l'algoritmo di crittografia simmetrica raccomandato da utilizzare. Finché la chiave viene generata utilizzando un generatore di numeri casuali crittograficamente sicuro (pseudo-), allora non sarà pratico per l'attaccante alla forza bruta. Quindi, l'attaccante cercherà invece un modo per rubare la chiave.
Supponendo che i dati siano in un server SQL, la semplice memorizzazione della chiave al di fuori del database fornirà almeno una copertura contro gli attacchi SQLi. Non codificare la chiave nel codice sorgente dell'applicazione, ma piuttosto, posiziona la chiave in un file separato , in modo che il codice sorgente possa essere copiato in un ambiente di test, se necessario, e un separato (non -secret) può essere utilizzato per tali ambienti.
Tuttavia, questo ti protegge solo da perdite SQLi e codice sorgente. Altri tipi di intrusioni potrebbero consentire all'utente malintenzionato di leggere i file sul server.
Assicurati che la tua applicazione (e il sistema di autenticazione su cui si basa) sia eseguito in il proprio account utente sul sistema operativo e sul filesystem. Il file chiave non dovrebbe essere leggibile da altri utenti (tu senza sudo ) o applicazioni (ad esempio sendmail ) sul sistema in questo modo. (Ad esempio, imposta le autorizzazioni keyfile su 600 o 400 per sistemi UNIX-like)
Nel complesso, dovresti proteggere la tua applicazione e tutti i servizi in questo ambiente da tutti i tipi di attacchi. Questa è la prima linea di difesa. Qualsiasi altro suggerimento qui è una misura di sicurezza per aiuto per ridurre l'impatto di un hack di successo.
È sempre possibile che ci sia un errore e un'intrusione potrebbe raggiungere l'account utente sensibile. (quello che accede al file chiave)
Potrebbe essere possibile separare gli account utente all'interno della tua unica applicazione, ma questo diventa complicato.
La protezione finale è usa la password e la sessione dell'utente finale per ottenere la chiave di decrittografia . Questa è la soluzione più sicura dopo che hai trattato nei punti precedenti, ma è complessa da implementare e non è compatibile con una funzionalità di reimpostazione della password autonoma.