La tua soluzione attuale funzionerebbe, tuttavia, puoi tenere le informazioni sul tuo server monitorando una sessione. Quando un utente invia le proprie credenziali di accesso, è possibile memorizzarle in un database (possibilmente crittografato) e quindi rilasciarle un id di sessione univoco (dovrebbe essere difficile prevedere l'id di sessione, ad esempio crypto rand + hash).
Una volta che l'utente ha ottenuto la chiave di sessione, invierà quell'ID insieme ad ogni richiesta al tuo server. Quando si verifica che questa chiave di sessione sia valida, si ottiene il nome utente / password dal database e si effettua la richiesta per conto dell'utente. Dopo un po 'di tempo, invalida questa chiave di sessione e la cancelli e le informazioni di accesso dal tuo database. Ciò aiuterebbe a difendersi dagli attacchi di tipo replay.
Se si includono le informazioni di accesso effettive e non si ha alcun tipo di età scadente, un utente malintenzionato potrebbe ottenere l'URL utilizzato per accedere al sistema ed eventualmente effettuare richieste per conto dell'utente. Naturalmente, questo dipende da come si imposta l'URL ecc.
Generalmente, questo tipo di situazione viene gestito memorizzando localmente le credenziali in una sorta di archivio sicuro (ad esempio crittografato) e emettendo una sorta di identificatore di sessione temporale.
Anche se ci possono essere alcuni vantaggi nell'utilizzo di processi a breve durata, è probabile che sia più costoso che vantaggioso. Se un attaccante è al punto in cui può leggere la memoria nei tuoi processi, il fatto che il tempo in memoria sia di breve durata non sarà di grande aiuto. Inoltre, probabilmente stai ancora memorizzando le credenziali crittografate da qualche parte sul tuo server (ad esempio i log di accesso http), insieme alla chiave di crittografia (che suppongo sia in un database). Se l'utente malintenzionato ha accesso a entrambi, le credenziali saranno compromesse. A seconda della lingua che stai usando per scrivere l'applicazione, ci potrebbe essere un modo per azzerare la memoria una volta che hai finito con le informazioni sensibili.
Se si utilizzano i timestamp nell'URL, è necessario assicurarsi che il timestamp non possa essere manomesso (HMAC, AES-GCM, ecc.). Mantenere i dati delle credenziali, crittografati o meno, rappresenta anche un problema nel controllo delle informazioni. Se si sospetta che la chiave di crittografia sia stata compromessa, è possibile eliminare facilmente i crednt dal proprio server. Se le credenziali sono in URL potenzialmente disperse su Internet nella cache del browser, ecc, non sarai in grado di mitigare la perdita.
Se memorizzi le credenziali nel database, insieme al materiale che usi per ricavare la chiave, avrai molto più controllo sui dati. Supponendo che l'applicazione del database sia protetta, è probabilmente più sicuro. Suggerirei di utilizzare chiavi diverse per ogni set di credenziali e di utilizzare un qualche tipo di KDF ( link ) per ricavare la chiave, invece di memorizzare la chiave in chiaro nel database. Puoi anche includere parte del materiale derivato dalla chiave nell'ID di sessione che hai inviato all'utente.
Naturalmente, se qualcuno ha accesso completo al tuo server, incluso il database e / o lo spazio VA dei tuoi processi CGI, le credenziali saranno comprimibili, ma questo è vero con quasi tutte le soluzioni.
Se scrivessi questa applicazione, utilizzerei gli ID di sessione per legare le richieste di un utente a un insieme di credenziali. Vorrei usare una tabella di database contenente i campi per l'id, tempo di creazione, ultimo tempo visto, nome utente, password e seme derivazione chiave (questa parte dipende da come si derivano le chiavi). L'id di sessione che vorrei rilasciare all'utente sarebbe un valore grande, difficile da indovinare (memorizzato nel campo id), combinato con una porzione del materiale necessaria per generare la chiave (questo materiale non verrebbe memorizzato sul server, quindi sono necessari sia un ID di sessione valido che il materiale memorizzato sul server per decrittografare le credenziali.
Ad esempio, un ID di sessione potrebbe essere simile a questo:
d7be62755db80ccefb7d802fde153145b6e9_bdb8f9bf599293fd65a020dba1ecd
La prima parte sarebbe la parte id e la seconda metà dei dati necessari per ricavare la chiave.
Quando viene effettuata una richiesta, viene verificata la parte id dell'id di sessione e la chiave di decrittografia generata utilizzando la parte di materiale chiave fornita dall'utente (tramite l'id di sessione) e la parte memorizzata nel database. Una volta generata la chiave, decifrierai e utilizzerai i credenziali.
In questo modo, se un utente malintenzionato accede al database, non dispone di tutto ciò che è necessario per decrittografare tutte le credenziali. Avrebbero bisogno di un id di sessione per ogni set di credenziali che desiderano decifrare.
Per interrompere le sessioni potresti avere un cron job, o qualche altro meccanismo, eliminare sessioni scadute dal database.