Memorizzazione password in database in testo normale rispetto alle esigenze del cliente

Question

Voglio chiamare "memorizzare una password in un testo in un database" una cattiva pratica ... ma il nostro cliente ha fatto questo nella sua applicazione. Vogliono che rinnovi quell'applicazione.

Il mio punto: voglio cambiare questo ... ma poiché non è un bisogno per il nostro cliente non è ancora chiaro.

Come gestisci tali problemi relativi alla sicurezza? Dal mio punto di vista è difficile spiegare tali problemi ai clienti.

Answer 1

Scrivete una lettera formale breve, chiara e priva di gergo che dichiari le vostre preoccupazioni e concludendo che nel vostro parere professionale, dovrebbe essere corretto. Rivolgilo a qualcuno ragionevolmente in alto nel cliente.

Se poi decidono di ignorare il tuo consiglio, questa è la loro prerogativa.

(conservare una copia della lettera da soli, anche.)

Answer 2

Si dovrebbe semplicemente spiegare al cliente che il login non è sicuro se qualcuno con cattive intenzioni ha accesso al database. Se l'applicazione è all'interno dell'azienda, forse non vale la pena cambiarla. Devi analizzare se è davvero un valore e puoi solo conoscerlo parlando con il cliente. Forse i dati non sono molto confidenziali e non è una priorità avere molta sicurezza. Tutto dipende dall'obiettivo del software e da dove si trova il database e da ciò che il cliente desidera che i suoi dati siano protetti.

Answer 3

Non memorizzare mai una password in testo semplice.

mi sento di raccomandare di leggere queste domande:

• How to best store user information and user login and password
• Best practices for storing database passwords
• Password Management Best Practices (soup to nuts, not just storage or generation)
• Salting Your Password: Best Practices?
• Is it ever ok to store password in plain text in a php variable or php constant?

Se il cliente non è interessato ai dettagli, è sufficiente implementarlo. (Fornire anche una procedura corretta per il recupero della password). Non è davvero un grosso problema per te come programmatore, ma migliora davvero la sicurezza del tuo prodotto nella qualità &.

Se vuole sapere cosa intendi cambiare, spiegaglielo. Parlagli dei problemi di sicurezza e lui capirà. Anche un esempio dal vivo aiuta davvero ad aprire gli occhi dei clienti: basta recuperare la sua password dal vecchio sistema e mostrargli quanto sarebbe facile per tutti.

Ho sempre fatto così: se penso che sia importante avere una funzione di sicurezza in uno dei miei prodotti, l'ho sempre incluso. Aggiunge un grande vantaggio alla qualità dei tuoi prodotti e ti regala molti momenti "woah hai pensato a tutto".

Answer 4

Se possibile, una dimostrazione dal vivo funziona alla grande. Chiedi all'utente di creare un account con una password (non la password che normalmente usano). Vai nel database e recupera, e spiega che chiunque abbia accesso al tuo database (sia per autorizzazione, sia per violazione della sicurezza) può semplicemente andare avanti e farlo.

Answer 5

penso "cattiva pratica" è un eufemismo. "Irresponsabile" potrebbe essere più preciso.

Se vale la pena proteggerlo con una password, vale la pena farlo correttamente. Memorizzare le password in testo semplice è una violazione della sicurezza imbarazzante in attesa di accadere.

Se "sicurezza" è ovunque nei desideri dei clienti (che suppongo sia, poiché ci sono password), hanno implicitamente chiesto un sistema di sicurezza decente, che include la corretta gestione delle password. Non possono chiedere che "le password siano archiviate in modo sicuro" (hash e salate) perché non sono gli esperti; questo è quello per cui ti hanno assunto.

Answer 6

Da un punto di vista strettamente professionale, devi chiederti se lasciarlo come sarebbe un problema più avanti (hai un contratto di supporto che può essere richiesto in caso di un highjacker che ruba un pass dal DB?)

Personalmente, faccio non pensano che è difficile da spiegare a qualcuno perché memorizzazione passa non criptati è sicuro, tuttavia, come ha sottolineato Daok, si ha realmente bisogno non ti preoccupare passa sistema che non contiene dati magici personali-segreti-segreti.

Al giorno d'oggi sembra così facile utilizzare la crittografia per questo scopo che, a seconda della tecnologia che si sta utilizzando, potrebbe significare solo il minimo sforzo nella codifica e tempo per farlo.

Buongiorno amico!

Answer 7

Spiegherei che quello che hanno fatto è una cattiva pratica e chiedere loro se vorrebbero che tu cambiasse. Consiglierei di non fare nulla al di fuori del permesso di ciò che ti è stato chiesto di fare senza consultarli.

Answer 8

Le dimostrazioni e le spiegazioni sono molto utili, ma quando si dice di "rinnovare" l'applicazione, si sta lavorando dalla documentazione, da una specifica funzionale o tecnica?

Chiedere di essere coinvolto nella finalizzazione di questi documenti e incluso nell'accettazione sarebbe una buona idea.

In definitiva, è è un bisogno per il cliente, semplicemente non ce ne rendiamo ancora conto.

Answer 9

Il motivo migliore per non mantenere mai la password in testo normale è in realtà legale.

Ci sono leggi, come il Data Protection Act nel Regno Unito, che affermano che devono essere fatti sforzi ragionevoli per proteggere i dati sensibili. Memorizzare le password in testo semplice viola chiaramente questo e, a sua volta, potenzialmente nulla l'assicurazione di indennizzo che si ha in caso di violazione della sicurezza. Questo potrebbe lasciarti aperto a una grande causa di responsabilità se non prendi questa semplice misura.

Quando si tratta di uomini d'affari, si deve sempre parlare in termini di tasche, e affermando che un'ora di lavoro per cancellare le password e cambiare l'accesso costerà loro una piccola quantità rispetto al costo potenziale se qualcosa andato male.

Sarebbe inoltre opportuno notare, che se qualcuno ha progettato un sistema fondamentalmente errata come questo, la cappa probabile che vi sia un errore che può esporre dati sensibili come questo è esponenzialmente superiore.

In cima a questo, come altri hanno affermato, una dimostrazione dal vivo è buona. estrai dal database una password di membri del personale casuali e provala con i loro altri sistemi, non dovrai provarne molti prima di entrare.

Answer 10

Bastanneu, sai l'espressione inglese "Coprire il vostro un **"? Immaginate questo scenario:

1. Siete preoccupati che non si preoccupino della sicurezza e non vogliono sentire il vostro messaggio. Diglielo comunque e loro dicono di no a qualsiasi cambiamento.
2. Vengono violati.
3. Ti chiedono perché non ha detto nulla prima.

Vi consiglio di rendere le vostre preoccupazioni note in anticipo. E mantieni la prova (lettera firmata, ecc.).

Answer 11

Questa è una situazione in cui devi esprimere le cose correttamente. Le password in chiaro non sono qualcosa che si definisce "cattiva pratica". È qualcosa che tu esprimi come rotto, qualcosa che semplicemente non può essere fatto. È necessario rendere il contratto contingente per la correzione della memorizzazione della password, non è facoltativo. Questo non vuol dire che non puoi avere una discussione amichevole sul perché non può essere fatto, ma devi chiarire che non lo farai, non importa quale.

Allora la domanda diventa come si fa a convincere la gente di affari che non è una soluzione valida. Questo dovrebbe anche essere abbastanza facile. Trova i responsabili delle decisioni e portali su una macchina in cui è aperto il browser delle query del database. Digita la query "Seleziona password da credenziali dove username = 'DECISION_MAKERS_USERNAME'", quindi esegui il decision maker (sii educato e non guardi lo schermo mentre lo fanno) Spiega che qualsiasi dipendente con accesso al database sarà in grado di Fai questo. Generalmente penserei che sarebbe il trucco, ma se hai bisogno di fare ulteriori convincenti spiega che una grande parte degli utenti condivide le password attraverso le applicazioni e che qualsiasi dipendente sarebbe in grado di entrare in cose come conti bancari, account di posta elettronica, ecc. esso. Se questo non è ancora abbastanza, spiega esempi di cause legali e multe per le aziende che hanno fatto questo.

Qualunque cosa tu faccia, non spiegare i dettagli tecnici di qualsiasi di esso. Basta mostrare le conseguenze. Non spiegare hash, sali o usare parole come "testo in chiaro". Spiega solo che è ora che le persone possono vedere le password e che sarà facile cambiarle in modo che nessuno possa vedere le password, ma funzionerebbero comunque.

Se non riesci a convincerli, non prendere il cliente. E probabilmente dovresti avvertire gli utenti dell'applicazione che le loro password non sono archiviate in modo sicuro.