Best practice Memorizzazione di informazioni sensibili nell'applicazione Web

L'ambito completo di questa domanda è enorme (diversi aspetti della progettazione di applicazioni sicure). Non sono sicuro che sia sufficiente un semplice Q & A qui.

Data la serietà di ciò che stai tentando, dovresti ottenere un strong AppSec pro nel tuo team e considerare un approccio olistico che includa modelli di minaccia, progettazione sicura, principi di codifica sicuri, test di sicurezza e verifica.

Cercherò risposte brevi per domande mirate - con la clausola di esclusione della responsabilità che gli esperti di AppSec stanno ancora discutendo di alcune di queste, soprattutto perché alcune delle risposte sono "in evoluzione" (ad esempio, archiviazione sicura delle credenziali - alcune discussioni in favore di K12 e Blake2 su PBKDF2 / bcyrpt / scrypt).

Questa non era una domanda ma:

2) User registers for an account at register.php and passwords is hashed password_hash and Password_BCRYPT during registration.

Assicurati di utilizzare un sale casuale considerevole. Vedi questo vecchia discussione su hash e dimensioni del sale per un po 'di comprensione. OWASP ha una guida decente e recente per questo qui . Si noti che le discussioni del 2013 riguardavano circa 64 e 128 bit di sale. OWASP menziona 64 byte (non bit) salt. Inoltre, le funzioni consigliate sono non solo semplici hashing.

Finalmente hai menzionato "fondamentalmente come un gestore di password". Questo complica un po 'le cose. Dovrai lasciare l'utente sotto controllo - con almeno una ragionevole garanzia che parte delle chiavi del regno sono bloccate nel loro cervello o nel loro sistema. Il metodo usuale per questo è che la chiave principale dell'utente (password) non è memorizzata da nessuna parte (nemmeno sul sistema locale) ma viene utilizzata per ricavare la chiave (o le chiavi) utilizzata per l'archiviazione della password.

Ora per le tue domande:

1) For a system like this, what encryption/security methodology is considered best practice to maximize security of the sensitive information that is stored in step 4 and 5?

Spiacente, nessuna risposta breve per questa domanda.

Questo sistema richiederebbe un modello completo di minaccia + una privacy e una progettazione della sicurezza da zero. È bene che tu sia partito abbastanza bene, ma per favore non sottovalutare i compiti a portata di mano. OWASP ha delle guide per la maggior parte delle parti, anche se le persone con una profonda esperienza sono note per diss-inare alcune aree (di solito sul conto che "non è perfetto" ... che, considero un'obiezione pedante).

2) What is most secure way to transmit the information from step 4 and 5 to a third-party website via the iframed web form?

Come utente attento alla sicurezza non mi fido degli iframe. Non li consiglio agli utenti. Se quello che stai facendo è simile a una funzionalità di gestione password - ti suggerisco di esplorare alternative.

3) Is it better to store the sensitive information entered in step 4 and 5 on the server or on the client? If on the client exactly how should this be done?

Vedi un para precedente dove ho menzionato chiave principale (password)

Se segui questo consiglio, dovresti archiviare lo hashed-stash per utente sul tuo server. Non esiste un reale vantaggio (tecnico) di archiviare password hash / crittografate in modo corretto sul sistema dell'utente in cui può essere facilmente cancellato per una serie di motivi.

Spero che questo aiuti.