Tenemos varios entornos de desarrollo interno que usan contraseñas débiles en los componentes Auth y SQL; particularmente utilizando contraseñas como "contraseña" o "Contraseña1".
Obviamente, estos cambios se han modificado para los entornos UAT y de producción, pero ¿qué tan culpables debemos sentirnos por relajar nuestros hábitos por motivos de facilidad mientras desarrollamos soluciones?
Todo es una cuestión de confianza y / o responsabilidad. Si su entorno interno es completamente seguro / separado de Internet, puede hacerlo, pero en general no es una buena idea.
Ejemplo: ¿Qué sucede si se deja ir a un empleado? ¿Puedes confiar en esa persona entonces? Si estoy conectado a Internet, eso es muy malo y lo he visto en empresas en las que he trabajado en el pasado.
-
Respuesta a los comentarios para mayor claridad:
Más fuerte que 'contraseña' o 'Contraseña1' no significa necesariamente extremista. Para los entornos de producción, le pido a mi gente que lo haga mejor que eso, pero que no requiere códigos que limiten con extremos o ridículos a menos que sean datos bancarios o exista un alto riesgo de seguridad.
Las otras respuestas han tocado piezas del rompecabezas, pero la visión de alto nivel es la siguiente: toda la seguridad se reduce a la evaluación de riesgos, la gestión de riesgos y la mitigación de riesgos.
Debido a esto, no hay una respuesta genérica para su pregunta. Estos son algunos de los tipos de cosas que debe observar para determinar si esta práctica es aceptable en su entorno.
¿Controlas quién tiene acceso al sistema? (Lo hace en este caso, ya que mencionó que los usuarios necesitan acceso a la red).
¿Quién tiene acceso al sistema? (Enumerar a los usuarios que podrían acceder al sistema le dará una mejor idea de la exposición).
¿Confías en estas personas? (Esto va a ser subjetivo, en lugar de objetivo, pero lo hace una decisión fácil si la respuesta es "No").
¿Qué daño se podría hacer si se abusa del sistema? (Si alguien agrega, edita, elimina o roba datos del sistema, ¿cuál es el costo? ¿Son valiosos los datos? ¿Podría un vendedor que tenga acceso al sistema tener la tentación de llevársela cuando salga del trabajo? ¿O tal vez los sistemas no contienen nada de valor y pueden volver a basarse fácil y automáticamente en un buen estado conocido?)
¿Cuál es el riesgo de que se abuse del sistema? (Aún subjetivo, pero según lo que sabe sobre el sistema y los usuarios, ¿cuáles son las posibilidades de que alguien intente acceder de manera malintencionada al sistema?
¿Cuál es el costo de mitigar el riesgo? (En este caso, la mitigación implicará la implementación de una buena política de contraseña. ¿Eso va a causar un trabajo adicional para los desarrolladores?)
Una vez que haya analizado los riesgos para sus sistemas , ahora puede tomar una decisión informada y de calidad sobre si existen riesgos en los que valga la pena el esfuerzo adicional para mitigarlos. Si los riesgos son extremadamente bajos, como no es imposible imaginarlo para un entorno de desarrollo interno, puede que no valga la pena hacer que los desarrolladores vivan un poco más difícil. Sin embargo, si hay datos confidenciales involucrados, o un ataque malintencionado en una de sus aplicaciones tendría un costo significativo para recuperar algunos y la probabilidad de tal ataque no es despreciable, entonces es probable que el pequeño esfuerzo adicional requerido para contraseñas seguras vale la pena ese costo.
Lea otras preguntas en las etiquetas passwords password-policy