Non senza SSL

Questo non è sicuro se la password viene inviata sulla rete in testo normale. Anche l'hashing della password sul lato server non è sicuro se la password viene inviata sulla rete in testo semplice.

Poiché il tag HTML <input type="password"/> invia i suoi contenuti in testo normale, questo sarà un problema, indipendentemente dal modo in cui memorizzi la password sul server, a meno che il tuo sito Web non utilizzi SSL per trasmettere la password.

(L'autenticazione HTTP, che fa apparire una finestra di dialogo nel browser che richiede una password, può essere o non essere testo chiaro, a seconda dei meccanismi di autenticazione che il server e il browser hanno in comune. Potrebbe quindi essere un modo per evitare questo senza usare SSL.)

Non se gli amministratori del sito sono sospetti

Ora, supponendo che tu stia utilizzando HTTPS per fare il sito web, questo potrebbe essere sicuro se ti fidi degli amministratori del sito (che possono leggere le password in testo semplice) e di altre persone che hanno accesso alla macchina per comportarsi correttamente. Ora, può essere ovvio che possono fare tutto ciò che vogliono con il tuo sito web (dal momento che lo amministrano), ma se possono leggere la password, potrebbero anche essere in grado di utilizzare le coppie di login / password rubate sui siti di altre persone.

Un modo per proteggere le password dall'amministratore

Un modo sicuro per archiviare e controllare le password è il seguente:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

Per la funzione di hash, prova ad usare qualcosa di strong, e qualcosa che non ha ancora buone tabelle arcobaleno in natura. Puoi modificare la lunghezza del sale, se necessario, aggirare le tabelle arcobaleno.

A seconda dell'ambiente in cui ti trovi, la variabilità della latenza della rete e se i nomi utente devono essere noti pubblicamente, potresti volere un altro percorso di codice calcolare hash('0000'+entered_password) se l'utente non esiste, per impedire agli attaccanti di determinare quali nomi utente sono validi in base al tempo necessario per determinare che la password non è corretta.

Ciò suggerisce che stai mantenendo le password in testo aperto, che è un no-no, anche in scenari di bassa sicurezza.

Dovresti preferire:

if(hash(enteredPassword) == storedHash)

Puoi usare un semplice hash come ad esempio MD5

Sono d'accordo con coloro che suggeriscono l'hashing, ma c'è anche una ruota che stai reinventando qui. A seconda della piattaforma, è possibile trovare uno strumento di gestione ruolo / utente che copra tutte le risorse di gestione degli utenti in modo sicuro e senza richiedere troppi interventi da parte dell'utente.

La sicurezza è un argomento molto delicato, in particolare perché è necessario trovare un equilibrio tra l'inconveniente degli utenti e la sicurezza delle loro informazioni. In genere, la formula per la quantità di sicurezza necessaria è una funzione dell'importanza dei dati. In breve:

isSecuritySufficient = effortToBreak > rewardForBreaking

Un comune equivoco sulle persone che fanno cose cattive è ciò che cercano. La maggior parte di questi ha intenzione di distruggere fiducia . Dovresti sempre fare tutto il possibile per proteggere la fiducia dei tuoi utenti. Parte di questo è fare la dovuta diligenza per assicurarsi che la loro identità sia sicura. Potrebbero interessarsi meno dei dati che archiviano, ma si preoccupano della loro identità, anche alla soglia più bassa di sicurezza.

Sono disponibili numerose opzioni a basso costo (per implementare e influire sull'utente). Uno di questi è l'hashing della password al minimo. Qualsiasi servizio che memorizzi qualcosa di così sensibile come una password in puro testo merita l'imbarazzo di essere hackerato.

Principi generali per la protezione della password

• Mai memorizza le password in testo semplice
• Hash usando una funzione di hash sicura come SHA-1 o anche SHA-512 (anche MD5 è troppo facile trovare un hash corrispondente)
• Utilizza un valore salt dell'applicazione. Il sale è byte casuali o aggiunti a una password per renderlo più difficile da indovinare. Il sale deve essere generato in fase di esecuzione e utilizzando le informazioni sulla macchina come valore di inizializzazione anziché memorizzato e referenziato in alcun modo.
• Utilizza un valore salato specifico dell'utente. Utilizzalo insieme alla tua applicazione salt.
• Cripta tutte le richieste di autenticazione che vanno su una rete. Ciò significa utilizzare SSL per le applicazioni Web.

Dato che si utilizzerà SSL per l'autenticazione, come minimo si desidera crittografare tutte le pagine che gestiscono anche l'account dell'utente. Ciò consente di proteggere il più possibile l'identità di un utente.

Una nota sulla gestione delle password : gli utenti dimenticheranno la loro password di volta in volta. L'assoluta cosa peggiore che puoi fare è inviare loro la password in un'email. Se implementi i principi descritti sopra, non sarai in grado di farlo comunque. È molto meglio fornire un modo per reimpostare la propria password utilizzando un collegamento inviato al proprio indirizzo email registrato. Il link di reset avrà un codice di utilizzo monouso per garantire che la persona che accede alla pagina sia loro.

Va bene a meno che la password non venga utilizzata per nient'altro. C'è ancora il rischio che l'utente decida di riutilizzare la password, quindi sarebbe ancora meglio con:

if(hash(enteredPassword) == hashOfValidPassword)

Se è per te stesso o qualcuno che è a conoscenza che la password è memorizzata in testo normale, allora va bene.

Il codice sorgente è disponibile? Anche se non lo sono, sono abbastanza sicuro che la password possa essere trovata nelle istruzioni della macchina nel caso in cui il binario sia disponibile. Consiglierei di fare un checksum e confrontarlo invece.

Non trascurare mai la sicurezza anche se non è molto importante secondo te.

Assolutamente no. Leggi questo , descrive come gli hacker hanno violato un sito Web di sicurezza. Hai intenzione di considerarti l'anello più debole della catena.

È stato notato in un paio di risposte che non dovresti memorizzare la password stessa, ma un hash - e dovresti usare SSL.

Potresti dire, qual è il problema? Se la mia applicazione viene hackerata, è poco preoccupante. Beh, è un modello abbastanza comune per gli utenti di riutilizzare la stessa password su tutti i siti. Se un hacker ha hackerato il tuo sito e ha avuto accesso alle password degli utenti, l'hacker sarebbe in grado di imitare molti di quegli utenti su altri siti di maggiore importanza per quegli utenti. Quindi l'hacking del tuo sito potrebbe essere il primo passo per un hacker per ottenere l'accesso alle informazioni bancarie per gli utenti.

E il solo hashing della password non è sufficiente. Hai bisogno di hash con un sale. Gli hacker hanno tabelle di ricerca hash inverse, quindi per un determinato hash possono trovare una password corrispondente.

Se si sceglie di non implementare queste funzionalità, è necessario informare gli utenti di questa mancanza di sicurezza, incoraggiandoli a non utilizzare la stessa password che utilizzano altrove.

Finché questo è lato server .. Allora sì.

Se vuoi un po 'più di sicurezza, vai su https e cripta \ hash la password nel DB.