¡Eran otros tiempos! Hace 10 años cualquier red social era más informal y distendida de lo que son ahora. Los trolleos eran simpáticos, se captaban las ironías, etc. Había que venir llorado de casa . Y las disputas más salvajes se solventaban en las quedadas, ¿recuerdas?
Ha cambiado mucho. Las redes sociales se usan para ofenderse, nadie entiende el sarcasmo ni el humor negro, y los trolleos "benignos" han degenerado en campañas de acoso y boicot. La autocensura limita la difusión de ideas controvertidas...
Menéame ya no es lo que era (de hecho, Menéame nunca fue lo que era)
Irrelevante será si es una noticia, no creo que se pueda votar irrelevante a un envío de este estilo... Si no te gusta no se vota. Pero 4 en tan poco tiempo y nada más salir?
@Omoloc@ElUltimoMono tampoco debería ser vetar o incluir en la ecuación de karma para que suban más despacio las que están penalizadas. Podría ser simplemente un anuncio "esta fuente suele ser controvertida y sus noticias suelen ser tachas por la comunidad como sensacionalistas o erróneas".
@ElUltimoMono Se podrían medir los votos erróneos que esos te aseguras que si es que la noticia está mal, sensacionalista o irrelevante es más subjetivo
@ElUltimoMono No sé si sería bueno, hay muchas webs que reciben negativos por otras cosas que no sea credibilidad, por ejemplo si una noticia va en contra de la opinión mayoritaria de meneame, aunque sea veraz, tendrá muchos votos negativos e incluso puede ser descartada, y hay muchos ejemplo.
En cambio penalizar fuentes que se haya comprobado que han metido hoax o sensacionalismo contrastado etc. sería más correcto, y más difícil.
@anacard@gallir
> El segundo salt podría estar incrustado directamente en el código fuente (mala práctica) o tomarse a partir de archivos de configuración
- el salt tiene que ser distinto para cada usuario, o no funciona. Si usas el mismo salt, es contraproducente.
- si tienen acceso a tu db de usuarios puedes asumir que también tienen acceso a la app. El código fuente, o la config, estarán en memoria.
> Seguramente en rendimiento no merece la pena, pero quería plantear el escenario de que el atacante sólo tuviera acceso a una parte del salt.
El salt es algo público, casi por definición. La idea es que el hash y el salt son públicos y conocidos, mientras que el password es secreto y es (casi)imposible de deducir a partir del hash y el salt.
@anacard@gallir sobre guardar el salt en otra db. Cuantos más factores añadas, mejor. Pero:
- Desventaja 1: No añade seguridad.
Se asume que alguien que ha accedido a tu base de datos de contraseñas también tiene acceso a esa otra base de datos externa. La dificultad de romper las claves es la misma, por lo que la ventaja 1 desaparece.
Idem para sistemas que calculan otro factor "secreto" a partir de los datos de usuario (base64 del email, md5 de la fecha de creación, etc). Se asume que el código se filtra.
- Desventaja 2: Rendimiento y complejidad.
Si para validar cada usuario tienes que acceder y cruzar datos de varios sitios, el rendimiento empeora. Si usas un slow hash (PBKDF2), ya es bastante lento como para añadir más pasos.
En todo caso, el artículo se centra en cómo mitigar daños cuando la db de usuarios se ha filtrado. Lo que tú propones es cómo evitar que el atacante se haga con los datos, y sobre ese tema da para otro artículo igual de largo.
¿Soy el único al que le parece que en meneame los votos negativos valen demasiado?
Al menos valen mucho más que los positivos, lo cual no parece muy justo. Con esto se consigue que cosas polémicas les cueste salir en portada aunque tengan muchos positivos.
¡Eran otros tiempos! Hace 10 años cualquier red social era más informal y distendida de lo que son ahora. Los trolleos eran simpáticos, se captaban las ironías, etc. Había que venir llorado de casa . Y las disputas más salvajes se solventaban en las quedadas, ¿recuerdas?
Ha cambiado mucho. Las redes sociales se usan para ofenderse, nadie entiende el sarcasmo ni el humor negro, y los trolleos "benignos" han degenerado en campañas de acoso y boicot. La autocensura limita la difusión de ideas controvertidas...
Menéame ya no es lo que era (de hecho, Menéame nunca fue lo que era)
Con todas las que salían cuando el Maidan, y ahora que hay una "casi" guerra en Europa...
www.meneame.net/story/15-castillos-escocia-sentirse-autentico-highland
Irrelevante será si es una noticia, no creo que se pueda votar irrelevante a un envío de este estilo... Si no te gusta no se vota. Pero 4 en tan poco tiempo y nada más salir?
Aunque daría para demasiadas coñas.
En cambio penalizar fuentes que se haya comprobado que han metido hoax o sensacionalismo contrastado etc. sería más correcto, y más difícil.
> El segundo salt podría estar incrustado directamente en el código fuente (mala práctica) o tomarse a partir de archivos de configuración
- el salt tiene que ser distinto para cada usuario, o no funciona. Si usas el mismo salt, es contraproducente.
- si tienen acceso a tu db de usuarios puedes asumir que también tienen acceso a la app. El código fuente, o la config, estarán en memoria.
> Seguramente en rendimiento no merece la pena, pero quería plantear el escenario de que el atacante sólo tuviera acceso a una parte del salt.
El salt es algo público, casi por definición. La idea es que el hash y el salt son públicos y conocidos, mientras que el password es secreto y es (casi)imposible de deducir a partir del hash y el salt.
- Desventaja 1: No añade seguridad.
Se asume que alguien que ha accedido a tu base de datos de contraseñas también tiene acceso a esa otra base de datos externa. La dificultad de romper las claves es la misma, por lo que la ventaja 1 desaparece.
Idem para sistemas que calculan otro factor "secreto" a partir de los datos de usuario (base64 del email, md5 de la fecha de creación, etc). Se asume que el código se filtra.
- Desventaja 2: Rendimiento y complejidad.
Si para validar cada usuario tienes que acceder y cruzar datos de varios sitios, el rendimiento empeora. Si usas un slow hash (PBKDF2), ya es bastante lento como para añadir más pasos.
En todo caso, el artículo se centra en cómo mitigar daños cuando la db de usuarios se ha filtrado. Lo que tú propones es cómo evitar que el atacante se haga con los datos, y sobre ese tema da para otro artículo igual de largo.
Al menos valen mucho más que los positivos, lo cual no parece muy justo. Con esto se consigue que cosas polémicas les cueste salir en portada aunque tengan muchos positivos.
¿no?
Venga coño, que ha subido a portada con 80 meneos y dos negativos...
Que parezca esto un sitio serio que nos van a tomar a broma.
Steve Jobs en sus momentos mas gloriosos.