¿Cuál es la forma correcta de importar todos los usuarios existentes de Discourse a intercoin.app desde Discourse? ¿Existe algún tipo de punto final REST que devuelva todos los usuarios con sus contraseñas hasheadas y sales, entre otras cosas? ¿Cuál es el enlace al algoritmo de hash en github? Tendré que codificar de nuestro lado para usar el mismo algoritmo de hash con la contraseña y la sal ingresadas, si el nuestro no funciona, para permitir que esos usuarios inicien sesión. Creo que el #2 es relevante cada vez que un usuario de Discourse activa el SSO más tarde (como nosotros), por lo que resolverlo ayudaría a otros usuarios de Discourse también.
¡Excelente! Ahora, ¿cuál es el endpoint HTTP al que debo llamar para obtener toda la información del usuario, incluido el hash de la contraseña y la sal?
Imagino que no hay uno para servir al público en general (¿por qué facilitar el hackeo de personas?) Entonces, ¿qué puedo hacer? ¿Conectarme a la base de datos MySQL? ¿Escribir un plugin de Discourse?
Acabo de hablar con nuestro equipo y están de acuerdo, estoy dispuesto a pagarle a alguien para que cree un pequeño plugin de Discourse que exponga a través de un endpoint información JSON sobre un usuario, dada su dirección de correo electrónico.
Entonces, dada una dirección de correo electrónico, el plugin simplemente buscará en la tabla user_email por el correo, luego encontrará el user_id y obtendrá la fila del usuario, y enviará todos los campos “seguros”, incluida la sal.
Para mayor seguridad, las solicitudes se pueden firmar mediante HMAC utilizando un secreto compartido que se puede proporcionar al plugin.
¿Alguien quiere hacer esto? Envíame un mensaje o responde aquí y házmelo saber cómo contactarte. Esperemos que sea sencillo (un par de SELECTs y una verificación de HMAC si se estableció el secreto). Leeremos el JSON.
root@server:~# cd /var/discourse/
root@server:/var/discourse# ./launcher enter app
Se detectó la arquitectura x86_64.
root@server:/var/www/discourse# rails c
[1] pry(main)> Rails.configuration.pbkdf2_iterations
=> 64000
[2] pry(main)>
La biblioteca xorcist es solo un xor de cadenas más rápido, ¿verdad? ¿Qué pasa si uno de los caracteres termina siendo 0 porque ‘a’ se hizo xor con ‘a’? ¿Qué pasa con esa cadena? ¿No están las cadenas terminadas en nulo?
Mi objetivo es portar esto a PHP, así que cualquier cosa que puedas hacer para ayudar (como darme información sobre cómo replicarlo en PHP) será muy útil.
Además, ¿qué hace esta línea? ret.bytes.map { |b| (\"0\" + b.to_s(16))[-2..-1] }.join(\"\")
$u = hash_hmac('sha256', $password, $salt . pack('N', 1));
$ret = $u = hash_hmac('sha256', $password, $u);
for ($i=2; $i<$iterations; ++$i) {
$u = hash_hmac('sha256', $password, $u);
$ret = ($ret ^ $u);
}
// todo: averiguar qué está haciendo RUBY en esta última línea
¿Es esto cercano? ¿Puedes por favor arreglar este código PHP?
Normalmente, los algoritmos hash operan sobre datos binarios y el resultado se codifica en hexadecimal o Base64 al salir. Así que eso no es un problema.
¡Sí! Pude crear un script que recorre todos los usuarios de Discourse y los importa con el hash de su frase de contraseña a nuestra plataforma.
Pronto, podremos permitir que cualquiera que tenga un foro de Discourse agregue también Eventos, Videoconferencias, Medios y más, con Discourse residiendo en la pestaña “Discutir”. Puedes ver el resultado en https://intercoin.app
Básicamente, convertimos cualquier instalación de Discourse en una red social moderna al estilo de Facebook. Hemos trabajado durante años en estas funciones y ahora queremos integrarlas estrechamente con Discourse y WordPress también. Así, las personas pueden combinar WordPress, Discourse y Qbix y autoalojar toda su comunidad.
En Qbix, ciframos la contraseña en el cliente al menos con sha1(contraseña + userId) antes de enviarla al servidor. Incluso cuando es https. Lo hacemos para que el servidor o cualquier MITM NUNCA tenga la contraseña, para reutilizarla en varios sitios. Pero, Discourse simplemente envía la contraseña al servidor. Por lo tanto, tuvimos que desactivar este cifrado en el lado del cliente. ¿Es posible realizar algunas iteraciones de hash_pbkdf2 en el lado del cliente y el resto en el lado del servidor? Lo intenté y no parece coincidir:
¿Sería posible simplemente usar Discourse como un Proveedor de SSO, en lugar de usar nuestro sitio como proveedor de SSO? Entonces, los hosts de los foros de Discourse tendrían aún más probabilidades de expandirlo con las funciones de Qbix, ya que el inicio de sesión seguiría siendo exactamente el mismo, y del lado de Discourse. Facebook, Google y cualquier otra cosa. ¿Hay alguna documentación sobre qué tipo de información devuelve Discourse Connect como Proveedor de SSO a nuestro sitio consumidor? ¿Incluye cosas como la foto que podemos descargar, el nombre, el apellido y al menos el nombre de usuario?
Sinceramente, no creo que enviar una contraseña a través de HTTPS sea tu mayor desafío de seguridad en este momento.
Claro. Creo que obtienes la mayoría de las cosas en el serializador de usuario estándar.
Pero si eso no es suficiente, siempre puedes usar la API para obtener más información de Discourse.
Recomendaría a Discourse que hashee las cosas con una sal (userId funciona) antes de enviar la contraseña por la red. ¿Por qué no? No tiene por qué ser incompatible con lo que almacenas en la base de datos ahora. Simplemente haz las primeras 100 iteraciones en Javascript, luego resta 10 de 64000. Tienes una implementación personalizada de todos modos (copiada de rails), así que simplemente enviarías una variable isHashed, y si es verdadera, entonces haz solo los “últimos” 64K-10 pasos.
El ID de usuario no se conoce antes del inicio de sesión, así que eso no funcionará…
10 iteraciones no son seguras, y 63990 iteraciones son menos seguras que 64000 iteraciones. Así que, aunque sea marginal, parece que estás reemplazando un método seguro con dos métodos menos seguros y mucha complejidad adicional.
