genial-76 Postado Julho 24, 2011 Autor Compartilhar Postado Julho 24, 2011 O token é apenas uma exigência do sistema, acredito que não surja nenhuma vulnerabilidade por causa dele. Em relação ao e-mail e ao id do cliente dai sim, se alguém possuir o ID e o e-mail junto com o token, será possivel efetuar o login. Mas geralmente os clientes não sabem seus próprios IDs e o ID não é algo público para os outros clientes. Carlo, também estava meio cabreiro com essa dúvida. Estava até pensando em alterar algo na url para não parecer um autologin e sim um link unico. Mas acabei não fazendo nada, sigo aquele ditado, "não se mexe em time que está ganhando". Abração. Link para o comentário Compartilhar em outros sites More sharing options...
Jordan Miguel Postado Julho 25, 2011 Compartilhar Postado Julho 25, 2011 O token é apenas uma exigência do sistema, acredito que não surja nenhuma vulnerabilidade por causa dele. Em relação ao e-mail e ao id do cliente dai sim, se alguém possuir o ID e o e-mail junto com o token, será possivel efetuar o login. Mas geralmente os clientes não sabem seus próprios IDs e o ID não é algo público para os outros clientes. É verdade, mas é uma brecha não é? Querendo ou não.. Link para o comentário Compartilhar em outros sites More sharing options...
Carlo Schneider Postado Julho 25, 2011 Compartilhar Postado Julho 25, 2011 É verdade, mas é uma brecha não é? Querendo ou não.. Não vejo exatamente como uma brecha, porque se for pensar por um lado de que pra acessar o sistema via autologin vão precisar do ID e do e-mail do cliente. E o ID não é distribuido facilmente, apenas através do e-mail para cada cliente. Seria quase como alguém tentar acertar o login e senha de um dos clientes. Até daria para dar uma segurança maior, estou pensando nessa possibilidade. Criar mais um campo chave na URL (&chave=) e extrair algumas informações de cada cliente e fazer comparações md5. Mas como os campos de cadastro são um pouco limitados, teria que estudar melhor essa possibilidade. Teriam que ser os campos obrigatórios. Sugestões são bem vindas :D Link para o comentário Compartilhar em outros sites More sharing options...
Jordan Miguel Postado Julho 25, 2011 Compartilhar Postado Julho 25, 2011 Não vejo exatamente como uma brecha, porque se for pensar por um lado de que pra acessar o sistema via autologin vão precisar do ID e do e-mail do cliente. E o ID não é distribuido facilmente, apenas através do e-mail para cada cliente. Seria quase como alguém tentar acertar o login e senha de um dos clientes. Até daria para dar uma segurança maior, estou pensando nessa possibilidade. Criar mais um campo chave na URL (&chave=) e extrair algumas informações de cada cliente e fazer comparações md5. Mas como os campos de cadastro são um pouco limitados, teria que estudar melhor essa possibilidade. Teriam que ser os campos obrigatórios. Sugestões são bem vindas :D Sim, mas o que penso eu é.. Um cliente recebe o link com id, email e token.. E ele sabe o email de outro cliente.. Ele mesmo pode tentar vários ID's, não há uma proteção contra isto entende? Link para o comentário Compartilhar em outros sites More sharing options...
henrique Postado Julho 25, 2011 Compartilhar Postado Julho 25, 2011 A ID e o e-mail são unicos no sistema não é ? Logo penso em passar a ID da fatura, e-mail e o token via url para a página autologin.php e ele fazer uma busca no banco de dados pelo e-mail passado e retornar o clientid via POST liberando o acesso. O que acham da idéia ? Tentei olhar o código fonte do autologin para tentar adaptar, mas esta criptografado. Link para o comentário Compartilhar em outros sites More sharing options...
Jordan Miguel Postado Julho 25, 2011 Compartilhar Postado Julho 25, 2011 A ID e o e-mail são unicos no sistema não é ? Logo penso em passar a ID da fatura, e-mail e o token via url para a página autologin.php e ele fazer uma busca no banco de dados pelo e-mail passado e retornar o clientid via POST liberando o acesso. O que acham da idéia ? Tentei olhar o código fonte do autologin para tentar adaptar, mas esta criptografado. Mas não é apenas para faturas, também funciona com tickets e etc.. O banco de dados do mysql é bem limitado e um pouco complexo devido o tamanho do sistema. Link para o comentário Compartilhar em outros sites More sharing options...
genial-76 Postado Julho 25, 2011 Autor Compartilhar Postado Julho 25, 2011 Acho que daria para comparar também com o cep e telefone... Se não me engano são campos obrigatória do WHMCS e já vem padrão nele. Também seria interessante travar com o CPF, ou algo assim... Link para o comentário Compartilhar em outros sites More sharing options...
Carlo Schneider Postado Julho 25, 2011 Compartilhar Postado Julho 25, 2011 No WHMCS tem também aquela parada de pergunta e resposta para lembrete da senha. Poderia ser usada. Nome, Sobrenome, Email, Endereço, Cidade, Estado, CEP, Telefone, Senha me parece que são obrigatórios. Vou analisar essas opções pra reforçar o sistema :D Link para o comentário Compartilhar em outros sites More sharing options...
genial-76 Postado Julho 25, 2011 Autor Compartilhar Postado Julho 25, 2011 No WHMCS tem também aquela parada de pergunta e resposta para lembrete da senha. Poderia ser usada. Não são todos que usam essa opção. Pessoalmente não uso ele. Cliente as vezes tem dificuldade de clicar em renomear senha, imagina lembrar disso. heheheh Link para o comentário Compartilhar em outros sites More sharing options...
lucast Postado Julho 26, 2011 Compartilhar Postado Julho 26, 2011 Bom, to meio por fora de como está implementado o sistema, mas acredito que passar essas informações pela URL, sem máscara, gere um grau de vulnerabilidade, mesmo sendo difícil a questão de uma pessoa acertar o id e o e-mail de outra, mas aí pode entrar a questão da engenharia social. Eu penso em dois modos que se possa fazer: 1- Ao inves de passar as informações do usuário, como id e e-mail, concatenar os bytes dessa informação e aplicar o hash. Mas aí seria interessante armazenar esse hash no banco de dados para ter acesso direto e não ficar gerando o hash do cliente toda hora. 2- Cifrar as informações dos clientes. Para criptografia simétrica, aconselho AES ou 3DES e assimétrica o algoritmo RSA. E em relação aos algoritmo de hash, já foi conseguido sucesso em ataques de colisão ao MD5 e SHA-1. Abraço Link para o comentário Compartilhar em outros sites More sharing options...
Posts Recomendados