Penso che il tuo approccio generale sia fondamentalmente errato. Mentre riesco a capire appieno dove ti stai formando, il tuo approccio generale è fuorviante.
Uno dei maggiori contributori allo scarso livello di sicurezza in molte applicazioni è dovuto al fatto di lasciare la sicurezza in una fase successiva piuttosto che costruirla all'inizio. Troppo spesso l'approccio è "lascia che l'app funzioni e ci occuperemo della sicurezza una volta che avremo le funzionalità di base funzionanti.
Il problema con questo approccio è che far funzionare le funzionalità di base spesso stabilisce restrizioni e guida la progettazione in modo tale da limitare le opzioni quando si tratta di sicurezza.
Questo è completamente comprensibile. Quando ti siedi a destra la nuova app killer, vuoi concentrarti sulle parti più interessanti - la funzionalità chiave che vuoi vedere e vuoi vedere progressi reali. Spesso ci sono manager e decision maker che aumentano la pressione per produrre qualcosa da vedere. Tutta questa roba di sicurezza è solo un'impalcatura che si frappone - una sorta di male necessario.
Purtroppo, troppo spesso, questo si traduce in una mancanza di enfasi sulla sicurezza. O il design rende l'aggiunta di sicurezza sufficiente, troppo dura o altre pressioni, come le scadenze di consegna, gli angoli medi vengono tagliati.
Inizia con il modello di sicurezza. Accertalo e poi inizia con la funzionalità dell'app. Risulterà in un design migliore e qualcosa che è più facile da mantenere. In questo caso specifico
- Sì, elimina definitivamente l'approccio ai parametri GET.
- Dimentica la codifica base64. Non ti sta davvero comprando nulla ed è probabile che crei un falso senso di sicurezza.
- Guarda come minimizzare la necessità di inviare la password o anche il nome utente. Prendi in considerazione l'utilizzo di una sorta di token di autenticazione.
- Assicurati che i tuoi token siano crittografati.
Ci sono molti vantaggi nell'usare un token di autenticazione piuttosto che solo nome utente e password. È possibile crittografare informazioni aggiuntive nel token, ad esempio la data di scadenza. Ho persino visto token che includono dettagli del client, come la versione del browser e le informazioni del sistema operativo, che possono essere utilizzate come un tipo di impronta digitale.
Il vantaggio principale dell'uso di un token è che il tuo unico passaggio di nomi utente e password è un numero minimo assoluto di volte. Meno hai bisogno di inviare queste informazioni, meglio è. Tuttavia, per usare i token in modo efficace e sicuro, devono essere progettati nella tua applicazione e non aggiunti successivamente.
L'altro vantaggio nel creare questo nella tua app dall'inizio è che puoi testare più facilmente i vari approcci e librerie diversi là fuori. Esistono numerose soluzioni di autenticazione e autorizzazione basate su token diverse e devi identificare quale sia la soluzione migliore per la tua architettura, lingua e piattaforma. Prendi questo giusto all'inizio e il resto andrà a posto molto più facilmente rispetto al tentativo di adattarlo retroattivamente a un codice esistente.