Se creo un account di accesso per un'app che presenta un rischio di sicurezza medio-basso (in altre parole, non è un'app bancaria o altro), è accettabile per me verificare una password inserita dall'utente semplicemente dicendo qualcosa come:

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

Sembra facile essere efficace, ma certamente non mi dispiacerebbe se fosse tutto ciò che era richiesto. È sufficiente un semplice controllo su combo nome utente / password?

Aggiornamento: il particolare progetto sembra essere un servizio Web, la verifica è interamente lato server e non è open-source. Il dominio cambia il modo in cui lo affronteresti?

Non senza SSL

Ciò non è sicuro se la password viene inviata in rete in testo semplice. Anche l'hash della password sul lato server non è sicuro se la password viene inviata sulla rete in testo semplice.

Poiché il <input type="password"/>tag HTML invia i suoi contenuti in testo semplice, 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 apre una finestra di dialogo nel browser che richiede una password, può essere o meno un testo chiaro, a seconda dei meccanismi di autenticazione che il server e il browser hanno in comune. Quindi potrebbe essere un modo per evitarlo senza usare SSL).

Non se gli amministratori del sito sono sospetti

Ora, supponendo che tu stia usando HTTPS per fare il sito web, questo potrebbe essere sicuro se ti fidi dei tuoi amministratori del sito (che possono leggere password di 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 gestiscono), ma se sono in grado di leggere la password, potrebbero anche essere in grado di utilizzare le coppie di login / password rubate sui siti di altre persone.

Un modo che protegge 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 hash, prova a usare qualcosa di forte e qualcosa che non ha ancora buoni tavoli arcobaleno in natura. È possibile modificare la lunghezza del sale, se necessario, aggirare i tavoli arcobaleno.

A seconda dell'ambiente in cui ci si trova, della variabilità della latenza della rete e del fatto che i nomi degli utenti siano noti pubblicamente, è possibile che sia necessario calcolare un altro percorso del codice hash('0000'+entered_password)se l'utente non esiste, al fine di impedire agli aggressori di determinare quali nomi utente sono validi in base al tempo impiegato determina che la password non è corretta.

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

Dovresti piuttosto avere:

if(hash(enteredPassword) == storedHash)

Puoi usare un hash semplice come ad esempio MD5

Concordo con coloro che suggeriscono l'hashing, ma c'è anche una ruota che stai reinventando qui. A seconda della piattaforma, è possibile trovare probabilmente uno strumento di gestione ruoli / utenti che copre tutte le attività di gestione degli utenti in modo sicuro e senza richiedere troppo intervento da parte dell'utente.

La sicurezza è un argomento molto delicato, in particolare perché deve esserci un equilibrio tra l'inconveniente degli utenti e la sicurezza delle loro informazioni. In genere, la formula per quanta sicurezza è necessaria dipende dall'importanza dei dati. In breve:

isSecuritySufficient = effortToBreak > rewardForBreaking

Un comune malinteso sulle persone che fanno cose cattive è quello che stanno cercando. Molti di loro cercano di distruggere la fiducia . Dovresti sempre fare tutto il possibile per proteggere la fiducia dei tuoi utenti. Parte di ciò sta facendo la dovuta diligenza per assicurarsi che la loro identità sia sicura. A loro potrebbe interessare di meno i dati che memorizzano, ma a loro importa della loro identità, anche alla soglia di sicurezza più bassa.

Sono disponibili numerose opzioni a basso costo (da implementare e di impatto per l'utente). Uno di questi è l'hashing della password al minimo indispensabile. Qualsiasi servizio che memorizza qualcosa di sensibile come una password in testo normale merita l'imbarazzo di essere violato.

Principi generali per la protezione con password

• Non archiviare mai le password in testo semplice
• Hash usando una funzione hash sicura come SHA-1 o persino SHA-512 (anche MD5 è troppo facile per trovare un hash corrispondente)
• Utilizzare un valore sale dell'applicazione. Il salt è byte casuali o aggiunti a una password per rendere più difficile indovinare. Il sale deve essere generato in fase di esecuzione e utilizzando le informazioni sulla macchina come valore seme anziché archiviato e referenziato in alcun modo.
• Utilizzare un valore salato specifico dell'utente. Utilizzare questo in combinazione con il sale dell'applicazione.
• Crittografa tutte le richieste di autenticazione che vanno su una rete. Ciò significa che utilizzare SSL per le applicazioni Web.

Dal momento che useresti SSL per l'autenticazione, come minimo vuoi crittografare tutte le pagine che trattano anche dell'account dell'utente. Ciò consente di proteggere il più possibile l'identità di un utente.

Una nota sulla gestione delle password : gli utenti dimenticano di tanto in tanto la propria password. La cosa peggiore in assoluto che puoi fare è inviare loro la password in un'e-mail. Se si implementano i principi di cui sopra, non si sarà in grado di farlo comunque. È molto meglio fornire un modo per reimpostare la password usando un collegamento inviato al loro indirizzo e-mail registrato. Quel link di reimpostazione avrà un codice di utilizzo una tantum per garantire che sia la persona che accede alla pagina.

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

if(hash(enteredPassword) == hashOfValidPassword)

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

Il codice sorgente è disponibile? Anche in caso contrario, sono abbastanza sicuro che la password potrebbe 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 secondo te non è molto importante.

Assolutamente no. Avere una lettura di questo , si descrive come gli hacker violato un sito web di sicurezza. Il tuo piano ti avrebbe come 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 grosso problema? Se la mia applicazione viene hackerata, questo è poco preoccupante. Bene, è un modello abbastanza comune per gli utenti di riutilizzare la stessa password su tutti i siti. Se fosse un hacker per hackerare il tuo sito e ottenere l'accesso alle password degli utenti, l'hacker sarebbe stato in grado di impersonare 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 l'hashing della password non è sufficiente. Devi frullarlo con un sale. Gli hacker hanno tabelle di ricerca hash inversa, quindi per un dato 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 utilizzata altrove.

Finché si tratta del lato server .. Quindi sì.

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