¿Cómo se M1uG*xgRCthKWwjIjWc*010iSthY9buc
detecta la cadena aleatoria como demasiado simplista / sistemática para una contraseña de acuerdo con passwd y cracklib-check ? Pruébelo en su máquina y vea
echo "M1uG*xgRCthKWwjIjWc*010iSthY9buc" | cracklib-check
Tenga en cuenta que esta no es mi contraseña, sino otra cadena generada aleatoriamente desde el mismo generador de contraseñas aleatorias que produce el mismo resultado.
M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK
/dev/urandom
para generar una contraseña?Respuestas:
Dado que cracklib es de código abierto, la respuesta se puede encontrar en el código fuente .
"Demasiado simplista / sistemático" significa que hay demasiados caracteres precedidos por uno de sus vecinos alfabéticos. Por lo tanto, "ab" o "ba" se consideran malos, pero "ac" o "ca" están bien ya que se omite b.
Antes de este parche del 02-03-2010 , permite como máximo cuatro caracteres que exhiban este rasgo. Por ejemplo, "bar12345" fallaría, porque los caracteres "a", "2", "3", "4" y "5" son vecinos alfabéticos de los caracteres anteriores.
slm descubrió en su respuesta que
M1uG*xgRCthKWwjIjWc*010iS
estaba bien, mientrasM1uG*xgRCthKWwjIjWc*010iSt
que no lo está. Analicemos Estos son los caracteres que cracklib-check cree que son indicaciones de una contraseña sistemática:que está por debajo del máximo de cuatro, pero sumando t:
lo empuja por encima del límite, ya que T sigue a S (parece que la prueba no distingue entre mayúsculas y minúsculas).
El parche cambia el límite máximo, por lo que depende de la longitud total de la contraseña, para evitar falsos positivos como este.
fuente
Ww
)?En Fedora 19
Cuando lo ejecuto me sale bien. Estoy en Fedora 19.
Aquí está la información de la versión:
NOTA: También lo probaría con comillas simples en lugar de dobles qutoes, ya que se trata de
*
que se estén expandiendo de manera extraña en usted.CentOS 5 y 6
Probar su ejemplo en CentOS 6 estuvo bien, obtuve un OK, pero falló como lo describió en CentOS 5.9.
Información de la versión:
¿Un insecto?
En lo que te has topado parece ser un error. Si toma su cadena y ejecuta más y más de su cadena
cracklib-check
, notará que cuando llegue al 26 ° carácter, comenzará a fallar:Profundizando en esto si cambio el último personaje de a
t
para decirv
que continúa funcionando.Entonces parece que en la versión de
cracklib-check
se está colgando en la subcadenaSth
.Definitivamente hay algo extraño en los trozos de la cadena que ha proporcionado. Si tomo la pieza del extremo de la cola y omito la parte frontal, también puedo hacer que esta parte falle.
¡Esa misma cadena también causa problemas en Fedora 19 y CentOS 6!
ACTUALIZACIÓN # 1Basado en la muy buena investigación de @ waxwing , ahora sabemos que la heurística utilizada se disparó si> 4 caracteres eran demasiado adyacentes entre sí. Se introdujo un parche que cambió esta heurística para que se tuviera en cuenta la longitud total de la contraseña considerada para eliminar estos falsos positivos.
Conclusiones?
Según algunas de mis pruebas limitadas, parece que hay algunas heurísticas extrañas en juego aquí. Ciertas cadenas que aparentemente estarían bien lo están tropezando.
Si está tratando de codificar esto, sugeriría concluir la generación y evaluación de una contraseña y luego salir del ciclo una vez que se ha generado una contraseña que apacigua
cracklib-check
.O al menos sugeriría actualizar a una versión más nueva que incluya las soluciones que @maxwing menciona en su respuesta.
Alternativas de contraseña de generación
pwgenTambién agregaré que generalmente uso
urandompwgen
para generar contraseñas. Eso podría ser útil para usted aquí también.También puede utilizar un poco de magia con secuencias de comandos
tr
,/dev/urandom
yfold
para obtener una contraseña aleatoria de muy alta calidad.El
fold
comando puede controlar la longitud. Como alternativa, también puedes hacer esto:fuente
Tm7U:n=@*+4$*gf$6hOngEHJ;mnh$+R6
está perfectamente bien en la misma máquina.