Juntamente com a implementação da componente de visualização na aplicação Where@UM, foram feitas algumas alterações no sistema com o intuito de melhorar alguns aspetos.
Deste modo, são listadas algumas das alterações que foram feitas: Segurança:
o Implementação de um token de sessão enviado em todos os pedidos feitos ao servidor;
o Renovação do token de sessão automática;
o Logout automático quando o token de sessão expira. Posicionamento:
o Adicionados os campos “SSID” e “canal” às informações dos pontos de acesso que são obtidas na recolha de fingerprints;
Correção de alguns bugs no código fonte. 6.4.5.1. Modelo de dados
As alterações efetuadas resultaram em algumas adições ao modelo de dados da base de dados Where@UM e da base de dados local SQLite da aplicação Android.
Os campos SSID e canal foram adicionados na base de dados local da aplicação Android. A Figura 6.15 representa o novo modelo de dados.
Figura 6.15: Modelo de dados da base de dados SQLite
Na implementação do token de sessão foi necessário adicionar uma nova tabela, chamada “sessions”, que tem os dados das sessões ativas. Esta nova tabela é caracterizada pelos seguintes campos:
idSession – identificador da sessão;
idUser – identificador do utilizador associado à sessão; mac – endereço MAC da interface de rede do dispositivo;
platform – plataforma associada à sessão, pode ter os seguintes valores: “android”, “windowsphone” e “windowsdesktop”;
timestamp – data/hora do momento no qual a sessão foi criada;
token – string de 50 caracteres, este valor tem que ser único para cada sessão; activeToken – pode tomar os valores “Yes” ou “No”, indicando se o token está ativo
ou não. Isto é necessário porque a sessão é criada antes do utilizador se autenticar. Para que o token seja ativado é necessário que o utilizador faça o login com sucesso. Relativamente aos dados das fingerprints e pontos de acesso, foram adicionados os campos “SSID” e “canal” às tabelas aps e apsFingerprintsHistory.
O novo modelo de dados está representado na Figura 6.16, onde estão as novas adições. A descrição de todas as tabelas pode ser consultada em [44].
Figura 6.16: Modelo de dados do sistema Where@UM
6.4.5.2. Nova fingerprint
As alterações no modelo de dados permitiram uma reformulação às fingerprints que são recolhidas e enviadas para o servidor. Foi definida uma nova estrutura para o objeto JSON associado à fingerprint como demonstra a Figura 6.17. O objeto JSON contém vários parâmetros associados ao utilizador, local e data/hora onde a fingerprint foi recolhida. A fingerprint é um array
de vários objetos JSON sendo que cada objeto JSON representa as informações de um AP detetado.
Figura 6.17: Novo formato da fingerprint Where@UM
6.4.5.3. Novas medidas de segurança
Com o objetivo de melhorar a segurança na comunicação entre aplicação e servidor foi implementado o conceito de token de sessão. Tal como foi introduzido na secção anterior, o token de sessão é gerado quando a aplicação cliente faz um pedido para a criação da sessão (quando o utilizador faz o login ou cria uma nova conta). O servidor cria uma sessão e um token associado à mesma, que é enviado para a aplicação cliente mas nesta fase ainda não está ativo. Depois, é enviado para o servidor um novo pedido por parte da aplicação com os dados de autenticação do utilizador, que são validados pelo servidor caso estejam corretos. Em caso afirmativo, o token é
O diagrama de sequência da Figura 6.18 apresenta as operações efetuadas entre a aplicação e o servidor depois do utilizador introduzir os dados de login.
O processo é simples, inicialmente é feito um pedido para obter o token. O servidor devolve o token de sessão associado ao utilizador e ao dispositivo. A aplicação recebe o token e faz um pedido de login no qual envia o token como cookie no pedido com o valor “token=’valor do token’”, os dados enviados neste pedido são o e-mail do utilizador, o valor tokenpassword, o endereço MAC e a plataforma. O valor tokenpassword é obtido da seguinte forma:
𝑡𝑜𝑘𝑒𝑛𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑 = 𝑚𝑑5(𝑚𝑑5(𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑) + 𝑡𝑜𝑘𝑒𝑛)
Essencialmente, é calculado o md5, do valor md5 da password concatenado com o token. Isto permite que os dados sejam enviados para o servidor sem a necessidade de a password estar às claras.
O servidor quando efetua o login, verifica se os dados recebidos coincidem com os valores da base de dados, retornando uma resposta. Caso os dados estejam corretos, o servidor ativa o token e os dados do utilizador são enviados para a aplicação. Caso os dados de autenticação não estejam corretos, é devolvida uma mensagem de erro.
Figura 6.18: Processo de criação de uma sessão após login
O token expira 48h após a sua criação, condição que é verificada na aplicação Where@UM que faz a renovação do token automaticamente. É seguido um conjunto de verificações que permitem fazer um pedido ao servidor caso o token esteja quase a expirar.
O fluxograma da Figura 6.19 representa as operações realizadas na aplicação cliente para a renovação do token de sessão. O algoritmo é executado em background quando são recolhidas fingerprints no dispositivo. É feita a diferença em horas entre a data atual e a data de criação do token. Caso a diferença seja entre 36 e 48 horas, ou seja, quando faltarem cerca de 12h para o token expirar, é feito um pedido de renovação do token. Caso o token tenha ultrapassado as 48h, este expirou e por isso é efetuado o logout.
Figura 6.19: Renovação automática do token de sessão
O token de sessão permite evitar alguns ataques (por exemplo ataques de brute force) e aumenta a segurança uma vez que nesta nova versão dos web services as passwords não são enviadas às claras e existe um token associado a cada sessão.
No Anexo E – Web Services Where@UM é possível consultar a nova versão da API dos web services utilizada na comunicação entre a aplicação cliente e o servidor.