Portada
mis comunidades
otras secciones
#8:
Yo antes usaba siempre "123456", pero como dicen que hay que usar mayúsculas y minúsculas, ahora uso"123456". La seguridad es lo primero.
#10:
En el gráfico es es una farsa están usando un cifrado débil y muy antiguo, tipo MD5.
Una contraseña de 8 caracteres ya se considera segura. No hay que usar contraseñas largas o complejas, es mejor usar un gestor de contraseñas, es inviable escribir una contraseña de 18 caracteres con letras y números
Una contraseña de 8 caracteres ya se considera segura. No hay que usar contraseñas largas o complejas, es mejor usar un gestor de contraseñas, es inviable escribir una contraseña de 18 caracteres con letras y números
#6:
#5 Exacto. Se supone que un cracker se ha llevado las password cifradas. Otro cracker -o él mismo- quiere obtener, -por fuerza bruta, diccionario, basado en reglas, etc. - los originales de esas claves. Esas son las que le permitirían el acceso con el login del usuario afectado. Desde hace unos años nadie guarda las password sin cifrarlas antes. (O no debería...).
Véase: https://es.wikipedia.org/wiki/Hashcat
Véase: https://es.wikipedia.org/wiki/Hashcat
#2:
De que sirve una contraseña de puta madre de esas de 34 años si roban las bases de datos del servicio donde la usabas?
Comentarios
Yo antes usaba siempre "123456", pero como dicen que hay que usar mayúsculas y minúsculas, ahora uso"123456". La seguridad es lo primero.
#8 A mí desde que me lo dijeron siempre uso "mayúsculasyminúsculas", si esa es la contraseña buena pues hay que usarla.
En el gráfico es es una farsa están usando un cifrado débil y muy antiguo, tipo MD5.
Una contraseña de 8 caracteres ya se considera segura. No hay que usar contraseñas largas o complejas, es mejor usar un gestor de contraseñas, es inviable escribir una contraseña de 18 caracteres con letras y números
#10 tal como dices, lo ideal es usar un gestor que genere contraseña seguras para cada uno de los servicios
#10 Una contraseña larga siempre será mejor que una corta, aunque sólo uses minúsculas:
estacontraseñaessegura
#10 M1&C4b4ll0&S3nt4d0
Es súper complicado una contraseña de ese estilo.
#10 Inviable no es.
Yo me he acostumbrado a usar hashpass, generación de contraseñas stateless basadas en nombre, dominio y password maestra. Ni siquiera tiene una base de datos que se pueda llevar un atacante y romper.
#10 Me gustaría ver los números cuando el algoritmo es bcrypt o yescrypt
#55 #58 El salt es para no puedas reutilizar un ataque de fuerza bruta ya hecho (el ataque Rainbow )
Yo entiendo que la velocidad del grafico se corresponde a una iteration y hoy en dia se repite el algoritmo, xmiles de veces. Por ejemplo, para que tu propio ordenador tarde .5seg en comprobarlo.
Asi un ataque de fuerza bruta tambien sera xmiles de veces mas costoso.
En keepass, me sugieres 7 mllones.
#35 Es buena idea, pero los ataques brutos tienen cierta inteligencia estadistica. Pore ejemplo los numeros se suelen poner al principio o final y si van por en medio no suelen romper las silabas.
Las mayusculas tambien suelen ir antes de vocales, inicios de silabas, etc Si no es la primera letras solo.
Supongo que ese patro numerico tambien se computa en los ataques de fuerza bruta.
#54 Yo creo que si todas son palabras de diccionario, no seguro y deberia haber alguna con alguna imperfeccion que no este en el diccionario. Todos los trucos que faciliten memorizar ablandan la contraseña.
Pero me parece que es un buen consejo contraseñas faciles pero largas y apartir de ahi aumentar la dificultad segun las posibilidades de cada uno. Ademas en una pass larga, añadir 1 numero, mayuscula, etc incrementa muchisimio mas las seguridad que en una corta.
#67 Habias una extension y una algoritmo en JS Hashpass y passHashh que hacian eso. Cada una usa un algoritmo difernente y no sirve las de uno para otro. La ha comentado #57
http://hashapass.com/en/index.html
Estaria bien tene el algoritmo para generarlas si falla ese programa.
#44 En la wiki explican el Salt y el ataque Rainbow.
https://en.wikipedia.org/wiki/Salt_(cryptography)
https://en.wikipedia.org/wiki/Rainbow_table
#98 En concreto uso este:
https://github.com/scottparry/hashpass
Corriendo en una máquina que tengo en mi esxi únicamente dedicada a servir este .php, ya que aunque el autor tiene una instancia accesible nunca sabes como de segura es y si la han podido comprometer.
#10 menos mal que alguien lo dice. No tiene sentido depender solo de una clave larga como si se fueran a almacenar con un hash de mierda.
Primero: las claves se deben guardar con una función de derivación de claves como PBKDF2 donde se realizan cientos de pases en cada intento, con lo que los tiempos para realizar un ataque de fuerza bruta se elevan exponencialmente y con 8 caracteres suele ser más que suficiente para que sea inviable buscar una colisión en tiempo. Aparte que estamos hablando de algoritmos para los que no se ha encontrado colisión todavía como sha2
Segundo: el problema de las claves repetidas no son las rainbow tables, son que te metan un maleare en el pc y te roben la clave (un rat, una extensión del navegador, etc) junto con unas credenciales como tu email, porque la gente que reciba esas claves (o quién compre esos datos) probará esa combinación mail/clave en otros servicios, y si usas la misma ya estás jodido.
Tercero: obligar a usar claves de 15 o 20 caracteres a usuarios no solo es inútil por lo mencionado sino que puede ser contraproducente por lo visto en los comentarios anteriores. La gente tiene una memoria limitada así que usa patrones fáciles de deducir , lo cual dado que te van a robar la clave tarde o temprano por otros medios que no sean crackeando un hash (lo dichoz un maleare, o un servicio de.mierda que no cifra las claves etc) es más probable que te roben el resto sacando el patrón o por usar la misma en varios .
Dicho esto, lo que es recomendable es : usar un gestor de contraseñas con una clave robusta, cambiarla periódicamente y el resto de claves generarlas en el gestor (realmente una vez las generas te da igual la longitud, así que ahí si es viable generarlas de la longitud que te de la gana por si algún servicio usa un mal cifrado para almacenarla) y sobre todo, lo más importante hoy en día , *activar el segundo factor en todo lo posible* y si puede ser algo tipo TOTP que se genere localmente mejor, para no depender de factores externos como tú n de teléfono u otras cuentas
De que sirve una contraseña de puta madre de esas de 34 años si roban las bases de datos del servicio donde la usabas?
#2 cada dia hay menos bases de datos con las contraseñas en texto plano.
#3 Dirás que todavía hay demasiadas bases de datos que almacenan las contraseñas en claro.
#22 pues no lo se, de servicios serios pocas creo yo.
#31 Crees, crees. Luego revientan el "servicio serio X", y descubres que sus contraseñas se guardaban en claro.
#47 Pues no se, no recuerdo cuando ha sido la ultima vez que han sacado las contraseñas de uno de los grandes.
#47 porque el pass the hash no existe.
El problema es las contraseñas débiles o fácil de tener en diccionarios personalizados / tablas Rainbow y la falta de 2FA
#55 con salting se evitan los ataques por diccionario.
Hay muchas bases de datos sin salt, pero en texto plano no creo que queden muchas
#3 Sí, pero es un ataque por fuerza bruta, es decir, probando todas las posibles para encontrar la correspondencia con el hash que está guardado en la base de datos
#26 lo que dices no tiene nada que ver con el comentario que respondo, que dice que da igual lo buena que sea la contraseña cuando te la pueden robar.
#30 No te sigo
#26 Mi profesor de criptografía y criptoanálisis sostenía que el ataque por fuerza bruta era el mas efectivo, en concreto, en su modalidad contra del poseedor de la clave
#3 en España si te pillan con una el puro de la AEPD es fino fino. Dudo que ahora mismo haya muchas de esas
#45 En República Dominicana conozco varios casos, como el de Altice, donde las contraseñas están o en texto plano o, a lo sumo, con alguna encriptación simétrica. Lo sé porque cuando indicas que has olvidado la clave, en lugar de iniciar un proceso de resstablecimiento de contraseña para el usuario, te mandan la contraseña actual por email.
#2 no reuses contraseñas en distintos sitios
#2 Aparte de lo de #17 , no te metas en un sitio tan cutre como para que guarden las claves en claro, que los hash en bbdd ya se podian implementar hace 20 años.
#32 Pero muchos se olvidaban del "salarlos", he visto más de una aplicación donde si hacías un
SELECT * from user order by password
veías innumerables filas con el mismo valor
#37 Si, pero con un buen hash tardarán años en sacar una clave (aunque esté repetida), se que no es mucho, pero al menos ya dificulta lo suficiente como para que no merezca la pena.
Yo si quisiera meter un sistema seguro usaría bcrypt para las claves y un segundo factor de autenticación como google authenticator o similares
#41 Si no usan sal, no creo que tardasen más de unos pocos meses en cuanto encuentren un patrón a seguir. Puede que incluso tan sólo unas pocas semanas.
#77 Sin sal un buen algoritmo algoritmo de hash tardas años en romperlo, lo que pasa es que se suele usar el por defecto o los llamados algoritmos rápidos, que están hechos para hacer hash rápido porque tienen que hacerlo a un mensaje dinámico que necesita una respuesta rápida (como una transacción de una tarjeta de crédito)
La sal realmente se usa para evitar los diccionarios, un montonazo de claves comunes y posibles pre calculados en los que solo hay que buscar el hash y te da la clave.
#82 Sin sal se han roto contraseñas complejas con Argon2d en cuestión de meses. No olvidemos que a los ataques por diccionario hoy por hoy se añaden técnicas de aprendizaje de máquina, y estas son cada vez más complejas.
#87 Gracias, viene bien actualizar los conocimientos de seguridad.
#2 Por norma general en la base de datos de un servicio nunca se almacena la contraseña, si no un hash de la contraseña.
En principio, si la contraseña es suficientemente segura, no se puede obtener la contraseña a partir del hash de la contraseña
#68 ok, gracias por la info
#9 Acabas de descubrir el "salt".
#24 acabo de descubrir como se llama, gracias. La verdad es que en tema de encriptacion no estoy muy puesto a nivel técnico. Me limito a agregar a la contraseña un salt personalizado para cada registro y luego a encriptarla con el algoritmo de turno mas robusto (sin posibilidad de desencritarla, claro) y obviamente a incluir en la aplicación de turno sistemas de detección de ataques por fuerza bruta. Lo que ya no se es como funciona por dentro estos algoritmos.
#48 #21 goto #44
#44 Utiliza siempre librerías robustas que ya esté probadas y cuya eficacia esté contrastada. Esas librerías incluirán en su mayoría la generación y adición de la sal. Incluso se puede usar junto a la sal, aunque suene a broma, una "pimienta" que sería un valor fijo para el sitio web que se añade, al igual que la sal, a la contraseña, pero que no se almacena en la base de datos junto al hash y la sal. Esa "pimienta" puede ser perfectamente una cadena binaria muy larga, guardada en la configuración del sitio web, por ejemplo, en un fichero JSON.
Tampoco es del todo cierto por que la mayoría de sistemas de login tienen un anti brute force que hace que tengas un cool down de un rato si fallas la pass más de x veces seguidas, o ban de la IP origen.
#4 Imagino que se referirán a cuando se hackea el servicio o web y tienen acceso a la base de datos encriptada. Ahí puedes emplear fuerza bruta sin problemas.
#5 Exacto. Se supone que un cracker se ha llevado las password cifradas. Otro cracker -o él mismo- quiere obtener, -por fuerza bruta, diccionario, basado en reglas, etc. - los originales de esas claves. Esas son las que le permitirían el acceso con el login del usuario afectado. Desde hace unos años nadie guarda las password sin cifrarlas antes. (O no debería...).
Véase: https://es.wikipedia.org/wiki/Hashcat
#5 Para ello necesitas conocer el sistema de encriptación. Yo siempre recomiendo un doble sistema de encriptación en base de datos (Basta concatenar a la contraseña que el usuario ha escrito unos caracteres al "azar" antes de encriptar la contraseña y registrar la password en base de datos). Asi dos usuarios que usan la misma password en base de datos aparecen textos diferentes. (Hombre si además de tener acceso a la base de datos tiene acceso al código fuente pues estamos igual de jodidos, claro).
#9 Lo que hay que hacer es guardar un hash de la passwd y no guardar la passwd.
Luego se compara el hash de la entrada de login con el hash guardado en base de datos....
#21 Es lo que #9 dice, y dice algo más (y más importante), que es que no debes ni guardar el hash del password a pelo, sino que debes usar un salt para que no puedan usar un dictionary attack / rainbow table.
#9 Si en vez de encriptar (que implica que se puede desencriptar) lo que haces es generar un "hash" criptográfico con un algoritmo bueno, entonces por mucho que tengas acceso a la base de datos y al código fuente no vas a ser capaz de averiguar la contraseña, porque un hash es una operación destructiva, los dueños de la base de datos (o del código) no pueden obtener la contraseña original a partir de ese hash almacenado.
La idea es que cada vez que quieras autentificar al usuario repitas el mismo hashing y lo compares con lo almacenado, sin guardar nunca la contraseña en tu base de datos ni en ningún sitio.
#5 exacto, pero eso NUNCA lo dicen en estos artículos. Para que te peten el password primero tienen que rebentar el sistema de seguridad que protege la base de datos. Es un matiz muy importante y reduce mucho las probabilidades
#4 Deberías cambiar tu nombre de usuario por "milkandcookies" .
#4 me imagino que no conoces open bullet , en donde el mismo aplicativo te va cambiando de proxy con cada request
#4 es lo que salva el pin de las tarjetas de crédito. Con fuerza bruta no tardas ni 1 segundo en sacarlo, pero como sólo tienes 3 intentos es un sistema seguro.
El problema que la mayoría de la gente obvia es que los sistemas de fuerza bruta de décima generación no utilizan secuencias aleatorias para probar contraseñas, sino que utilizan patrones aprendidos por machine learning a partir de filtraciones de datos ya existentes. Así si muchos usuarios utilizan contraseñas con una misma estructura de manera habitual prueban esa misma estructura primero.
Cuando te obligan por narices a poner un número, una mayúscula y un singo de puntuación al final las contraseñas suelen ser bastante semejantes. Es más débil una contraseña que está basada en palabras de diccionario con las sustituciones típicas que una completamente aleatoria. Lo de cambiar números por sus nombres también es relativamente habitual, y es de las primeras cosas que un cracker por fuerza prueba.
Y es que la fuerza bruta ya no es tan bruta, aunque si muy fuerte.
#39 “el hacker “ normalmente es una máquina que no compara passwords entre sitios.
Está claro que no es ideal pero es mejor que tener la misma en todos sitios. En cualquier caso he puesto un patrón sencillo para el ejemplo, pero si tú quieres mirar el dedo… aya tu.
#43 Yo sólo te hacía ver que el ejemplo es malillo. Respecto a que el hacker es un máquina... ya que pones una contraseña ponla bien porque no sabes quién va a ser el hacker (y no me salgas con la falacia del hombre de paja de que es mejor que poner la misma en todos sitios, estamos hablando del ejemplo que has propuesto tú).
Y, lo de poner el dedo, sólo lo pongo apuntándote que se escribe "allá".
#52 El ejemplo que he puesto es "definir un patrón" y he dado un patrón sencillo para que se vea la idea; no he dicho que el patrón elegido por mi sea suficiente o bueno. Pero si hace falta, por gente que tiene un bajo nivel de comprensión de lectura, especificar que NO es ese un buen patrón, en efecto no lo es.
"allá", disculpa. EL móvil no es buen sitio para escribir. Y encima era la mierda de Iphone de empresa, que mi Android está en reparación No sé escribir con él
#69 Pues todo aclarado. Ciertamente es un buen método usar un patrón con parte fija y otra variable para poder recordar diferentes contraseñas.
Y también coincido escribir con el móvil es una lotería
#43 La máquina de la que hablas cuenta con diccionarios de millones de entradas extraídos a lo largo de los años de muchas vulnerabilidades explotadas o directamente de robos de sitios con poca seguridad, y utiliza también aprendizaje de máquina para encontrar patrones.
Una frase corta, en minúsculas, ya rebasa cualquier margen de seguridad. No es necesaeio C0mπłiČäřsę demasiado.
Me acabo de enterar que el tipo de contraseña que llevo usando desde hace años es de las más seguras según esa tabla del artículo, y al menos en mi caso no la elegí por seguridad, sino por mala memoria y exigencias de los sitios donde tuve que crear contraseñas al principio.
Había un sitio donde me exigían que la contraseña tuviese 8 caractéres, otro donde me decían que tenía que incluir al menos un símbolo, un número y una mayúscula y otro donde me pedían que la contraseña fuese única y que no la tuviese en uso en ningún otro lugar.
Teniendo en cuenta que mi memoria es nula y que como todo hijo de vecino me registro en un montón de sitios distintos aunque sólo sea para probar, no me quedó otra que buscar un sistema que me sirviese para todos ellos ¿El resultado? una serie de caractéres fijos y otros generados matemáticamente a partir del nombre del sitio.
Lo bueno es que mientras el sitio no cambie de nombre no tengo que recordar la contraseña, me basta con recordar como generarla, lo malo es que algunas son laaargas como un día sin pan.
Para mi una contraseña normalita, de las cortas tiene al menos 16 caractéres.
#56 Entonces, deberían especificarlo. Tal y como tratan este asunto, da la impresión de que los sistemas, de por si, pueden ser atacados directamente, con estos tiempos.
Estas tablas no tienen mucho sentido. Basicamente, te dicen lo que tarda un ordenador en generarlas y probarlas contra el servicio atacado. Hoy en día es muy difícil encontrar un sistema que te permita más de unos pocos fallos seguidos, sin bloquearte o establecer un cierto tiempo hasta que puedas volver a intentarlo. Estos tiempos habría que sumarlos a los de la tabla.
Siempre que no hayan encontrado un bug, cosa bastante difícil.
#46 Supongo que eso es válido cuando en un ataque roban la BBDD de contraseñas codificadas.
#20 Solo parcialmente, evita embarazos, pero no evita el resto de ETS
#28 Un embarazo no es una ETS, no?
#92 Yo pienso que sí, exactamente un parásito, pero la OMS aún no lo ha reconocido como tal.
Menos mal que un gran médico si sabe diagnosticarlo
#76 estupendo. Puedes recomendar a la gente usar patrones alfanuméricos, aleatorios de 16 cifras y que no sé rwpitan entre páginas.
Seguro que eso hace que cambien sus políticas de contraseñas
#20 Usas proteccion?
#27 tu madre no me ha dicho nada al respecto....
#34 jajaja positivo por las risas
Al final lo que cuenta es hacer una buena contraseña (larga, rara, pero con elementos sencillos) para cada servicio.
Google: LaGranGGuarda15GbDeFotos
Facebook: SeraMejorQueNoMeMetaEnRedesSociales
Instagram: MiMetaEsHacerFotosChulas
Meneame: KarmaKarmaChameneon
Estas son relativamente sencillas de recordar y son suficientemente largas.
Eso de tener que recordar 16 carácteres alfanuméricos sin sentido es un dolor.
#7 Pero si haces eso mejor meter palabros o cosas que no sean muy de diccionario (como en tu ejemplo de KarmaKarma o de 12Gb)... porque con ataques de diccionario se puede sacar incluso más rápido.
Entonces el problema ahora viene al tenerte que acordar que eran 12Gb y no 14, o de si el "Chameneon" era on Ch o con K, si tenía "l"...
Al final lo mejor es tener un gestor de contrasenias.
#12 El "anillo único", un error en su gestión y vendes hasta la camisa.
#12 #14 Ya sé que lo mejor es un gestor de contraseñas, pero hay gente que ni siquiera cree que usar 123456 en TODAS partes sea inseguro, como le metas un gestor de contraseñas se ríen en tu cara. Estas frases son cutres, pero son miles de veces mejores que el típico "pin" de 6 cifras.
#7 Tener que recordar todas las contraseñas es ya un dolor, utilices el método que utilices. La única forma posible de tener contraseñas únicas y seguras es cualquier cosa que no sea memorizarlas.
#7 #14 Una forma que usé en su día, hasta que me cansé, es establecer un patrón en base al sitio, pero que sea fácilmente replicable.
MiPassDeMeneame156
MiPassDeFacebook167
MiPassDeGoogle1459
En Este caso, de patrón sencillo, sería
MiPassDe + [sitio] + [número de caracteres de la contraseña] + [sumatorio de los numeros anteriores].
Es un ejemplo tonto pero solo tienes que recordar un patrón, crea contraseñas seguras y cada contraseña es única. En caso de que tu contraseña sea expuesta, incluso si el patrón es sencillo... no la podrán replicar los bots en distintos sitios. Igual un humano es capaz de replicar el patrón... pues sí. Pero es mejor que nada
#35 Donde MiPassDeGoogle1459 y MiPassDeCalico1459 es el (prácticamente) mismo. Y si además el hacker ha sido administrador de Calico, rápidamente deduce el patrón para todas las cuentas que se le puedan ocurrir que tengas. No sé Rick, dale una vuelta más
#35 Eso implica un patrón, y por lo tanto no es seguro. Incluso estás dando una pista para restringir el rango de números de la contraseña. En el momento en que averigüen una, tendrán todas tus contraseñas para cualquier sitio.
#7 Esas son muy fáciles de crackear, porque son basadas en diccionario. Y, encima, sin reemplazar nada.
Todo lo que es basado en diccionario es muy fácil de crackear. Una contraseña tipo: 9d-D*3 será muchísimo más difícil de crackear que cualquiera de esas.
#15 xkcd opina de una forma diferente.
https://xkcd.com/936/
#54 venía buscando precisamente esto.
#54
* 11 caracteres aleatorios (de un set de 94) tiene log2(94^11) = 72.1 bits de entropia
* 4 palabras aleatorias (de un set de 2048) tiene log2(2048^4) = 44 bits de entropia
El motivo por el que xkcd asigna menos bits de entropia a "Tr0ub4dor&3" es porque en lugar de 11 caracteres aleatorios esta usando palabras con caracteres cambiados seguidos de un número y un signo de puntuación (en orden aleatorio).
Nada de eso se aplicaría si se usasen caracteres aleatorios.
También hay un estudio sobre el tema que desmintió que fuese más sencillo memorizar las palabras aleatorias:
> Contrary to expectations, system-assigned passphrases performed similarly to system-assigned passwords of similar entropy across the usability metrics we examined. Passphrases and passwords were forgotten at similar rates, led to similar levels of user difficulty and annoyance, and were both written down by a majority of participants. However, passphrases took significantly longer for participants to enter, and appear to require error-correction to counteract entry mistakes. Passphrase usability did not seem to increase when we shrunk the dictionary from which words were chosen, reduced the number of words in a passphrase, or allowed users to change the order of words.
https://cups.cs.cmu.edu/soups/2012/proceedings/a7_Shay.pdf
#66 ¿por qué pones que a la hora de elegir palabras hay sólo 2048? El diccionario de la RAE tiene 93.000 palabras diferentes. Me salen 66 bits.
Y hay muchas palabras que no están recogidas en el diccionario de la RAE, dudo que en un ataque de fuerza bruta con diccionario en castellano sólo se eligan 2048 palabras.
Luego, puedo tener dudas que sea sencillo recordar 4 palabras aleatorias. Pero desde luego 11 caracteres aleatorios lo encuentro mucho más complicado. Pero vamos, sin ningún genero de dudas.
#73 Porque el comic dice "four random common words", cuanto más grande el número menos comunes se hacen. 2048 es lo que usan en explain xkcd y en el generador de xkpass.com deben usar algún número no muy diferente pq dicen que tienen 46 bits de entropía.
La idea del comic era pretender que 4 palabras comunes son mejores que 1 palabra poco común ("uncommon") que ha sido tuneada para hacerla más rara aún. Lógicamente mezclar ambos métodos y poner 4 palabras "uncommon" (y de paso mete algúun númerito) va a tener más entropía que cualquiera de los dos métodos originales de los que hablaba el comic.
> 11 caracteres aleatorios lo encuentro mucho más complicado
Es que para tener una entropía equivalente a esas 4 palabras se necesitarían menos de 11 caractéres.
De todas formas todo es cuestión de usar buenas asociaciones mnemotécticas. A mi me autogeneraron en la universidad una clave de caracteres aleatorios y hasta la fecha la sigo recordando.
De todas formas la idea es usar gestores de contrasenias o sistemas de derivación de clave.
#74 Yo veo menos seguro usar siempre la misma contraseña, por segura que sea.
Y veo mucho más fácil recordar 4 palabras normales que recordar 11 caracteres aleatorios. Obviamente, es más fácil recordar una palabra rara y larga con modificaciones para hacerla menos común, pero entonces la entropía vuelve a bajar.
yo el problema que veo a usar 4 palabras es que no te suelen permitir contrasñas tan largas. Además que te exigen poner números y a veces caracteres especiales, con lo que ya complican las cosas
#78 No he dicho que haya que usar siempre la misma contraseña. Sólo digo que la clave aleatoria que usaba en mi uni la sigo recordando, después de 15 años. Y antes solía usar derivaciones de ella. Pero yo hoy dia lo que uso es un gestor de contraseñas (KeepassXC).
Y es cierto que hay muchos sitios donde ponen limitaciones absurdas a la longitud de las contraseñas, eso me da mucha rabia.... esos casos siempre me hacen sospechar que lo que almacenan seguramente no sea un hash, sino la contraseña completa y que por eso tienen límites de espacio.
#66 Y de todas formas incluso con las 93000 palabras de la RAE seguiría no llegando a los 72.1 bits:
log2(93000^4) = 66.02
#15 Una contraseña basada en diccionario no es una contraseña basada en palabras, son cosas algo distintas.
Un diccionario tiene palabras únicas, sueltas. Si haces una frase con 7 palabras el que la quiera crackear necesitará hacer combinaciones de 7 palabras...
En el diccionario español hay 50.000 entradas. De ellas "habituales" digamos que son solamente 2000.
Combinaciones de 7 palabras = 2000^7 = 128x10^21 (si es fuerza bruta la contraseña es tan larga que ni hace falta tenerlo en cuenta)
En cambio combinaciones de 12 caracteres alfanuméricos (mayúsculas, minúsculas, números) = 66^16 = 6x10^21
7 palabras formando una frase mas o menos coherente son tremendamente mas fáciles de recordar que 12 letras y números al azar... y mas o menos igual de seguras.
#7 Pones una parte fija al principio
Parte anterior: "Pr3"
Luego aplicas una regla al servicio que corresponda: tipo coges todas las vocales y las doblas y luego solo las consonantes
Google : Pr3ooeooeGl
Amazon: Pr3AaoAaomzn
Facebook: Pr3aeooaeooFcbk
#7 lo ideal es un sistema de gestión de contraseñas que controles tu (por ejemplo keepass) con una contraseña robusta (la mía es una frase de más de 20 caracteres).
En keepass generas para cada servicio una clave aleatoria. Lo usual que hago es una de 20 caracteres con minusculas, mayusculas, números y algunos caracteres especiales. Total no la tienes que recordar. Las contraseñas de servicios críticos (por ejemplo, gmail, aún más largas)
Con eso solo tienes que recordar una contraseña y luego generar todas distintas. El fichero de keepass lo tengo en Google Drive sincronizado entre mis equipos y mi móvil.
#50 yo tengo mi propio programa encriptador de texto, programado por mí,
sin usar ninguna librería externa en el proceso de encriptado y desencriptado. No me fío de ninguno comercial (como keepass), doy por hecho que ciertos gobiernos tienen backdoors a los mismos. Guardo mis contraseñas encriptadas con MI encriptador. Y la del propio encriptador, en mi cabeza.
#61 keepass es open source. Puede haber un backdoor, pero es tan fácil que lo haya en Keepass como en las librerías que uses tú para cifrar. Al final nadie implementa AES desde 0, en Java usarás las de java.security que vienen en el lenguaje o las de BouncyCastleEncryption
#50 Yo también tengo keepass, pero a los que les cuesta esto de las contraseñas y siguen creyendo que 123456 es suficiente... no les pidas gestionar la sincronización del Keepass en algún servicio en la nube. Y si les dices que solo lo podrás consultar cuando estés en casa... te dicen que te vayas a la porra
Falso, tengo ahora mismo John (que es más lento que hashcat) con una gráfica Nvidia en un portátil y 14 a 16 caracteres ASCII imprimibles son solo dos semanas. (NTLM)
#23 ntlm creo que tiene rainbow tables disponibles para ese rango, puedes mejorar ese tiempo.
#23 LM si. Bueno es que el máximo soportado son 8 caracteres, y para 16 lo que hace Windows es cobrar los 8 primeros y luego los 8 siguientes. Pero NT no hay rtables con tantos caracteres.
letras y números con mayúscula y minúscula, 12 caracteres, 200 años. Me basta.
18 caracteres es muy poco. Parece mucho si lo tienes que teclear, pero nunca hay que hacer eso.
La "Ñ" cuenta como letra o como caracter especial?
#1 Especial, mira su codigo ascii.
#16 entonces 6969 no es segura?
Me parece más coherente lo que dice KXCD para el común de los mortales
https://xkcd.com/936/