Come assicurare agli utenti che il sito Web e le password siano al sicuro [chiuso]

1. Gli utenti non si preoccupano.

   L'unica volta che si preoccupano è quando qualcuno ritira il denaro dal proprio conto in banca e sembra che abbia un link che pochi giorni prima, qualcuno ha ottenuto pieno accesso al proprio database.

2. In quasi tutti i casi ho visto questi messaggi, erano fuorvianti. Il più esilarante era su un sito web con etichette "sicure di livello militare" su ogni pagina. C'è stato un avviso che indica che il certificato HTTP non è valido. C'era un'iniezione SQL sul modulo di accesso. Poche settimane dopo, il sito Web è stato violato, quindi è scomparso per sempre.

   Ho smesso di contare il numero di siti web che affermano di mantenere le informazioni protette, pur avendo un modulo "Recover my password", che in realtà invia la password originale via e-mail.

   È come le etichette "XHTML valide per W3C". Perché vengono solitamente inseriti in siti Web in cui anche una home page contiene almeno decine di errori e codice come <DIV COLOR='red'> ?

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

Your passwords are kept secure. Remember that we can't see your password and will never send you an e-mail asking you to provide one.

Ma francamente, il modulo "Reimposta la mia password" in sostituzione di "Ho dimenticato la password, inviarlo 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, apri il tuo progetto. Dal momento che la tua preoccupazione è: "Non voglio che gli utenti pensino che le loro password non siano sicure perché alcuni bambini a scuola l'hanno progettata." , non c'è niente di più rassicurante che essere in grado di controllare, leggendo il codice sorgente, che è stato scritto da uno sviluppatore abile a cui importa 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 la maggior parte dei framework web comuni.

O forse qualsiasi altro protocollo. Se si tratta di un progetto interno per qualche istituzione (come suggerisce il tuo commento sull'altra risposta), c'è quasi sicuramente 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. Collegati a quello.

Questo ti evita di archiviare informazioni sensibili (probabilmente dovrai ancora memorizzare permessi, ma non sono che critici) e gli utenti devono ricordare ancora un altro nome utente e password, quindi complessivo win-win.

dicendo:

"This is secure."

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

Significato: Questa affermazione rischia di essere obsoleta, forse anche senza esserne a conoscenza.

Pertanto, sono tendenzialmente d'accordo con il commento sopra di @JoachimSauer: descrivi semplicemente cosa fai, come salvi le informazioni dell'utente e chiedi agli utenti come questo dovrebbe rendere sicuro il tuo servizio. Quindi lascia che gli utenti giudichino da soli.

Dipende davvero dal contesto del tuo sito web specifico.

Ad esempio, se si tratta di un sito Web per consumatori, la maggior parte di loro si preoccuperà solo delle proprie password (forse), delle informazioni finanziarie / sanitarie (dipendenti) e delle loro informazioni private come le immagini (hahaha, sì giusto. ..).

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

Tutto questo contesto definisce in modo significativo che dovresti comunicare e quale livello di sicurezza è richiesto.

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

This site is built using state-of-the-art security techniques. Your password is always encrypted, and we will never ever send your pictures to the 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, ti consigliamo di avere una pagina completa di dettagli tecnici e procedurali, come ad esempio:

We have implemented a full SDL (secure development lifecycle) throughout our development and deployment process.
...
Our security architecture is ... This gives the benefits of...
We ensure secure coding such as ... by... We perform these and those tests.
Our cryptography includes these algorithms... and ... We are compliant with whichever industry regulation you need, and certified for...
Our security is verified by this independent 3rd party consultant.
...
For more details, and to review our policies or to arrange an independent audit, please discuss with the marketing department.

Naturalmente, non vuoi dare via too molte informazioni dettagliate, dovrebbe essere più sul processo che le password stesse ... E ovviamente dovrebbe andare senza dire che la realtà dovrebbe in realtà conformarsi a qualunque cosa tu scriva, qualunque contesto tu abbia a che fare.

Come una delle risposte a cui ho accennato, la maggior parte gli utenti non se ne preoccupano, non capirebbero qualsiasi cosa tu dica loro, e comunque registrerebbero comunque, anche se tu dici che tu mandi l'utente dati alla NSA.
Questo non fa per loro.
Sarebbero altrettanto contenti di non avere alcuna password, lasciami scegliere il mio nome utente dalla lista e loggarmi automaticamente.

Ovviamente questo è per la piccola percentuale che cura - dovresti consentire agli utenti intelligenti di fare ciò che è giusto, fornire loro le informazioni di cui hanno bisogno e concedere loro l'istruzione che potrebbero chiedere.
Se non lo fai, quando questo 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 qualcuno altro potesse vederle anche io !!")

Se vuoi che il tuo sistema sia sicuro, la forza dell'algoritmo della password è insignificante - la maggior parte degli hacker può crackare le password in un batter d'occhio, specialmente se la password scelta è piccola o è composta da parole generiche che l'hacker già " incrinato e memorizzato "tabelle arcobaleno usiong e simili. Leggi l'articolo di ArsTechnica sul crack delle password per un sacco di informazioni.

Quello che devi fare è assicurare agli utenti che i cattivi non riescono ad arrivare ai loro hash in primo luogo. Una società per la sicurezza che ho lavorato per me aveva un sistema Web a 3 livelli in cui i server Web non erano fisicamente collegati ai server del database. Quando il mio capo voleva mettere il suo sito web e avere accesso diretto al DB (codice mal progettato, "ha detto nuff), gli fu detto che non poteva averlo, e quando spinse ... fu detto che non c'erano fili tra loro . Ha dovuto architettarlo in modo che passasse tutte le richieste di dati attraverso un servizio di livello intermedio. E quei servizi non sono stati solo garantiti, ma hanno esposto una superficie minima per attaccare e sono stati bloccati. E il DB non ha mai esposto nessuna delle sue tabelle per la lettura, solo le stored procedure che a loro volta erano bloccate in modo tale che solo il servizio pertinente aveva accesso.

Non è stato così male codificarlo, come si potrebbe pensare, una volta che si conosceva l'architettura e la separazione di ogni livello, era abbastanza facile da codificare.

Puoi sviluppare il sito più sicuro del pianeta e avere un'esperienza utente davvero scarsa. 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 presumeranno che il tuo sito sia sicuro. Almeno fino a quando non appare nei notiziari serali.