Best practice Memorizzazione di informazioni sensibili nell'applicazione Web

2

Sto sviluppando un'applicazione in php / MySql e sto cercando il miglior approccio dal punto di vista della sicurezza. L'applicazione utilizzerà e memorizzerà le informazioni sensibili. Mi rendo conto che ci sono rischi per tutti gli approcci, ma ho bisogno del miglior approccio possibile che riduca al minimo i rischi per la sicurezza delle informazioni sensibili con questa applicazione.

Ecco le basi dell'applicazione:

1) L'intera applicazione viene eseguita con https e php 7.

2) Registri utente per un account su register.php e le password sono hash password_hash e Password_BCRYPT durante la registrazione.

3) L'utente accede all'applicazione web tramite login.php

4) Una volta effettuato l'accesso, le visite dell'utente gestiscono la pagina delle credenziali (manage-accounts.php) e su un sito web immette url, nome utente e password per i siti Web di terze parti (fondamentalmente come un gestore di password).

5) Il prossimo utente visita la pagina manage-customer.php e inserisce le informazioni sensibili sui clienti che includono ssn #.

6) Infine, l'utente visita la pagina submit-customer.php.

  • In questa pagina l'utente seleziona uno dei siti Web di terze parti inseriti nel passaggio 4 e un cliente è entrato nel passaggio 5 e invia invio.
  • Dopo aver inviato lo script php, verrà selezionato iframe sito Web di terzi (il sito Web di terze parti utilizza https).
  • Registrerà automaticamente l'utente nel sito Web di terze parti (con credenziali dal punto 4). Riempirà automaticamente le informazioni sensibili dei clienti sul modulo web https di terze parti (con le informazioni sui clienti del passaggio 5). iii. Invia il modulo web di terze parti.

Ecco le mie domande:

1) Per un sistema come questo, quale è la metodologia di crittografia / sicurezza    considerato best practice per massimizzare la sicurezza del sensibile    informazioni che sono memorizzate nei passaggi 4 e 5?

  • Non sto cercando di creare la mia crittografia personale. Mi piacerebbe usare un quadro comprovato esistente.

2) Qual è il modo più sicuro per trasmettere le informazioni dal passaggio 4    e 5 su un sito Web di terzi tramite il modulo web iframed?

3) È meglio memorizzare le informazioni sensibili immesse nel passaggio 4    e 5 sul server o sul client? Se sul cliente esattamente come    dovrebbe essere fatto?

    
posta user1609391 18.06.2017 - 00:30
fonte

1 risposta

0

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.

    
risposta data 18.06.2017 - 05:48
fonte

Leggi altre domande sui tag