Re: [androidbrasil-dev] Garantir que somente a minha App acesse meu webservice

Mesmo com o HTTPS acha que vão conseguir engenharia reversa?! Só o OBAMA pra pegar pela rede. Ou através de descompilar o apk e achar as strings fixas e coisas do tipo... Mas dá pra ofuscar isso com o ProGuard

Atenciosamente,

Diego Rocha

2015-03-17 15:01 GMT-03:00 Eduardo Baião <eduardobaiao@gmail.com>:

Entendi Diego e Thiago.

É que estou partindo do pressuposto de que alguém inevitavelmente irá fazer a engenharia reversa, tendo com isso acesso ao algoritmo que gera o token.

Para este caso, ainda não encontrei uma solução.

Em 17 de março de 2015 14:53, Diego Rocha <diego@diegorocha.com.br> escreveu:

Baião, a forma como ele sugeriu já é funcional sem login.
O app ao enviar a requisição gera o token seguindo uma fórmula única que ele vai inventar, essa forma leva em consideração o horário atual. Um token usado é inutilizado, outra requisição gera outro token
O servidor ao receber, valida o horário da requisição ou se o token já foi utilizado e se for antigo sabe que é fraude (alguém capturou um token antigo e quer usar de novo).

O complicado dessa abordagem é achar uma fórmula pra gerar o token que não seja fácil de sofrer engenharia reversa, ao mesmo tempo que o servidor precisa faze-lo.

Acredito que HTTPS seja a melhor saída pois eles já lidam com chaves assimétricas, e em tese, ninguém conseguiria ver nenhum cabeçalho das requisições.
Então você poderia usar um token fixo, ou um qualquer outra validação específica que não seja de ida-e-volta, já que dá pra supor que ninguém conseguirá achar esse token analizando a rede.

Atenciosamente,

Diego Rocha

2015-03-17 14:45 GMT-03:00 Eduardo Baião <eduardobaiao@gmail.com>:

Joshef, a sugestão do token dinâmico funciona bem quando a aplicação exige que usuário se autentique. E numa aplicação onde isso não seja uma exigência?

Em 17 de março de 2015 14:25, Jhosef Marks <jhosef@gmail.com> escreveu:

Gera um token dinâmico pra cada requisição com tempo de expiração...

Pode somar um token seu, mais a data e alguma outra coisa e no ws valida antes de devolver uma resposta...

OAuth tbem pode ser uma opção.

Att,

Jhosef Marks de Carvalho

Celular: (47) 9708-6420

skype: jhosef.marks
Twitter: @jhosefmarks

Em 17 de março de 2015 13:44, Diego Rocha <diego@diegorocha.com.br> escreveu:

UserAgent também é mascarável, posso escrever um programa em qualquer linguagem que fará uma requisição passando o mesmo UserAgent do smartphone.

Se você colocar um certificado ssl e só permitir acesso ao WS por https poderá usar o Token sem riscos de engenharia reversa (em tese hahahha).

Atenciosamente,

Diego Rocha

2015-03-17 13:32 GMT-03:00 Carlos H. F. M. Rodrigues <analista.carlosh@gmail.com>:

Pessoal estou pesquisando uma solução para um situação.

Garantir que somente minha App acesse meu Webservice, sendo que meu App é de utilidade publica (Informações de linhas de ônibus e comerciais da cidade onde moro) não será obrigatório login por facebook e gmail.

Cenário: 

1 - No meu Webservice consigo validar o HTTP_USER_AGENT, validando somente requisições de SmarthPhone.

(http://www.newmediacampaigns.com/blog/three-ways-to-target-mobile-devices)

2 - Se colocar um Hash Token no meu App para acessar meu WebService, uma engenharia reversa já quebraria isso. (http://pt.stackoverflow.com/questions/34899/como-fazer-engenharia-reversa-de-um-aplicativo-android)

Se vocês poderem dar sugestão de segurança do que e como eu poderia garantir que somente a minha App acesse meu webservice.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.