Abbiamo un numero di ambienti di sviluppo interni che utilizzano password deboli nei componenti Auth e SQL; in particolare utilizzando password come "password" o "Password1".
Ovviamente sono cambiati per gli ambienti UAT e di produzione ma come ci sentiremmo colpevoli di rilassarci per comodità durante lo sviluppo di soluzioni?
È tutta una questione di fiducia e / o responsabilità. Se il tuo ambiente interno è completamente sicuro / separato da Internet puoi farlo, ma generalmente non è una buona idea.
Esempio: cosa succede se un dipendente viene lasciato andare? Puoi fidarti di quella persona allora? Se collegato a Internet è molto brutto e l'ho visto accadere in aziende per cui ho lavorato in passato.
-
Risposta ai commenti per maggiore chiarezza:
Più strong di 'password' o 'Password1' non significa necessariamente estremista. Per gli ambienti di produzione, chiedo ai miei dipendenti di fare meglio di così, ma non richiedono codici confinanti o ridicoli a meno che non si tratti di dati bancari o di rischi per la sicurezza.
Le altre risposte hanno toccato parti del puzzle, ma la visione di alto livello è questa: tutta la sicurezza si riduce alla valutazione del rischio, alla gestione del rischio e alla mitigazione del rischio.
Per questo motivo, non esiste una risposta generica per la tua domanda. Ecco alcuni dei tipi di cose che devi considerare per determinare se questa pratica è accettabile o meno nel tuo ambiente.
Sei tu a controllare chi ha accesso al sistema? (In questo caso, in quanto hai menzionato che gli utenti necessitano di un accesso di rete.)
Chi ha accesso al sistema? (L'enumerazione degli utenti che potrebbero potenzialmente accedere al sistema ti darà un'idea migliore dell'esposizione.)
Ti fidi di queste persone? (Questo sarà soggettivo, piuttosto che obiettivo, ma lo rende una decisione facile se la risposta è "No".)
Che danno potrebbe essere fatto se il sistema viene abusato? (Se qualcuno aggiunge, modifica, elimina o ruba dati dal sistema, qual è il costo? I dati sono preziosi e un venditore che ha accesso al sistema può essere tentato di portarlo con sé quando lascia il lavoro, per istanza? O forse i sistemi non contengono nulla di valore e possono essere facilmente e automaticamente ri-basati a uno stato buono noto.)
Qual è il rischio che il sistema venga abusato? (Ancora soggettivo, ma basato su ciò che sai sul sistema e sugli utenti, quali sono le probabilità che qualcuno possa provare ad accedere maliziosamente al sistema?
Qual è il costo di mitigazione del rischio? (In questo caso, la mitigazione implicherà l'implementazione di una buona politica di password. Ciò causerà un ulteriore lavoro per gli sviluppatori?)
Dopo aver analizzato i rischi per i tuoi sistemi, ora puoi prendere una decisione di qualità e informata sul fatto che ci siano rischi che valgono la pena di un ulteriore sforzo per mitigarli. Se i rischi sono estremamente bassi, come non è impossibile immaginare per un ambiente di sviluppo interno, potrebbe non valerne la pena rendere gli sviluppatori ancora più difficili. Se tuttavia sono coinvolti dati sensibili, o un attacco dannoso su una delle tue applicazioni avrebbe un costo significativo per recuperarne alcuni e la probabilità di tale attacco non è trascurabile, è probabile che il piccolo sforzo aggiuntivo richiesto per le password complesse possa essere vale quel costo.
Leggi altre domande sui tag passwords password-policy