Come assicurare agli utenti che il sito Web e le password sono protetti [chiuso]

Su siti Web affidabili vedo sempre affermazioni come "Tutti i dati sono crittografati" o "Tutte le password sono crittografate utilizzando la crittografia a 128 bit" e così via. Tuttavia non ho mai riscontrato un reclamo come "Tutte le password sono sottoposte a hash".

Sul mio sito Web, memorizzerò tutte le password degli utenti in un database dopo aver usato l'hashing SHA-512 (molto probabilmente) con un salt casuale. Voglio aggiungere uno snipet assicurando agli utenti che le loro password sono sicure in modo che non possano essere scoraggiate dall'uso del mio sito Web perché richiede una password. Voglio che gli utenti si sentano sicuri, ma non credo che tutti sappiano cos'è l'hashing.

LA MIA DOMANDA: Va bene fornire un messaggio che dice che "Tutte le password sono crittografate e sicure" poiché non penso che l'utente medio saprà quale sia la differenza tra hashing e crittografia e molto probabilmente si sentirà sicuro solo perché vede la parola comfort "crittografia"? O c'è un messaggio alternativo che dovrei fornire?

In una nota a margine, sono nuovo nella crittografia e nell'hash della password e mi chiedevo se questo sarebbe abbastanza sicuro per ora mentre lancio il mio sito. Non voglio dire agli utenti che è sicuro se non lo è. Qualsiasi informazione sarebbe molto apprezzata. Grazie.

1. Agli utenti non importa.

   L'unica volta che gli interessa è quando qualcuno preleva i soldi dal proprio conto bancario e sembra che abbia un link che pochi giorni prima, qualcuno ha ottenuto pieno accesso al tuo database.

2. In quasi tutti i casi che ho visto messaggi del genere, erano fuorvianti. Il più esilarante era su un sito Web con etichette in stile "sicuro di livello militare" su ogni pagina. Si è verificato un avviso che informa che il certificato HTTP non è valido. Si è verificata un'iniezione SQL al modulo di accesso. Alcune settimane dopo, il sito Web è stato violato, quindi è scomparso per sempre.

   Smetto di contare il numero di siti Web che affermano che mantengono le informazioni sicure, pur avendo un modulo "Ripristina la mia password", che in realtà invia la password originale via e-mail.

   È come quelle etichette "W3C XHTML valide". Perché di solito vengono messi su siti Web in cui anche una home page contiene almeno dozzine di errori e codici simili <DIV COLOR='red'>?

Se vuoi ancora rassicurare gli utenti, puoi mettere qualcosa come:

Le tue password sono al sicuro. Ricorda che non possiamo vedere la tua password e non ti invieremo mai una e-mail che ti chiederà di fornirne una.

Ma francamente, il modulo "Reimposta la mia password" che sostituisce il "Ho dimenticato la mia password; mandamela via e-mail" è molto più rassicurante di qualsiasi parola.

Suggerimenti dai diversi commenti:

• Non reinventare la ruota: usa OpenID. In questo modo, non memorizzi nemmeno gli hash.

  Fonte: commento di Jan Hudec .

• Dato che sei uno studente, open source il tuo progetto. Poiché la tua preoccupazione è: "Non voglio che gli utenti pensino che le loro password non siano sicure perché alcuni bambini a scuola lo hanno progettato." , non c'è niente di più rassicurante che poter verificare, leggendo il codice sorgente, che è stato scritto da un abile sviluppatore che si preoccupa della sicurezza.

  Fonte: commento di Jan Doggen .

Non memorizzare le password in primo luogo! Segui l'esempio di Stack Exchange e consenti agli utenti di accedere con la loro identità su un altro sito che fornisce l'autenticazione tramite OpenID . Le implementazioni sono disponibili gratuitamente per i più comuni framework Web.

O forse qualsiasi altro protocollo. Se è un progetto interno per qualche istituzione (come suggerisce il tuo commento sull'altra risposta), quasi sicuramente c'è già un LDAP, Kerberos (Windows Active Directory si basa anche su questi due; apache supporta l'autenticazione HTTP contro di loro) o alcuni tale servizio per l'accesso al computer. Connettiti a quello.

Questo ti evita di archiviare informazioni sensibili (molto probabilmente dovrai comunque conservare le autorizzazioni, ma non sono poi così critiche) e gli utenti devono ricordare ancora un altro nome utente e password, quindi nel complesso win-win.

Detto:

"Questo è sicuro."

è un giudizio personale che fai su determinati fatti o processi tecnologici e questo giudizio è limitato da ciò che tu stesso conosci sulla sicurezza in quel momento. Ma puoi garantire senza dubbio che la crittografia, il metodo di archiviazione, ecc. Resisterà a qualsiasi tipo di attacco, anche a quelli che non conosci o che non conosci ancora?

Significato: questa affermazione rischia di essere obsoleta, forse anche senza che tu ne sia consapevole.

Pertanto, tendo a concordare con il commento sopra di @JoachimSauer: descrivi semplicemente cosa fai, come salvi le informazioni degli utenti e dì agli utenti come si suppone che ciò renda sicuro il tuo servizio. Quindi lascia che gli utenti giudichino da soli.

Dipende molto dal contesto del tuo sito web specifico.

Ad esempio, se questo è un sito Web di consumo, le probabilità sono che la maggior parte di loro si preoccupi solo delle loro password (forse), informazioni finanziarie / sanitarie (a seconda del caso) e delle loro informazioni private come immagini (hahaha, sì giusto ...) .

Se si tratta di un'applicazione aziendale, il livello di sicurezza dell'intero sito è rilevante, non solo le password. Allo stesso modo, dipende da chi sono i tuoi utenti target: altamente tecnici / non così tecnici, ecc.

Tutto questo contesto definisce in larga misura cosa dovresti comunicare e quale livello di sicurezza è richiesto.

Ad esempio, per i consumatori non tecnici, è sufficiente avere alcuni commenti generici e semplici, come:

Questo sito è realizzato utilizzando tecniche di sicurezza all'avanguardia. La tua password è sempre crittografata e non invieremo mai le tue foto all'NSA.

(E, come altri hanno già detto, è meglio non avere nemmeno le password, utilizzare alcuni standard come OpenId o OAuth.)

Per le attività altamente tecniche, si vorrebbe avere una pagina completa di dettagli tecnici e procedurali, come:

Abbiamo implementato un SDL completo (ciclo di vita dello sviluppo sicuro) durante tutto il nostro processo di sviluppo e distribuzione.
...
La nostra architettura di sicurezza è ... Questo offre i vantaggi di ...
Garantiamo una codifica sicura come ... di ... Eseguiamo questi e quei test.
La nostra crittografia include questi algoritmi ... e ... Siamo conformi a qualsiasi normativa del settore di cui hai bisogno e certificata per ...
La nostra sicurezza è verificata da questo consulente indipendente di terze parti.
...
Per maggiori dettagli e per rivedere le nostre politiche o per organizzare un controllo indipendente, si prega di discutere con l'ufficio marketing.

Certo, non vuoi dare via troppe informazioni dettagliate, dovrebbe essere più sul processo che sulle password stesse ... E ovviamente dovrebbe essere ovvio che la realtà dovrebbe effettivamente rispettare tutto ciò che scrivi lì , qualunque contesto tu abbia a che fare.

Essendo una delle risposte a cui si allude, la maggior parte degli utenti non si preoccupa, non capisce ciò che dici e si iscrive comunque, anche se dici di inviare i dati dell'utente alla NSA.
Questo non è per loro.
Sarebbero altrettanto felici di non avere password, lasciami scegliere il mio nome utente dall'elenco e accedermi automaticamente.

Ovviamente questo è per la piccola percentuale che interessa : dovresti consentire agli utenti intelligenti di fare ciò che è giusto, dare loro le informazioni di cui hanno bisogno e concedere loro l'educazione che potrebbero chiedere.
In caso contrario, quando ciò va storto, l'altro 98% si sveglia improvvisamente e si arrabbia.
("Certo, sapevo che non avevo bisogno di una password per vedere le mie foto, ma non pensavo che anche chiunque altro potesse vederle !!")

Se vuoi che il tuo sistema sia sicuro, la forza dell'algoritmo delle password è insignificante: la maggior parte degli hacker può decifrare le password in pochissimo tempo, soprattutto se la password scelta è piccola o è composta da parole generiche che l'hacker ha già "decifrato e archiviato "usiong tavoli arcobaleno e simili. Leggi l'articolo di ArsTechnica sul crack delle password per molte informazioni.

Quello che devi fare è assicurare agli utenti che i cattivi non possono arrivare ai loro hash in primo luogo. Un'azienda attenta alla sicurezza per cui ho lavorato aveva un sistema Web a 3 livelli in cui i server Web non erano fisicamente connessi ai server di database. Quando il mio capo voleva mettere il suo sito Web e avere accesso diretto al DB (codice mal progettato, 'nuff ha detto) gli è stato detto che non poteva averlo, e quando ha spinto ... gli è stato detto che non c'erano fili tra di loro . Ha dovuto progettarlo in modo che passasse tutte le richieste di dati attraverso un servizio di livello intermedio. E quei servizi non solo erano garantiti, ma esponevano una superficie minima agli attacchi e venivano bloccati. E il DB non ha mai esposto nessuna delle sue tabelle per la lettura, solo le procedure memorizzate che a loro volta sono state bloccate, quindi solo il servizio pertinente ha avuto accesso.

Non è stato così male programmare come potresti pensare, una volta che hai conosciuto l'architettura e la separazione di ogni livello, è stato abbastanza facile codificarlo.

Puoi sviluppare il sito più sicuro del pianeta e avere un'esperienza utente davvero scadente. Gli utenti presumeranno che il tuo sito non sia sicuro.

Puoi costruire il sito meno sicuro del pianeta e avere un'esperienza utente straordinaria. Gli utenti supporranno che il tuo sito sia sicuro. Almeno fino a quando non appare nelle notizie della sera.