Portada
mis comunidades
otras secciones
![Primera víctima de la colisión de SHA1: El repositorio de WebKit [ENG]](https://cdn.mnmstatic.net/cache/29/ce/media_thumb_2x-link-2739842.jpeg?1487970307)
#25:
#24 Válgame Dios, que mal rayo me parta si en concluyendo este meneo entiendo las raras monsergas de aquestos pitagóricos. ¿No hay mal musa que sópleme luz a la salmodia de raras palabras que veo?
¿ Qué clase de sortilegio digno del sabio Frestón es éste?
!Quédome igual leyendo los comentarios otros que no en leyendo nada!
¿ Qué clase de sortilegio digno del sabio Frestón es éste?
!Quédome igual leyendo los comentarios otros que no en leyendo nada!
#22:
#11 entre otras cosas por sha1
¿Y qué crees que usa Git?
Si creas un blob con el mismo hash que un commit o un tree del repositorio al hacer un push o un clone pasará exactamente lo mismo que en svn: repositorio corrupto.
Yo sin duda prefiero git a svn o hg, pero nunca deja de sorprenderme la cantidad de fanboys de lo que sea que echan pestes sobre otras tecnologías sin saber muy bien por qué.
¿Y qué crees que usa Git?
Si creas un blob con el mismo hash que un commit o un tree del repositorio al hacer un push o un clone pasará exactamente lo mismo que en svn: repositorio corrupto.
Yo sin duda prefiero git a svn o hg, pero nunca deja de sorprenderme la cantidad de fanboys de lo que sea que echan pestes sobre otras tecnologías sin saber muy bien por qué.
#15:
#10 Hombre, tampoco exageres con que limita el trabajo. A la vista está que no si hay gente que ha preferido no cambiar. No digo que si empiezas un proyecto nuevo no uses git, pero si tienes un proyecto perfectamente estable con un montón de programadores que conocen la herramienta y ninguna razón práctica para cambiar...
#36:
En mi empresa tenemos el servidor Git en local, y para alguna colaboración externa usamos github o bitbucket. No es información clasificada, y cualquier cliente que quiera puede conocer esa información (no se me ocurre motivo para ocultarla).Ya he recibido email de un cliente diciendo que acaba de leer que Git no es seguro, que puede corromperse fácilmente y que necesita una alternativa fiable. Ahora mi cliente es experto en software de control de versiones y seguridad.. y hace un mes no sabía lo que era un certificado de seguridad. Acaba de pasar de cliente normal a cliente "cuñadista". Será un día largo.. 
#40:
#26 Git no está afectado porque usa SHA1 mas otra información para hacer el hash de los commits. http://marc.info/?l=git&m=148787047422954
#44:
De los comentarios de la noticia, mirad cuál ha sido la razón del problema:
"Looking through the bug comments and commit log, it seems that the person who checked in the two PDF files did so, not to see what happens in SVN, but because he was creating a testcase for Webkit itself to check whether the SHA1 collision issue couldn't be used for cache poisoning. The test presumably used the two PDF files to generate the behavior needed in the test. It seems he just was a bit careless, not realizing that SVN was also susceptible."
O sea, que querían probar si WebKit se vería afectado por los PDFs con el mismo SHA1 en un escenario de "envenenamiento de caché" y los subieron a SVN sin darse cuenta que SVN también se ve afectado por la misma razón corrompiendo el repositorio.
Vamos, me recuerda a cuando los rusos se pusieron a hacer un test a la central nuclear de Chernobil a ver cuanto aguantaba, ya sabéis como acabó todo...
"Looking through the bug comments and commit log, it seems that the person who checked in the two PDF files did so, not to see what happens in SVN, but because he was creating a testcase for Webkit itself to check whether the SHA1 collision issue couldn't be used for cache poisoning. The test presumably used the two PDF files to generate the behavior needed in the test. It seems he just was a bit careless, not realizing that SVN was also susceptible."
O sea, que querían probar si WebKit se vería afectado por los PDFs con el mismo SHA1 en un escenario de "envenenamiento de caché" y los subieron a SVN sin darse cuenta que SVN también se ve afectado por la misma razón corrompiendo el repositorio.
Vamos, me recuerda a cuando los rusos se pusieron a hacer un test a la central nuclear de Chernobil a ver cuanto aguantaba, ya sabéis como acabó todo...
#52:
increible que hoy en día se necesiten tantas cosas y tantos programadores de pacotilla para hacer simplemente mierdas de webs, mierdas de programas en java y mierdas de software hecho a remiendos como Frankestein que petan por todos lados.
Y os quejais que os pagan 800€.
Y os quejais que os pagan 800€.
#23:
Menuda putada. Ahora tienen que comprar otro monitor.
#42:
#14 yo he trabajado con SVN y con Git, y lo que limitaba el trabajo en grupo era Git. En SVN si colisionas con otro tio te enteras al primer commit (y te cagas en todo). En Git podias estar haciendo commit contra tu local y enterarte de que la habias liado mucho mas tarde (y te cagas en todo, mas veces).
A no ser que hagas commit+push, que es como trabajar con SVN y al final es lo que la gente hacia.
A no ser que hagas commit+push, que es como trabajar con SVN y al final es lo que la gente hacia.
#27:
#20 No vaciles, que el que no piensa antes de hablar eres tú.
Es imposible que te bajes un paquete falso del repositorio oficial de Debían, así de claro. Tu ”pueden modificar un archivo” no tiene ningún sentido si no dices quién y cómo, porque el archivo viene de un repositorio oficial y un atacante tiene que modificarlo al vuelo nada menos que en tu disco duro local.
¿Te has comido un virus mágico que hace ”sudo”... en Debian? ¿Has metido en tu fichero ”hosts” un ”man in the middle” que crea colisiones SHA1 bajo demanda a teraflops por segundo? ¿Hay un tío invisible sentado a tu lado que te roba el teclado sin que te dés cuenta? ¿O simplemente eres tonto y tienes publicada la contraseña de tu usuario ”root” para que te peten vía SSH? En cualquiera de esas fantasías un paquete de instalación corrupto sería el menor de tus problemas.
Pero es que además la utilidad del ataque que imaginas es nula y sin consecuencias, porque incluso si pudiera hacerse no conseguirás más que un paquete corrupto sin ningún efecto ¿O te crees que la colisión SHA1 puedes hacerla con el contenido que te dé la gana?
Antes de vacilar tienes que asegurarte de que el ignorante no seas tú, chato.
Es imposible que te bajes un paquete falso del repositorio oficial de Debían, así de claro. Tu ”pueden modificar un archivo” no tiene ningún sentido si no dices quién y cómo, porque el archivo viene de un repositorio oficial y un atacante tiene que modificarlo al vuelo nada menos que en tu disco duro local.
¿Te has comido un virus mágico que hace ”sudo”... en Debian? ¿Has metido en tu fichero ”hosts” un ”man in the middle” que crea colisiones SHA1 bajo demanda a teraflops por segundo? ¿Hay un tío invisible sentado a tu lado que te roba el teclado sin que te dés cuenta? ¿O simplemente eres tonto y tienes publicada la contraseña de tu usuario ”root” para que te peten vía SSH? En cualquiera de esas fantasías un paquete de instalación corrupto sería el menor de tus problemas.
Pero es que además la utilidad del ataque que imaginas es nula y sin consecuencias, porque incluso si pudiera hacerse no conseguirás más que un paquete corrupto sin ningún efecto ¿O te crees que la colisión SHA1 puedes hacerla con el contenido que te dé la gana?
Antes de vacilar tienes que asegurarte de que el ignorante no seas tú, chato.
#29:
#24 Subversión (svn), es un sistema de control de versiones. Se usa en programación para guardar versiones del código. Es un programa que maneja diferentes versiones de los archivos.
Las versiones se guardan en repositorios. Svn usa un repositorio central, en una única máquina, para manejar todas las versiones.
SHA1 es un algoritmo de hash o firma. Hasta ahora, si a un archivo (un conjunto de datos) le aplicabas este algoritmo devolvía un resultado único. Ahora han encontrado que pueden conseguir dos archivos con el mismo resultado.
De este modo, con dos archivos pdf con idéntico hash es posible "corromper" todo un repositorio de miles de archivos.
Las versiones se guardan en repositorios. Svn usa un repositorio central, en una única máquina, para manejar todas las versiones.
SHA1 es un algoritmo de hash o firma. Hasta ahora, si a un archivo (un conjunto de datos) le aplicabas este algoritmo devolvía un resultado único. Ahora han encontrado que pueden conseguir dos archivos con el mismo resultado.
De este modo, con dos archivos pdf con idéntico hash es posible "corromper" todo un repositorio de miles de archivos.
Comentarios
#11 entre otras cosas por sha1
¿Y qué crees que usa Git?
Si creas un blob con el mismo hash que un commit o un tree del repositorio al hacer un push o un clone pasará exactamente lo mismo que en svn: repositorio corrupto.
Yo sin duda prefiero git a svn o hg, pero nunca deja de sorprenderme la cantidad de fanboys de lo que sea que echan pestes sobre otras tecnologías sin saber muy bien por qué.
#26 #22 amigos, calmad vuestros corceles:
https://news.ycombinator.com/item?id=13719368
http://security.stackexchange.com/questions/67920/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer
#35 ¿Y eso qué tiene que ver con lo yo he dicho?
calmad vuestros corceles
#50 yo entiendo en esos enlaces que sí, git usa SHA1, pero de ahí a hacer una catástrofe como lo que han hecho con SVN va un trecho.
Y entiendo que tu crees que no hay tal trecho.
#53 Lo que he dicho es que Git usa SHA-1, respondiendo a un usuario que insinuaba lo contrario y he mostrado un escenario en el que se puede corromper un repositorio con un blob con un hash duplicado.
pero de ahí a hacer una catástrofe como lo que han hecho con SVN va un trecho
#35 O, The news.combinator. Una web donde ha tenido una hostia guapa gracias a un fallo de cookies con Cloudfare.
).
Aviso, vulernabilidad gorda.
Si algún sitio web con cuenta usa cloudflare, cambiad contraseña ya.
Repo github con las vulnerabilidades (joder esto es ridículo
https://github.com/pirate/sites-using-cloudflare
#22 Ñe, te equivocas. En caso de que llegue un objeto con el mismo hash, git se queda con el local y rechaza el nuevo que llega.
Menuda putada. Ahora tienen que comprar otro monitor.
#11 Eso no era un problema real hasta anteayer
#12 El que mi equipo sea un repositorio en si mismo, para mi si que es suficiente para utilizar git hoy por ejemplo.
#13 si no tienes una politica de backups montada en tu equipo, no lo usas solo como SCM y lo tienes detras de un firewall bien administrado, tu equipo no es un repositorio.
Otra cosa es que tu te lo creas.
#39 Me parece que no entendiste lo que, con toda razón, ha dicho #13
#39 Es un repositorio inseguro y atrevido, un repositorio audaz que no le teme a nada, y camina sin mirar atrás, pero un repositorio al fin y al cabo, pardiez...
cc/ #12
En mi empresa tenemos el servidor Git en local, y para alguna colaboración externa usamos github o bitbucket. No es información clasificada, y cualquier cliente que quiera puede conocer esa información (no se me ocurre motivo para ocultarla).Ya he recibido email de un cliente diciendo que acaba de leer que Git no es seguro, que puede corromperse fácilmente y que necesita una alternativa fiable. Ahora mi cliente es experto en software de control de versiones y seguridad.. y hace un mes no sabía lo que era un certificado de seguridad. Acaba de pasar de cliente normal a cliente "cuñadista". Será un día largo..
#36 no, el problema tuyo, es que el cliente es eso, el cliente y siempre va a meter baza... Porque como tu dices muchos responsables de proyectos de los clientes saben lo mismo de las tecnologías que se necesitan como una hormiga de saber como funciona un 747
#43 #36 Me recuerda a un cliente que para acceder a un servicio que mi empresa sirve en https por Internet, nos exige que le montemos una VPN. "Por política de seguridad".
#36 ten la chuleta a mano, por si acaso https://news.ycombinator.com/item?id=13719368
SVN? SVN???
#8 Sí, yo también aluciné.
#8 #9 ¿por qué? Hasta ahora ha funcionado sin problemas y hay muchos proyectos vivos anteriores a git.
#10 Pues entre otras cosas por sha1
#11 Git usa sha1. Git tiene el mismo problema, está afectado.
De todos modos al no ser centralizado como subversión siempre quedará alguna copia sin actualizar.
#26 Git no está afectado porque usa SHA1 mas otra información para hacer el hash de los commits. http://marc.info/?l=git&m=148787047422954
#40 Y además no sobreescribe una versión local si hay colisión, impidiendo que suceda eso incluso sin la información extra. Nuestro amigo Linus el paranoico... Estas son las tonterías que pienso que son tonterías mientras las añado, y que no se van a dar nunca, pero algo dentro de ti no te deja vivir si no las contemplas. Para otras cosas es una mierda, pero en estas ocasiones te alegras de ser un paranoico.
#11 Ejem…
"Git uses SHA-1 hashes internally; this is a problem because SHA-1 is no longer considered secure. Linus Torvalds has responded that the hash was mostly to guard against accidental corruption, and the security a cryptographically secure hash gives was just an accidental side effect, with the main security being signing elsewhere. Nonetheless, the publication of the first SHA-1 collision attack in 2017 prominently mentioned Git as a possible target for attacks."
https://en.wikipedia.org/wiki/Git
#10 Porque limita mucho el trabajo en grupo. No es un sistema distribuido. Y es posible convertir un repositorio svn a git desde hace mucho, conservando todo el historial y demás.
#14 yo he trabajado con SVN y con Git, y lo que limitaba el trabajo en grupo era Git. En SVN si colisionas con otro tio te enteras al primer commit (y te cagas en todo). En Git podias estar haciendo commit contra tu local y enterarte de que la habias liado mucho mas tarde (y te cagas en todo, mas veces).
A no ser que hagas commit+push, que es como trabajar con SVN y al final es lo que la gente hacia.
#42 el clásico workflow"a martillazos". Que cosas.
#45 bueno, si trabajas con gente que es mi agil y que piensa que el scm es como el undo es lo que termina pasando
#46 si trabajas con gente así... Lo mejor es cambiar de trabajo
#73 yo mas bien administraba, asi que me limitaba a ver como sufrian.
#42 No conocías la integración continua? Vas a hacer llorar a Martin Fowler
#61 #67 y eso que tiene que ver? La integracion continua es lo que pasa despues del commit (o el push). Si usas git, haces 50 commits a tu repositorio local (en tu rama, en 'miBrach45' o en el que sea) y despues haces push a la rama que compartes con otro, puedes tener colisiones (50 acumuladas) independientemente de que despues tengas un jenkis tirando test (y el resto de la parafrenalia) o lo metas en un tar y lo mandes por correo a producción. Si trabajas aislado de lis demas, te pisas con ellos sin darte cuenta hasta que te mezclas. Hags lo que hagas.
#67 y #86 y el dia de release, cuando tu y tus 50 compañeros hagais todos el merge a release, o el dia anterior cuando todos hagais el merge a develop, te encontraras con que es un "marica el ultimo" porque todo el mundo tendra colisiones co otros 6 o 7. De los 60 ficheros que has cambiado en tu rama, 43 coinciden con los que han cambiado otros miembros, asi que tendras que hacer 43 merges si eres el ultimo en mergear. A quien madruga dios le ayuda.
#72 toda la razon del mundo. Cuanto mas aislado, peor, y tener tu propio repositorio te aisla mas.
#91 y el dia de release, cuando tu y tus 50 compañeros hagais todos el merge a release, o el dia anterior cuando todos hagais el merge a develop, te encontraras con que es un "marica el ultimo" porque todo el mundo tendra colisiones co otros 6 o 7. De los 60 ficheros que has cambiado en tu rama, 43 coinciden con los que han cambiado otros miembros, asi que tendras que hacer 43 merges si eres el ultimo en mergear. A quien madruga dios le ayuda.
Sigue siendo lo mismo, no saber trabajar en equipo y planificar mal los releases, proyectos con más desarrolladores y con más lineas de código cambiadas al día funcionan a la perfección con Git.
#102 #91 #99 si vives solo la cosa sale como en el papel, bien. Pero si tu feature, que desarrollas tu solito en tu rama sin que nadie te moleste, toca 32 ficheros que tambien ha tocado tu colega, que tambien ha desarrollado en su rama sin que nadie le moleste, teneis que hacer un merge de 32 ficheros como que Lobezno mola mas que Linterna Verde, y eso es igual de jodido tanto si usas git como si usas svn. Solo puede ser peor si lo haces con el vi.
Como estas en tu propia rama no te enteras de lo que pasa fuera de tu rama, y como no has terminado no puedes hacer merges continuos con la rama pricipal sin joderla (el señor Fowler no hace muchas cosa fuera de una puzarra, y esas lo aguantan todo).
A ver, si sacamos las ramas a pasear, da igual usar svn o git porque trabajas sin que lo s denas interfieran contigo. Solo notas la diferencia del tiempo del commit porque cambias el acceso a red pir el acceso a disco, pero nada mas. Y si no ysas ramas o compartes la rama, git te hace aislarte de los demas si no haces un commit+push, que es trabajar como en svn, con lo que tardas mas en integrarte con los demas (y Fowler te afeara energicamente tu discola conducta) .
Lo jodido son las colisiones y los merges, y esas te las comes igual uses lo que uses porque el problema es inherente al dsarrollo en equipo.
Miraros el video en el que Linus presenta git, sobre todo el momento en el que reconoce que dentro de una empresa, con una buena red asegurada, se puede trabajar con svn. El kernel necesita un scm distribuido porque, como son voluntarios, no se puede asegurar que todos tengan siempre red o pagar el ancho de banda que requiere que todos los voluntarios del planeta accedan al mismo servidor, pero me estrañaria que nadie de meneame tenga esos problemas, la verdad.
Pero podeis engañaros y pensar que con la metodología de moda todo ira bien... dentro de cinco años os apuntareis a la nueva moda y despreciareis lo que haceis hoy.
#91 La integración continua no es tener un jenkins detrás. Integración continua es básicamente una filosofía de trabajo cuya base radica en la "recomendación" de que el trabajo de todos se integre lo antes posible, por ejemplo a diario. Esa "integración" debe resultar en que todo debe compilar y funcionar en otra maquina que no sea la local, de ahí que sea buena practica apoyarse en servidores que verifiquen esa integración, que se hagan tests y demás.
https://www.martinfowler.com/articles/continuousIntegration.html
Se puede utilizar GIT o SVN y no integrar el trabajo de todos de forma continua y es un caos. La gracia es que GIT simplifica enormemente esa forma de colaborar en equipo pudiendo trabajar en una rama aislada sin que nadie te pise tu trabajo y luego mergear fácilmente a la rama de integración. Esto en SVN pues es basicamente un dolor de huevos.
#91 si haces merges cuando terminas la nueva feature a la rama de integración, no debería pasar eso nunca, ya que no modificas todo el código cuando quieres añadir algo, y si esa es la tónica, tal vez deberíais pensar en hacer un refactor
#42 crea ramas por feature o bug, luego merge a develop, y el día de release de develop a master. Te aseguro que te ahorras un montón de problemas
#42 Como se dice en todas partes: un gestor de versiones no sustituye a la comunicación entre programadores.
#42 Eso es lo que se conoce popularmente como no saber trabajar con un sistema de control de versiones, o trabajar con git como si fuese subversion. Hay que aprender a usar branches y merges, eso es todo.
#42 Git te permite trabajar como SVN si quieres, pero al contrario no es cierto.
Y salvo que el código se ponga en común una vez cada cuatro años, no debería ser tampoco un problema ver dónde están los conflictos y arreglarlo.
Yo he trabajado con los dos, y me sigo quedando con git.
#10 Hombre, tampoco exageres con que limita el trabajo. A la vista está que no si hay gente que ha preferido no cambiar. No digo que si empiezas un proyecto nuevo no uses git, pero si tienes un proyecto perfectamente estable con un montón de programadores que conocen la herramienta y ninguna razón práctica para cambiar...
#8 ¿Cual es el problema? Svn mueve proyectos muy grandes.
#65 ¿Has usado git o mercurial?
Te cambia la manera de trabajar especialmente en proyectos grandes.
#80 uso git, he usado cvs, svn y sourcesafe.
Un repo es un repo, nada más. No veo problema en usar un svn, ni entiendo echarse las manos a la cabeza.
#94 No jodas, y un editor es un editor así que todo el mundo a usar notepad (eso sin entrar en que tendemos a usar IDEs).
Espero que no los hayas usado todos igual.
Git tiene un sistema de ramas muy superior )los merges, los rebase, la creación y borrado, las ramas locales) , squashing de commits, poder hacer commits parciales de ficheros diferenciando entre git add y git commit y haciendo stash de los cambios que querias mantener...
Esto es de cabeza.
Git es mucho más flexible y potente, lo puedes usar como subversion, pero es un desperdicio.
#96 He trabajado en equipos que se preocupaban muchas más del workflow de git que de la calidad del código que escribían. La clásica discusión de merge versus rebases, o repos compartidos versus fork de repos y pull requests, en equipos de 3 personas, incluso cosas más raras.
Al final, svn o git solo son herramientas, y svn no es mala. Su concepto de servidor centralizado es el que acaban copiando el 90% de los equipos que usan git.
Un gran repo de svn, por ejemplo, el de WordPress.
#96 No te olvides del git blame ... El favorito del project manager
#96 Eso me parece excusas para no intentar hacer las cosas de la mejor manera posible.
Estoy convencido de que muchos equipos usan git como usan Subversion, pero incluso en proyectos y equipos pequeños las posibilidades de git para editar commits y ramas locales sin coste, son muy útiles.
A mí no me ha pasado que el workflow de git nos haya generado más trabajo que resuelto. Al principio la transición, puede costar si no hay nadie que lo entienda. Aparte de que git no impone un workflow.
#114 eso también existe en svn, y los desarrolladores. también lo usamos para cotillear y podernos verdes.
Corrutos que son unos corrutos
#3 ¡SVN es corrupción!
#18 cvs es la luz. Nunca debimos apartarnos de OpenBSd.
Pues es una gran putada muy grande y mucha gente puede tener vulnerabilidades por esto.
#5 Sí... cualquiera con permisos de escritura en un SVN la puede liar en 30 segundos. Poca broma, desde luego.
#6 y quién da a cualquiera permisos de escritura a su repositorio? :roto2:
#5 Preveo una oleada de caos y destrucción que va a durar meses. La gente es muy puta cuando ve la más mínima ocasión de tocar los cojones porque sí.
#19 una huelga en el sector ahora y el primer día jodemodes el repositorio.
La culpa fué del Shá Shá Shá....
De los comentarios de la noticia, mirad cuál ha sido la razón del problema:
"Looking through the bug comments and commit log, it seems that the person who checked in the two PDF files did so, not to see what happens in SVN, but because he was creating a testcase for Webkit itself to check whether the SHA1 collision issue couldn't be used for cache poisoning. The test presumably used the two PDF files to generate the behavior needed in the test. It seems he just was a bit careless, not realizing that SVN was also susceptible."
O sea, que querían probar si WebKit se vería afectado por los PDFs con el mismo SHA1 en un escenario de "envenenamiento de caché" y los subieron a SVN sin darse cuenta que SVN también se ve afectado por la misma razón corrompiendo el repositorio.
Vamos, me recuerda a cuando los rusos se pusieron a hacer un test a la central nuclear de Chernobil a ver cuanto aguantaba, ya sabéis como acabó todo...
#58 la mejor solución sería usar SHA256.
Es un pregunta interesante. Yo entiendo que si es fácil encontrar una colisión en ambos por separado (provocada, como parece que es este caso, ver #44), también podría serlo encontrar una colisión en ambos a la vez.
(a ver si alguien con más conocimientos nos responde)
#20 No vaciles, que el que no piensa antes de hablar eres tú.
Es imposible que te bajes un paquete falso del repositorio oficial de Debían, así de claro. Tu ”pueden modificar un archivo” no tiene ningún sentido si no dices quién y cómo, porque el archivo viene de un repositorio oficial y un atacante tiene que modificarlo al vuelo nada menos que en tu disco duro local.
¿Te has comido un virus mágico que hace ”sudo”... en Debian? ¿Has metido en tu fichero ”hosts” un ”man in the middle” que crea colisiones SHA1 bajo demanda a teraflops por segundo? ¿Hay un tío invisible sentado a tu lado que te roba el teclado sin que te dés cuenta? ¿O simplemente eres tonto y tienes publicada la contraseña de tu usuario ”root” para que te peten vía SSH? En cualquiera de esas fantasías un paquete de instalación corrupto sería el menor de tus problemas.
Pero es que además la utilidad del ataque que imaginas es nula y sin consecuencias, porque incluso si pudiera hacerse no conseguirás más que un paquete corrupto sin ningún efecto ¿O te crees que la colisión SHA1 puedes hacerla con el contenido que te dé la gana?
Antes de vacilar tienes que asegurarte de que el ignorante no seas tú, chato.
#20 Por supuesto en #27 donde digo SHA1 aplica para MD5, que me he confundido con el tema del meneo.
Si el ”hash” MD5 lleva roto desde hace más de diez años y sigue usándose para ”checksums” es por algo, listillo. Para usar como identificador no sirve, pero para muchas otras cosas sí.
#27 no te enteras de lo que te digo y la peña te vota positivo.
Esto es meneame!!!
#16 #27 Menudo montón de gilipolleces, con perdón.
Para no tener ni puta idea, ni siquiera para entender lo que te están diciendo, te pones demasiado digno, ¿no?
#16 Esos envases para plátanos no son buenos.
#17 Sí son buenos, no puedes colar un envase roto en la balda de plátanos.
#20 Daría igual que lo hiciese, pues cada envase trae su pegatina infalsificable, el problema es verificar la autenticidad de cada plátano. Piensa un poco.
#27 No vaciles, ignorante, que manzanas traigo --dijo con mucha chulería mientras sostenía un envase con peras--.
#121 Para no entender ni lo que te dicen, te pones muy digno.
#122 Estás rebatiendo sin aportar argumentos, tonto.
Qué PATÉTICO, PENOSO y LAMENTABLE eres...
#123 Resumiendo, que tú tampoco entiendes una mierda de lo que he explicado en #27. Sobre la inviolabilidad de los plátanos en la nevera, concretamente.
Sólo eres un faltón pretendiendo aparentar sabihondez, y ni eso consigues.
No te preocupes, ya estaba bastante claro que tú tampoco piensas.
increible que hoy en día se necesiten tantas cosas y tantos programadores de pacotilla para hacer simplemente mierdas de webs, mierdas de programas en java y mierdas de software hecho a remiendos como Frankestein que petan por todos lados.
Y os quejais que os pagan 800€.
#52 sin repos, sin editor de textos y sin entorno gráfico, te haces un google en 2 días no? además solo, para que mas gente ...
#69 Con mariposas, como los programadores de verdad.
A menos que utilices Emacs, entonces: C-x M-c M-butterfly
https://www.xkcd.com/378/
#52 Va, no te quejes: sin esos programadores de pacotilla que hacen mierdas de webs no podrías venir a trolear…
Jajajajajajajajajajajajajajajajajajajaaaaaaaaaaaaaaaaaaaaaajajajajajajajajajajaaaaaaaaaaaaaaaa
#0 Corrumpió?
#2 Arreglado, gracias.
Mi profesor la semana pasada nos decía en clase que la posibilidad de una colisión era tan minúscula que por eso esa seguro
Que se prepare el lunes ajjaja
#32 ¿estas colisiones no serían casi imposibles si además del hash se usara el tamaño del archivo en la comprobación? Tiene que ser prácticamente imposible hacer 2 ficheros o conjunto de datos del mismo tamaño y con el mismo hash
#34 Los PDFs que han generado tienen exactamente el mismo tamaño
#47 entonces me callo. Creía que sería bastante difícil hacer 2 hashes iguales y con el mismo tamaño de fichero.
#49 Es difícil de hacer a fuerza bruta.
Hay 3 niveles de seguridad en un algoritmo hash. El más difícil es: dado un fichero con un cierto hash, crear otro que tenga el mismo hash, que es lo que se ha conseguido ahora. Pero no a fuerza bruta, sino aprovechando debilidades en el algoritmo que no son evidentes y que ha costado muchos años investigar.
(Disculpa el negativo... el cambio de iconos del interfaz me ha jugado una mala pasada)
#32 Yo les dije a mis alumnos que la probabilidad de una colisión era minúscula, pero que MD5 y SHA-1 se consideraban inseguros y era mejor no usarlos, porque tarde o temprano se iban a encontrar colisiones. Y precisamente ayer, según me enteré de la noticia, lo mostré en clase.
Que curioso, hace dos días, Google, que desarrolla Blink, competencia de Webkit, informa de que han han conseguido romper SHA1 y hoy aparece esto.
¿alguien puede explicar el problema en mundano? Porque he entendido bien poco de todo este asunto desde que salió ayer.
#24 Válgame Dios, que mal rayo me parta si en concluyendo este meneo entiendo las raras monsergas de aquestos pitagóricos. ¿No hay mal musa que sópleme luz a la salmodia de raras palabras que veo?
¿ Qué clase de sortilegio digno del sabio Frestón es éste?
!Quédome igual leyendo los comentarios otros que no en leyendo nada!
#25 Mas no temáis, si presto otras meneatrices se lanzaren a desfacer los entuertos.
#33 Oigate dios, gongorilla.
#79 Es correcto, pero creo que te has pasado de complejo. Para un profano es mejor algún ejemplo más sencillo ( lo intento, que no es fácil ):
Imaginemos que todas las tarjetas de crédito, al pasarlas por un lector de pago del berska ( o como coños se escriba ) aplican un método matemático al número de la tarjeta y lo envían al banco.
Si dos tarjetas distintas, al pasarla por el método matemático, dan el mismo número, tenemos un problema, y estamos pagando con la pasta de otro. ( En este caso, el banco, y el otro, tienen un problema ).
Esto se aplica en este caso al código que envían los programadores a 'la central' de su programa, donde el código de todos se mezcla para dar el resultado final. El problema aquí es que dos 'códigos' distintos dan el mismo resultado, haciendo que 'la central' se vuelva loca.
cc/ #24, ah y cc también a Góngora: #25, sean los hados propicios tal que aquestos ditirambos iluminen la savia de su mente y compartamos su grandeza entrambos.
#24 Subversión (svn), es un sistema de control de versiones. Se usa en programación para guardar versiones del código. Es un programa que maneja diferentes versiones de los archivos.
Las versiones se guardan en repositorios. Svn usa un repositorio central, en una única máquina, para manejar todas las versiones.
SHA1 es un algoritmo de hash o firma. Hasta ahora, si a un archivo (un conjunto de datos) le aplicabas este algoritmo devolvía un resultado único. Ahora han encontrado que pueden conseguir dos archivos con el mismo resultado.
De este modo, con dos archivos pdf con idéntico hash es posible "corromper" todo un repositorio de miles de archivos.
#29 "Hasta ahora, si a un archivo (un conjunto de datos) le aplicabas este algoritmo devolvía un resultado único."
Los hash nunca son únicos. Cualquier hash del tamaño que sea tiene repeticiones cuando la cantidad de bits sobre los que aplicas la operación es mayor a la del hash.
Si la distribución es perfecta, para un hash de 160bits tendrías 2 repeticiones al aplicarlo sobre 161 bits y crecería de forma exponencial por cada bit que aumentes.
"Ahora han encontrado que pueden conseguir dos archivos con el mismo resultado."
Lo que han encontrado es una forma para generar es colisiones de forma simple y en un tiempo aceptable.
#24 Básicamente se puede explicar así:
Imagínate que tienes varios trenes de mercancías que van por distintas vías, cada uno de estos trenes siempre sale por una vía distinta (distinto hash). ¿Qué probabilidad hay de que alguno de estos trenes salga por la misma vía que otro? (colisión de hash). Una colisión de hash se produce cuando dos entradas o dos valores aleatorios a partir de una función llamada de hash, producen la misma salida.
Por ejemplo uno de los trenes lleva madera y el otro lleva carbón (distinto mensaje o distinto contenido), eso sí pasan por el mismo punto de carga (función de hash) y siempre salen por una vía distinta a la de otros. Pero si por cualquier circunstancia salen por la misma vía habrá lo que se llama colisión de hash. Porque teniendo que una función de hash, a partir de una entrada llamémosle x, y una salida z. Tenemos que H (x) = z si llamamos a los dos trenes a y b, Y a las salidas zn (z1,z2,z3,z4...) se dará que...
Por ejemplo:
Si H (a) = z1 y H (b) = z5 -> No hay colisión:
Si H (a) = z3 y H (b) = z122 -> No hay colisión
Pero:
Si H (a) = z17 y H (b) = z17 -> ¡Se ha producido una colisión! y se da que H (a) = H (b) (¡coinciden los hash!)
Y esto anterior es muy grave, porque aunque las colisiones más tarde o más temprano se dan (aunque son miles de millones de valores no dejan de ser finitos y como encima son aleatorios es más fácil que se den). Pués hace que no te puedas fiar de la autenticidad de un contenido.
Esta busqueda anterior, por diferentes formas de encontrar una colisión, se denomina ataque de colsión de hash o ataque de colisiones. El problema es que si dentro de los muchos valores que hay vamos uno a uno desde el menor al mayor tardaríamos muchísimo en encontrar una posible colisión. Imaginemos los cien mil primeros valores, aquí no hay colisión y si vamos del 1 al 100.000 no habrá colisión, pero imaginemos que se produce una colisión entre los valores 100.001 y 4.996.678. Es más fácil encontrar estos valores si los elegimos al azar que si vamos del primero al último. Obviamente estos valores los he resumido, porque son miles de millones.
Generalmente es imposible que H (a) = H (b) (es decir que el hash de a coincida con el de b). Pero si se encuentra una colisión si de dará que H(a) = H(b) y aquí tendremos el problema que explicamos.
Salu2
#79 ¿Y dónde queda el exploit en todo esto? Entiendo por qué es un problema la colisión. No entiendo por qué hay semejante alarma como si fuese el problema de seguridad más grande del 2017.
#85 El problema son los certificados SSL que hay firmados con algoritmos como Sha1. Eso significa que tu puedes pensar que visitas google.es pero en realidad estas viendo una página controlada por externos.
Dentro de poco tanto Chrome como firefox van a dejar de aceptar los certificados sha1 como seguros así que esta via de ataque debería quedar limitada.
#85 Los de subversion todavía se están partiendo, mientras se toman "unas gordas"...
No es el mayor fallo de seguridad, es un fallo que puede afectar en muchos sentidos a muchas páginas, de formas insospechadas. Muchas contraseñas se guardan con sha1, por ejemplo.
Una pregunta muy chorras: ¿comparando el hash SHA1 Y el MD5 no se detectaría la colisión en uno de los dos? Difícilmente el hash de un fichero va a dar colisión por 2 métodos diferentes.
#58: Yo también me planteo eso: ¿Qué pasa si se usan varios métodos diferentes como eMule?
#58 Para eso tienes que almacenar ambos, algo que parece no hace subversion.
Me pregunto si google habra publicado la vulnerabilidad a posta para que la peña se pase a blink.
Me sorprende que nadie haya comentado que los repositorios de Wordpress están en Subversion.
#51
Dificultad ninguna. Creas tu programa y le añades lo que sea para tener el mismo hash.
Y claro, estos pdf los habrá subido alguien con esa intencionalidad, si no, como es que no se habia dado esta casualidad antes.
Toca workaround primero y parcheo cuando sea.
#90: Pero yo hablo de otra cosa, páginas web con HTML 3.0 porque su autor la hizo y no tiene tiempo para actualizarlo. Muchas de ellas no cargan lento, porque están bien hechas, sólo que para un estándar "antiguo", y es que lo del "deprecated" es una falta de respeto al trabajo de la gente. Supone tirar su trabajo a la basura.
#92 Disculpa, te entendí mal.
Yo creo que la mayor complicación a la hora de mantener los navegadores más que de esas web HTML 3.0 que mencionas viene de la enorme maraña de código ineficiente e inaccesible en la que se ha convertido el 99% de la web, siendo un buen ejemplo el framework jQuery. Yo suelo navegar sin Javascript porque el navegador se ralentiza y a veces incluso se cuelga.
La antítesis de esta librería es la recientemente publicada elementalsjs.com que, sin pretender cambiar el comportamiento de Javascript, aporta una serie de funciones para trabajar de forma más limpia.
Hoy día la web no suele cumplir ninguna recomendación de accesibilidad de la WCAG, y las personas con discapacidad cada vez encuentran más difícil encontrar información.
#95 En eso si te doy la razón, que cada vez es más difícil encontrar una página web que sea el código, algo de estilo CSS, algo de JavaScript y punto.
Parece que si una página web no ocupa 200 mb de RAM no está bien hecha.
El MD5 en 30 segundos con un móvil no está nada mal.
Los paquetes Debian vienen con el MD5. Pocos hay con SHA256.
#16 Ya sólo te falta colar un paquete de instalación coherente en el repositorio oficial de Debian y lo tienes. Chupado, vamos.
Pensad un poquito antes de poneros paranoicos viendo vulnerabilidades hasta donde no la hay. Los ”hashes” utilizados simplemente como ”checksum” siguen siendo seguros.
#17
No, porque los paquetes vienen firmados con PGP.
Los hashes de checksum no son seguros para comprobar archivos modificados en tu sistema de archivos. Pueden modificar un archivo de manera que obtenga el mismo checksum que el que venga en el paquete Debian. Piensa un poquito antes de responder.
#20 "Pueden modificar un archivo de manera que obtenga el mismo checksum que el que venga en el paquete Debian".
¿Es computacionalmente viable hacer una ataque de preimagen al MD5?
#21 Aun recuerdo cuando se publicó este pequeño experimento con MD5, hace 8 años ya...
https://rdos.wordpress.com/2009/02/23/usando-la-bola-de-crital-y-el-md5-para-predecir-los-numeros-de-la-loteria/
#57 ¡Muy interesante! ¡Gracias por el enlace!
Estoy leyendo cómo se puede hacer eso aquí -> http://www.kachakil.com/retos/S21_Reto_7.pdf .
La técnica usada para hacer eso, sin embargo, no serviría para manipular un paquete Debian. La clave está en que en lo de la lotería tienes el control de todos los archivos que quieres que colisionen, así que los puedes diseñar de tal forma que la colisión exista. En el caso del paquete Debian, uno de los ficheros es como es, y lo que buscas es diseñar otro que tenga exactamente el mismo hash. El hecho de sólo poder cambiar uno de los ficheros cambia la cosa muchísimo...
#59 En su día leí a alguien que estuvo una semana depurando un programa y al final el problema era que había una colisión que estaba haciendo que una tabla hash devolviera un valor incorrecto... ni me imagino la cara que se te tiene que quedar cuando ves eso
#16 yo he visto en mi trabajo 2 ficheros distintos con el mismo hash de md5 aunque no te lo creas. Eso sí la diferencia era un carácter (uno tenia un 0 y otro un 9 en la misma posicion) respecto uno de otro
Y esto fue por el 2007
Cc #17 #20 #21
#20 y ahí está la dificultad, entiendo yo, en que tu cambio tenga el mismo checksum. Si quieres colar un código malicioso por ejemplo, tendrá que ser uno muy concreto...
#129 "Razonamientos técnicos" . Para eso primero tendrías que haber entendido lo que decía #16, #20, etc, pesado ignorante. Por mí te puedes poner a razonar sobre la reproducción de la gallina. Lo que no soporto es a un inútil chulo. No te enteras de qué va la cosa y sigues chulito, y sigues, y sigues. Patético.
#17 No lo digo por la colisión de hash, porque fue otro tema distinto. Pero si pueden pasar cosas como esta:
https://hipertextual.com/2016/02/linux-mint-hackeado
http://blog.linuxmint.com/?p=2994
Pués tampoco es tan conspiranoia que se pueda modificar un paquete en Debian, digo yo.
Salu2
Corred insensatos!, es el fin del mundo. Sha ha muerto.
Ojalá desarrollen un motor para navegadores enfocado en el cumplimiento de estándares en vez de el modelo actual de parche sobre parche para dar soporte a webs frankenstein con HTML incorrecto y nada accesibles.
Afortunadamente sistemas como OpenBSD dejaron SHA1 hace tiempo, usando actualmente SHA256, y haciendo su sistema de alguna forma independiente del algoritmo usado, con lo que futuros cambios no supondrán un excesivo trabajo.
#56: Haz un navegador así y "nadie" querrá usarlo.
Es muy simple, lo que tú llamas "HTML incorrecto y nada accesibles" en su día fue un estándar 100% válido. Puede parecerte muy sencillo llegar y actualizar la página web, pero... ¿Tu crees que todo el mundo tiene tanto tiempo libre como tú? Y eso si no les vuelve a dar por ahí y declaran lo actual como "deprecated", porque si, por fastidiar.
#68 Yo lo usaría, de hecho suelo cerrar rápido cuando una página va lenta. Precisamente me quejo de que no se cumpla el estándar. Ejemplo: usar h2 sin siquiera haber un h1 en el documento. Bootstrap es un buen ejemplo de lo que critico, usando clases para presentación y un montón de código de forma innecesaria para una simple barra de menú.
¿Qué sabes tú del tiempo libre que tengo yo? ¿de qué me conoces?
¿Esto afecta también a contraseñas generadas con SHA1, o solo a los checksum de los ficheros?
#66 si guardas la clave en SHA1 en la db y cuando recibes la request simplemente codificas el string a SHA1 ... podría ser no?