@Jagüi Si necesitas ayuda para encontrar todos los comentarios de un determinado usuario te ayudo, para que puedas usar tu (poco) peso en Menéame en el gran ejercicio de censura que practicas
Ojo... estúdiate el algoritmo que calcula el karma, a lo mejor te perjudica (por si piensas que votar negativo en masa sirve de mucho
¡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)
@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.
@Neochange Suecia es una de las sociedades menos xenófobas que hay (a pesar de lo que haya podido parecer tras los "incidentes" en Estocolmo este verano). Esto más que xenofobia es un ejemplo de uso/abuso absurdo de los ratings de crédito a personas físicas. Aunque siempre podría ser peor, como en EEUU... /cc @flekyboy
Qué cachondos son estos de Comviq (operadora sueca): "Como no tiene usted historial de crédito, no puede contratar el plan postpago con 1GB de datos por 95 SEK/mes. Pero no se preocupe, ¡tenemos planes disponibles para usted! ¡Puede contratar 3GB de datos, SMS y llamadas ilimitadas por 245 SEK / mes!".
Como soy un recién llegado y todavía no tengo credit history me ofrecen... un plan mensual más caro. Makes sense.
@RickDeckard@Cesc_ ahora que sale el tema, terminé abandonando el proyecto entre otras cosas porque no podía reproducir gran parte de los bugs que me llegaban. Aún así lo estuve usando hasta hace un par de meses, cuando lo cambié por este widget: kde-look.org/content/show.php/Redshift+Plasmoid?content=148737github.com/simgunz/redshift-plasmoid
Empezó siendo un fork del mío con algunas mejoras y sin soporte para f.lux, pero al final lo reescribió en C++ (yo lo hice en Python y de forma bastante guarrera, la verdad sea dicha) y le ha quedado bastante majo, aunque hay cosas que no me convencen.
Independientemente de que se usen widgets o no, para Linux recomiendo Redshift, es muy configurable y sencillito, aunque f.lux cumple la función perfectamente. Mis ojos y yo no estamos a gusto sin uno de los dos instalado. Y, al menos en mi caso, noté bastante el cambio en la facilidad para conciliar el sueño cuando me lo puse por primera vez.
Ojo... estúdiate el algoritmo que calcula el karma, a lo mejor te perjudica (por si piensas que votar negativo en masa sirve de mucho
¡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
Ha cambiado mucho. Las redes sociales se usan para ofenderse, nadie entiende el sarcasmo
Menéame ya no es lo que era
Felicidades al resto de cumpleañeros @trillo69, @Kimy, @kastromudarra y @cajainas
Aunque parece que acabó eliminando todo lo que añadió.
Enlazar sigue sin ser delito. Besis a los trolls.
¡Saludos!
(igual me he pasao)
> 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.
Edito: Y tendría que seguir dudando, porque no me di cuenta del aupa/hala
//EDIT: Espera, ¿cómo que animando al Athletic, si tu perfil dice que eres de Vigo? Me he perdido algo
Como soy un recién llegado y todavía no tengo credit history me ofrecen... un plan mensual más caro. Makes sense.
Eso fue... ¿ayer?
-1 a @lamonjamellada y @samarkanda: ¡Volved a vuestro tráiler, camioneras!
Empezó siendo un fork del mío con algunas mejoras y sin soporte para f.lux, pero al final lo reescribió en C++ (yo lo hice en Python y de forma bastante guarrera, la verdad sea dicha) y le ha quedado bastante majo, aunque hay cosas que no me convencen.
Independientemente de que se usen widgets o no, para Linux recomiendo Redshift, es muy configurable y sencillito, aunque f.lux cumple la función perfectamente. Mis ojos y yo no estamos a gusto sin uno de los dos instalado. Y, al menos en mi caso, noté bastante el cambio en la facilidad para conciliar el sueño cuando me lo puse por primera vez.