Estou desenvolvendo meu primeiro sistema para o TCC, no sistema quero implementar um tela de login para controlar o acesso, mas me surgiu a duvida se os dados como login e senha do usuário devem estar ou não no Banco de dados.
desde já agradeço
O indicado é ter os dados registados numa base de dados sim.
Como auxíliar, pode usar um framework com função de controlo de acesso(spring security, por ex.).
E, para garantir alguma segurança das senhas guardadas na base de dados, pode usar encriptação(recorrendo a algoritmos como MD5, SHA, etc.).
Vc pode deixar em arquivo, o que não é pratica comum do mercado de trabalho.
Vai dos requisitos. [=
Aqui mostra como fazer usando filter:
Autenticação de Usuários (Filter/Servlet)
E aqui com Filter e JSF:
Aplicação Web Completa Tomcat JSF Primefaces JPA Hibernate
Te aconselho filter por ser mais simples. [=
Geralmente esses dados é deixado no banco de dados, mas com criptografia.
Mas esta tabela de “login” tem que se relacionar com outra tabela do meu banco de dados?
as tabelas que eu tenho são:
clientes
fornecedores
vendas
contas a pagar
contas a receber
compras
produtos
itens da veda.
[quote]
Mas esta tabela de “login” tem que se relacionar com outra tabela do meu banco de dados?
as tabelas que eu tenho são:
clientes
fornecedores
vendas
contas a pagar
contas a receber
compras
produtos
itens da veda. [/quote]
Os dados deixa no banco de dados e a senha criptografada, sua tabela de login irá relacionar em uma tabela se você for trabalhar com nível de acesso.
Para esta tabelas listadas creio que não.
certo e se eu quiser restringir o acesso de alguns usuários somente a tabela de vedas,produtos,fornecedores e compras?
Dependendo com que você esta trabalhando terá que fazer restrição de acesso, tem Sping Security, se tu estiver trabalhando com JBOSS tem o JAAS.
Neste Link tem um post: http://www.guj.com.br/java/289644-controle-de-acesso
Até hoje eu só vi senha criptografada. Qual a vantagem de criptografar o papel?
[quote=Shadowkan]certo e se eu quiser restringir o acesso de alguns usuários somente a tabela de vedas,produtos,fornecedores e compras?
[/quote]Filter seria o mais simples. Olhe nos exemplos que passei.
Até hoje eu só vi senha criptografada. Qual a vantagem de criptografar o papel?[/quote]
Cara, não entendi sua pergunta. Poderia ser mais claro?
A senha é criptografada, e quando o usuário digitar o login+senha, você criptografa a senha que ele digitou e compara com a que está no banco de dados.
Assim nunca ninguém sabe a senha, só se hackear o banco, mas aí é outra história.
Até hoje eu só vi senha criptografada. Qual a vantagem de criptografar o papel?[/quote]
Cara, não entendi sua pergunta. Poderia ser mais claro?
A senha é criptografada, e quando o usuário digitar o login+senha, você criptografa a senha que ele digitou e compara com a que está no banco de dados.
Assim nunca ninguém sabe a senha, só se hackear o banco, mas aí é outra história.
[/quote]Eita, duas contas detected O.o
A pergunta foi feita em cima de login/senha e também aqui se desenvolver o conceito de papel. A frase fala que “esses dados ficam no banco criptografado”. Achei que se referia além da senha ao login e papel.
Até hoje eu só vi senha criptografada. Qual a vantagem de criptografar o papel?[/quote]
Cara, não entendi sua pergunta. Poderia ser mais claro?
A senha é criptografada, e quando o usuário digitar o login+senha, você criptografa a senha que ele digitou e compara com a que está no banco de dados.
Assim nunca ninguém sabe a senha, só se hackear o banco, mas aí é outra história.
[/quote]Eita, duas contas detected O.o
A pergunta foi feita em cima de login/senha e também aqui se desenvolver o conceito de papel. A frase fala que “esses dados ficam no banco criptografado”. Achei que se referia além da senha ao login e papel.[/quote]
Veja que encriptar o papel ( o role) é tão importante quanto a senha.
A senha serve para provar que vc é quem diz ser (autenticação), mas é o role que lhe dá poder no sistema ( autorização). Se eu for um adversário que quiser zoar vc eu não preciso saber sua senha, é só mudar seus roles e vc não faz mais nada. Normalmente o pessoal deixa a lista de roles aberta o que daria azo a uma serie de ataques à autorização do sistema que é virtualmente a mesma coisa que fazer o sistema inutil. (pense se apagar a tabela de userroles o que vai acontecer)
[quote=Shadowkan]Estou desenvolvendo meu primeiro sistema para o TCC, no sistema quero implementar um tela de login para controlar o acesso, mas me surgiu a duvida se os dados como login e senha do usuário devem estar ou não no Banco de dados.
desde já agradeço[/quote]
O dados de login não precisam estar em um banco de dados relacionar , mas obviamente precisam estar num banco de dados ( no conceito abstrato que um banco de dados é um repositório de informação).
Vc poderá usar o banco de dados relacional , mas existem outras opções. LDAP e Active Directory (que pode ser acessado via LDAP) é muito usado hoje em dia , especialmente no windows, por exemplo.
Idealmente o repositorio de informação de autenticação deve ser plugável no seu sistema de forma a vc poder usar um que já seja usado pela empresa. Por exemplo, bancos sempre têm algum mecanismo proprietário para fazer autenticação e autorizaçao.
Já que é um TCC , parta do principio que isso é uma peça plugável da sua arquitetura e que um sistema externo pode prover essa informação. Em particular, o proprio sistema pode prover essa informação, mas isso é a exceção, não a regra (embora seja tlv a exceção mais comum do mundo , :lol: )
Segurança de verdade está em dificultar o acesso as coisas e depois dificultar o acesso ao acesso às coisas e assim recursivamente. O numero de recursões só depende da importância do que está sendo guardado.
[quote]Veja que encriptar o papel ( o role) é tão importante quanto a senha.
A senha serve para provar que vc é quem diz ser (autenticação), mas é o role que lhe dá poder no sistema ( autorização). Se eu for um adversário que quiser zoar vc eu não preciso saber sua senha, é só mudar seus roles e vc não faz mais nada. Normalmente o pessoal deixa a lista de roles aberta o que daria azo a uma serie de ataques à autorização do sistema que é virtualmente a mesma coisa que fazer o sistema inutil. (pense se apagar a tabela de userroles o que vai acontecer)[/quote]
Ou nao entendi direito, ou vc viajou…
Criptografia serve pra nenhuma outra pessoa saber a senha dele
Se o cara tem acesso a alteracao de dados (no caso vc disse pra alterar o role do cara), oq impediria de ele trocar a senha dele tb?
Ai já é questão de grants pra DBA…
Agora qual o problema de saber qual o role do usuário? (Pode ser questao de controle interno da empresa, igual esconder o salário, mas aí não tem nada a ver também)
[quote=igor_ks][quote]Veja que encriptar o papel ( o role) é tão importante quanto a senha.
A senha serve para provar que vc é quem diz ser (autenticação), mas é o role que lhe dá poder no sistema ( autorização). Se eu for um adversário que quiser zoar vc eu não preciso saber sua senha, é só mudar seus roles e vc não faz mais nada. Normalmente o pessoal deixa a lista de roles aberta o que daria azo a uma serie de ataques à autorização do sistema que é virtualmente a mesma coisa que fazer o sistema inutil. (pense se apagar a tabela de userroles o que vai acontecer)[/quote]
Ou nao entendi direito, ou vc viajou…
Criptografia serve pra nenhuma outra pessoa saber a senha dele
Se o cara tem acesso a alteracao de dados (no caso vc disse pra alterar o role do cara), oq impediria de ele trocar a senha dele tb?
Ai já é questão de grants pra DBA…
Agora qual o problema de saber qual o role do usuário? (Pode ser questao de controle interno da empresa, igual esconder o salário, mas aí não tem nada a ver também)[/quote]
Como disse é uma questão de quantos níveis de segurança vc quer. Normalmente , e espantosamente, é comum que nem a senha seja encriptada por que o PO fala que tem que ser possivel retornar a senha para o usuário. Tá.
Mas se o desenvovledor sabe o que está fazendo vai usar algum algoritmo de hash para encriptar. Ou seja, encriptação destrutiva. Mas o que isso protege ? Protege de um adversário que acessa o banco de dados e quer se fazer passar por si e entrar no sistema como sendo vc, com os seus poderes e atributos. Agora, pense ao contrário. O adversário que acessa o banco simplesmente mudar os poderes do usuário dele ou subverte os poderes dos outros. Isso é tão caótico e acabada dando um tipo de DoS porque os usuários conseguem se logar, mas não conseguem fazer nada no sistema. Entendido ? Já se admite que o adversário passou todas as outras barreiras e que ele já está vendo o banco de dados.
Se formos pensar que a senha do banco ou os grants ,etc, estabelecem toda a segurança necessária, então estamos sendo ingénuos, pois isso fosse verdade, não precisavamos fazer hash das senhas. ninguem ia ter acesso porque o banco de dados não daria acesso. T´. Na realidade não é bem assim.
Poderiamos ir mais longe e falar das senhas do próprio servidor, etc… mas quando vc analisa a segurança no nível X do sistema é proque implicitamente vc admite que o adversário chegou ali. É com oter duas firewalls. A segunda só faz sentido se vc admite que a primeira pode fallhar.
O ponto é que a tabela de userroles é tão vital quanto a tabela de senhas porque ambas podem ser atacadas para negar que o usuário use o sistema, e/ou para realizar uma operação não autorizada.
Ainda estou entendendo que vc ta querendo dizer que a Criptografia é para garantir a segurança e não para camuflar os dados. Sim, a criptografia é usado na garantia da segurança, mas não é essa seu objetivo.
Do jeito que estou entendendo é que vc tá dizendo que o cara pode alterar o role dele, e fazer “o que quiser” no sistema. Mas isso, o log do sistema vai pegar tudo que o cara fez… nao vai ter como ele se passar por outra pessoa…
E se o cara tem autorizacao (de banco) para alterar o role dele e de outros, então ele pode alterar outros dados também, neste caso vc diria de criptografar tudo que for importante?
Por exemplo: se um sistema gerencia as permissoes através de uma tabela no banco, ou seja, um “ROLE” feito pelo sistema, essa tabela deveria ficar toda criptografada para que ninguem troque de “Consulta”, para “Tudo” ?
O ponto é que ainda nào vi necessidade de criptografar o role, mesmo se eu alterar meu role pra ADMIN, o log do sistema vai ver q eu alterei meu salario (exemplo), e se eu posso alterar meu role, eu posso alterar as permissoes do meu role tb, ou alterar qualquer coisa que esteja no banco de dados…
[quote=igor_ks]Ainda estou entendendo que vc ta querendo dizer que a Criptografia é para garantir a segurança e não para camuflar os dados. Sim, a criptografia é usado na garantia da segurança, mas não é essa seu objetivo.
Do jeito que estou entendendo é que vc tá dizendo que o cara pode alterar o role dele, e fazer “o que quiser” no sistema. Mas isso, o log do sistema vai pegar tudo que o cara fez… nao vai ter como ele se passar por outra pessoa…
E se o cara tem autorizacao (de banco) para alterar o role dele e de outros, então ele pode alterar outros dados também, neste caso vc diria de criptografar tudo que for importante?
Por exemplo: se um sistema gerencia as permissoes através de uma tabela no banco, ou seja, um “ROLE” feito pelo sistema, essa tabela deveria ficar toda criptografada para que ninguem troque de “Consulta”, para “Tudo” ?
O ponto é que ainda nào vi necessidade de criptografar o role, mesmo se eu alterar meu role pra ADMIN, o log do sistema vai ver q eu alterei meu salario (exemplo), e se eu posso alterar meu role, eu posso alterar as permissoes do meu role tb, ou alterar qualquer coisa que esteja no banco de dados…[/quote]
Imagine então que eu sou um adversário. Eu consegui a senha do banco de dados do DBA João, que não sou eu. Então eu entro como o joão e vou na tabela de userroles ( a amarração entre os roles e os users, não os roles em si ) e apago tudo. O log do banco de dados ( não do sistema) irá dizer que o joão apagou os roles. Blz, era esse o objetivo. Ninguem vai saber que fui eu e o joão que vai pagar.
Agora o cenário que eu estava falando. Peguei a senha do João, entro no banco. Insiro uma linha dando a um usuário X o poder de admim. Este X posso ser eu, ou alguém de quem já roubei o acesso antes. Se o adversário é bom ele nunca irá usar a sua identidade. Logo, dou acesso de admin para a Maria. Ai eu entro no sistema como sendo a maria e faço o que eu quiser porque ela é admim. Mas como eu soube que role adicionar ? Porque estava lá escrito “Admim” no role. Se estivesse escrito “ZXasqwersdawww1123qdasda” como eu ia saber qual dos roles é o de Admin ?
É claro que eu poderia evoluir o cenário. Adiciono todos os roles para a maria, garantindo que assim ela será o admim. Mas o segurança do sistema criou um role de protecação que se a pessoa o tiver ela perde todos os poderes. Assim o adversário que quiser usar um insert all para dar todos os poderes não consegue e como ele não sabe qual é qual . Mas ainda sobra tentativa e erro. Vai demorar mais, mas o cara vai conseguir. Um exemplo de melhor proteção é que o sistema (não o banco de dados) gera uma chave encriptada para o par user-role. apenas se esta chave é válida é que o par é válido. Assim a associação é mais difícil apenas usando o banco e mesmo se o banco for aberto o adversário não saberá como gerar essa chave. Este mecanismo usa encriptação, mas não do role. Isto diminui o ataque ao banco e torna o sistema mais seguro simplesmente porque ha um algoritmo desconhecido no meio do processo.
Como eu disse é tudo uma questão de camadas. mas se partimos do principio que o log do sistema ou o log do banco de dados é suficiente, que eles sempre mostram que mexeu na coisa e que ninguém vai ver a info ou se a vir não vai usá-la, bem … se isso fosse assim o md5 da senha seria irrelevante.
O esquema de segurança é dinamico. O adversário está sempre tentando dar a volta. E vc sempre tentando impedir. O numero de proteções e a complexidade delas só depende do numero de iterações de segurança que vc quiz fazer.
Normalmente ninguém se preocupa com isto. Só focam em proteger a senha. E muitas vezes mal. Mas se o prêmio é bom o adversário vai tentar tudo. tudo depende do prêmio. Um sistema de cadastro não terá tanto problema como o sistema de contas do banco…
Bom, pode ser que estamos discutindo algo inútil, por isso pra nao ficar uppando o topico vou ficar por aqui mesmo… (como essa sendo a ultima postagem)
Respondendo a você:
Entendi que com o role, vc pode dar acesso ao que quiser, mas vc disse “Entro com o usuairo JOAO, entro com o usuario MARIA”, mas o que o role tem a ver com isso? como conseguiu a senha do joao se tava criptografada? O que ROLE e Criptografia na senha tem a ver com vc conseguir a senha do JOAO.
A parte do ROLE, eu entendi, eu sei que qualquer usuario vai poder trocar o role, mas se pode visualizar e alterar o role (ja que vc disse que nao se fala de grants ate o momento), eu tenho que criptografar por exemplo meu salário tb? Não tem muito sentido criptografar algo só porque isso vai dar certo acessos a mais ao sistema, se for assim, qualquer controle interno vai ter que criptografar
O ponto é: o que tem a ver criptografia de senha e role, com vc conseguir entrar com o usuario JOAO, só a senha não basta?