PC Toledo

Blz pessoal
Isso vai ficando assim por enquanto, e dificil de dar a manutencao, mas pelo menos funciona.
O dia que refizer posto aqui para analise.
[]s
claudio

Eu particularmente não gosto pq complica mesmo... pode cadastrar, mas não pode excluir... pode excluir, mas não pode cadastrar... um saco....

Já eu dou sempre atenção ESPECIAL aos níveis de senha. Não é apenas um critério para liberar para esse ou aquele usuário, mas garantir a integridade e segurança dos dados, principalmente em sistemas comerciais.

Até por questão de lógica, senão vira casa-de-mãe-joana...

Amiguinhos

Tempos atras eu disponibilizei um menu em 5win para os amigos que queriam migrar do DOS pra Windows paulatinamente.

O sistema de menus er baseado em um DBF onde os menus tinham suas opções niveldas como um plano de contas. Este menu era dinamico e nao precisava ser programado na interface pois mesma reconhecia as mudancas e pronto.

Na verdade era um beta-teste para o sistema de seguranca de meu sistema que hoje conta com flag de nivel de status para cada opção, flags de inclusão, exclusão, edição, impressão em cada opção, flag de desativação de opção e flag de liberação para o usuário.

Quando o usuário é cadastrado no sistema uma copia do menu principal é copiado para ele e ai tenho o penoso trabalho de liberar opções que seu nivel nao permite, exemplo, um usuario de nivel de acesso 2 necessita usar uma opção de nivel 3 ai eu libero ela na estrutura de seu menu e o resto so é liberado até o seu nivel.

em suma usar um arquivo externo é sempre melhor do que programar no sistema e para auxiliar a segurança, criptografar o conteudo dos campos usando funções como da SIX.

janio escreveu:Se o cidadão tem acesso ao CADASTRO DE PRODUTOS, por exemplo, gravo no CAMPO (flag) "S". Se não tem, gravo "N".

Aí se o espertão abrir no DBU e colocar tudo "S", ele acessa tudo. Muito fraco este conceito.

Eu uso parecido também, mas gravo em txt criptografado a senha e os direitos de cada usuário, e para não ficar dando mensagens do tipo "você não tem permissão" eu já retiro do menu alguns itens, mas mesmo assim só se o acesso for negado por completo.

O cara pode cadastrar produto, mas não pode alterar preço de venda por exemplo, aí tem que ter acesso ao menu, mas bloquear esta funcinalidade do preço. Mas também é simples, eu faço algo assim:

if nao_pode_alterar_preço
pedir_senha_de_alguem que_pode()
endif

Aí o cara entra com uma senha e após terminar esta tarefa quem continua logado é o fulano original.

E por aí vai...

É meio complicado isso mesmo. Existem muito jeitos.

Só posso garantir que é muito mais seguro por usuário do que por nível, pois só assim podemos gravar o histórico (log) de operações em qualquer atividade no sistema. E isso acaba caindo no tal auditor, que comentamos em outro tópico.

Falou, abraços.

gravo em txt criptografado a senha

Pra mim o problema não está no sujeito ter acesso ao conteúdo. O problema é ele alterar seus privilégios. Eu uso texto simples. Está tudo ali pro sujeito ver. Mas se alterar uma vírgula, o CRC32 (modificado) de autenticação já não vai bater e o arquivo ficará inutilizável até que ele reverta o que alterou ou algum outro usuário, mais privilegiado recadastre o sujeito e reconfigure tudo. É o mesmo esquema que eu uso no arquivo de licenciamento. O cliente vê ali a data em que o pograma ser auto-bloqueará. Se alterar alguma coisa,... Dançou!

Esse mesmo esquema de certificação também pode ser implementado num banco de dados. Basta reservar um campo para armazenar essa certificação.

Mais um detalhe: eu não gravo senha. Só gravo o hash resultante do nome+senha+"alguma coisa".

Maligno escreveu:Mais um detalhe: eu não gravo senha. Só gravo o hash resultante do nome+senha+"alguma coisa".

A senha em sí também não gravo. Eu usava a função crypt(). Atualmente uso md5 no xHarbour.
Mas o nosso processo é parecido, só que eu criptografo os dados e depois gravo no txt, você faz o contrário pelo que entendi, grava e depois gera a chave.

Só o que não dá é simplesmente ter um "S" ou "N" num dbf...

Só o que não dá é simplesmente ter um "S" ou "N" num dbf...

Até pode ter, mas se o dado está visível, deve-se criar um certificado que permita a verificação da integridade do conteúdo. Sem isso, realmente não dá. Aí tem que encriptar.

Stanis Luksys escreveu:Só o que não dá é simplesmente ter um "S" ou "N" num dbf...

Grande Stanis,

Quis ser o mais didático possível, claro que essas informações são todas criptografadas, além do que meus DBF's são todos protegidos com senha. Só acessa o DBF via sistema e olhe lá...rsrsrs

:* -:] ´o) :|< :f

Jânio

janio escreveu:além do que meus DBF's são todos protegidos com senha.

Legal. Como você fez este tipo de proteção?

Stanis,

Vou explicar senão vira confusão.

Entenda:

1-) Nos meus sistemas onde utilizo BD MySql, o Banco de Dados é todo protegido com senha, certo??? Nenhuma dúvida???

2-) Para os sistemas que ainda estão com acesso via DBF, há inúmeras funções que IMPEDEM o acesso a esses dados pelo Excel ou DBU's da vida.

Para esse segundo caso, em o usuário sendo um programador, até que dá pra burlar essa 'proteção'. Já para um usuário leigo (99,99% dos nossos clientes), duvido que ele consiga abrir o banco de dados e modificar o "N" pelo "S" como vc falou.

Entendido?

:|< :f #-)


Jânio

PS: Se formos considerar o possibilidade de o usuário abrir o DBF pelo DBU/Excel, toda a consistência do banco de dados vai pro espaço.

Legal, mas você disse que a senha era no DBF. Me interessei pelo fato, pois nunca fiz isso.

Quanto a outras formas de proteger, eu conheço bem aquela que altera um byte do cabeçalho do arquivo e o deixa corrompido, depois volta ao normal. Uma gambiarra sem tamanho... Mas funiona.

Eu num protejo os DBFs de nenhum jeito.

Conscientencia o sistema tem por sí próprio, se alguém alterar o DBF diretamente, vai ter que alterar sempre em 2 lugares, pois aqui somos todos viciados em segurança, não há uma única rotina do sistema que não grave os dados em pelo menos dois locais. E ainda assim vai dar pau no auditor...

Falou!

Para evitar que meu banco de dados de senhas seja aberto via DBU/Excel eu salvo as variáveis em um arquivo, com qualquer extensão.

Para conferir a senha, o programa abre o arquivo, carrega as variáveis, aí é só comparar a senha digitada.

Para criar nova senha, faz o inverso. Sempre funcionou.