Qual é a maneira correta de importar todos os usuários existentes do Discourse para o intercoin.app a partir do Discourse? Existe algum tipo de endpoint REST que retorne todos os usuários com suas senhas com hash e salts, entre outras coisas? Qual é o link para o algoritmo de hash no github? Terei que codificar do nosso lado, para usar o mesmo algoritmo de hash com a senha e o salt inseridos, caso o nosso próprio não funcione, para permitir que esses caras façam login. Acho que #2 é relevante sempre que um usuário do Discourse ativar o SSO mais tarde (como nós), então resolvê-lo ajudaria outros usuários do Discourse também.
Excelente! Agora, qual é o endpoint HTTP que eu chamo para obter todas as informações do usuário, incluindo hash de senha e salt?
Imagino que não haja um para servir ao público em geral (por que facilitar o hacking de pessoas?) Então, o que posso fazer? Conectar ao banco de dados MySQL? Escrever um plugin do Discourse?
Acabei de falar com nossa equipe, e eles concordam, estou preparado para pagar alguém para criar um pequeno plugin do Discourse que exponha via endpoint algumas informações JSON sobre um usuário, dado seu endereço de e-mail.
Então, dado um e-mail, o plugin simplesmente pesquisará na tabela user_email pelo e-mail, depois encontrará o user_id e pegará a linha do usuário, e enviará todos os campos “seguros”, incluindo o salt.
Para segurança extra, as requisições podem ser assinadas via HMAC usando um segredo compartilhado que pode ser fornecido ao plugin.
Alguém quer fazer isso? Me mande uma mensagem ou responda aqui e me diga como entrar em contato. Espero que seja simples (alguns SELECTs e uma verificação de HMAC se o segredo foi definido). Leremos o JSON.
A biblioteca xorcist é apenas um xor de string mais rápido, certo? E se um dos caracteres acabar sendo 0 porque ‘a’ foi xorado com ‘a’ — o que acontece com essa string? As strings não são terminadas em nulo?
Meu objetivo é portar isso para PHP, então qualquer coisa que você puder fazer para ajudar (como me dar informações sobre como replicá-lo em PHP) será muito útil.
Além disso, o que essa linha está fazendo? 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: descobrir o que o RUBY está fazendo nesta última linha
Isso está perto? Você pode corrigir este código PHP?
Normalmente, os algoritmos de hash operam em dados binários e o resultado é codificado em hexadecimal ou Base64 na saída. Portanto, isso não é um problema.
Sim! Consegui criar um script que percorre todos os usuários do Discourse e os importa com o hash de sua senha em nossa plataforma.
Em breve, poderemos permitir que qualquer pessoa que tenha um fórum Discourse adicione também Eventos, Videoconferência, Mídia e mais, com o Discourse residindo na aba “Discuss”. Você pode ver o resultado em https://intercoin.app
Basicamente, transformando qualquer instalação do Discourse em uma rede social moderna, à la Facebook. Trabalhamos por anos nesses recursos e agora queremos integrá-los de perto com o Discourse e o WordPress também. Assim, as pessoas podem combinar WordPress, Discourse e Qbix e auto-hospedar toda a sua comunidade.
No Qbix, nós fazemos o hash da senha no cliente, pelo menos com sha1(senha + userId) antes de enviá-la ao servidor. Mesmo quando é https. Fazemos isso para que o servidor ou qualquer MITM NUNCA tenha a senha, para reutilizá-la em vários sites. Mas o Discourse simplesmente envia a senha para o servidor. Então, tivemos que desativar esse hash no lado do cliente. É possível fazer algumas iterações de hash_pbkdf2 no lado do cliente e o restante no lado do servidor? Tentei e não parece alinhar:
Seria possível usar o Discourse apenas como um Provedor de SSO, em vez de usar nosso site como provedor de SSO? Então, os hosts de fóruns Discourse seriam ainda mais propensos a expandi-lo com recursos do Qbix, já que o login permaneceria exatamente o mesmo, e do lado do Discourse. Facebook, Google e o que mais. Existe alguma documentação sobre que tipo de informação o Discourse Connect retorna como Provedor de SSO para nosso site consumidor? Ele inclui coisas como a foto que podemos baixar, primeiro nome, último nome e nome de usuário, pelo menos?
Sinceramente, não acho que o Discourse enviar uma senha via HTTPS seja seu maior desafio de segurança neste momento.
Claro. Acho que você obtém a maioria das coisas no serializador de usuário padrão.
Mas se isso não for suficiente, você sempre pode usar a API para obter mais informações do Discourse.
Eu recomendaria ao Discourse que hasheasse as coisas com um salt (userId funciona) antes de enviar a senha pela rede. Por que não? Não precisa se tornar incompatível com o que você está armazenando no banco de dados agora. Simplesmente faça as primeiras 100 iterações em Javascript, depois subtraia 10 de 64000. Você tem uma implementação personalizada de qualquer maneira (copiada do rails), então você apenas enviaria uma variável isHashed, e se for verdadeira, então faça apenas os “últimos” 64K-10 passos.
O ID do usuário não é conhecido antes do login, então isso não funcionará…
10 iterações não são seguras, e 63990 iterações são menos seguras do que 64000 iterações. Portanto, embora seja marginal, parece que você está substituindo um método seguro por dois métodos menos seguros e muita complexidade extra.
