Senha mysql

[MARCELOG]

Olá pessoal,
estou "tentando" criar uma rotina para tratar os usuários do mysql com acesso ao banco de dados utilizado pelo sistema através do próprio sistema.
Contudo, a senha de entrada no mysql é convertida num string de 40 caracteres pela função password().
Essa senha não "descriptografável".
Então, ao recuperar a senha para confirmação ou alteração, ao invés dos valores originais para comparação, o mysql "devolve" a sequência de 40 caracteres.
Pensei em manipular na "unha" as tabelas user e db do mysql, mas a coluna password tem tamanho 41, não comportando os tamanhos dos resultados das funções de criptografia que admitem a descriptografia.
Alguém já passou por isso ou tem alguma solução para o problema?

MarceloG.

[Maligno]

Normalmente esse esquema de GET de senhas é sempre o mesmo: pede-se pro usuário o nome de log-in e a senha duas vezes, comparando as strings das senhas, da forma como o usuário digitou. Uma vez confirmadas, nome de log-in e senha são "somadas" e é calculado seu hash (normalmente MD5), que é então gravado no banco de dados. Se o usuário esquecer a senha, outra deve ser cadastrada. Não dá pra recuperar a original. Quer dizer, até dá, mas não é o usual. ))

[Stanis Luksys]

Olá,

Eu não entendi ao certo o que se pretende fazer. Você quer que o usuário acesse seu sistema e o banco ao mesmo tempo como user para as duas coisas? Tipo, cada usuário do sistema ser um usuário do banco?

Isso não é comum, aconselho a manipular o banco pelo sistema sempre com um unico user do banco, o próprio sistema. Você cria no mysql um usuario "sistema" com sua senha e pronto.

Se você tiver varios users a segurança fica boa, mas veja, de nada adianta vc proibir o usuário João de fazer alteração e deixar a opção no sistema, o que aconteceria é um erro de execução lá no mysql que deixaria o usuário assustado. Sendo assim, você vai ter que tratar de qualquer maneira via sistema, e portanto deixa de existir esta necessidade, a menos claro que você permita que os usuários acessem o bd com outras ferramentas.

No database que o user "sistema" tem acesso você cria a tabela "usuarios", e grava a senha do usuário do seu sistema com hb_md5("senha"), e lá no mysql, se precisar compara também com MD5("senha").

Você deve dar acesso limitado ao usuário "sistema", como por exemplo não permitir dropar tabelas, isso garante maior segurança.

Eu faria assim.

Falou maninho!!

[Maligno]

Um detalhe, Stanis: se o hash for calculado sobre nome+senha, você até pode ter vários usuários com o mesmo nome sem conflito algum, se a busca do usuário for pelo hash. Muito embora em alguns casos seja interessante evitar nomes iguais, a fim de evitar confusões "visuais", digamos assim. Mas, na maior parte dos casos, não há problema algum.

[MARCELOG]

Oi Stanis, oi Maligno, obrigado pela costumeira atenção.
É o seguinte:
O acesso as opções do meu sistema tá tranquilo, pego o nome do usuário e host com current_user() e verifico numa tabela dentro do meu db se o "pentelho" pode ou não fazer determina coisa.
Só que o mysql tem o controle dele para usuário, inclusive externo.
Por isso estou empenhado nesse trabalho.
Mas o que eu queria era possibilitar ao usuário manipular os acessos do mysql pelo meu sistema.
Eu já faço isso.
Através do sistema criou e edito usuário do mysql numa boa.
Só não consigo manipular a senha.

É assim oh:

Instala-se o mysql e o usuário root é criado com a senha tal e acesso total.

Esse usuário acessa o meu sistema e informa o usuário root e a senha tal.

A conexão é feita e verificada a existência do bd e tabelas.

Se não existir, como root, crio o db e tabelas, bem como o usuário padrão do meu sistema.

Esse usuário padrão pode fazer tudo, mas só tem acesso ao bd mysql.* e meudb.*.

Mas esse usuário padrão tem a senha padrão que deve ser alterada.

Se o usuário alterar a senha que vai estar num textbox, beleza. A nova senha será convertida pela função password() e convenientemente gravada em mysql.user e mysql.db.

Contudo, se ele não alterar essa senha e eu usar hash obtido com a função select (que vai estar no textbox), isso vai gerar outro hash e o acesso será prejudicado (uma senha de 40 caracteres não dá).

Então, pensei em criar minhas senhas que vão ser armazenadas nas tabelas user e db do mysql.

Só que os campos (colunas) padrões têm tamanho 41 e as funções de criptografia disponíveis para o mysql geram sequência de caracteres maior e contendo símbolos. (password() só gera números e letras)
E já ouvi que o mysql não se dá bem com símbolos nas colunas.

Simples exemplo:

"select aes_encrypt('a','a')" gera sequência de 16 caracteres com letras e símbolos.

MarceloG

[sygecom]

Tche, Marcelo....pq criar mais usuario ? desculpa a pergunta...mas não vejo uma explicação logica para isso.

Não seria melhor vc criar um unico usuario e uma unica senha...e restringir o acesso...a banco pelo Front mesmo.....por mais que queram acessar o seu banco pelo Front....acho que sem a senha.....ninguem vai acessar....claro que salvo os metidos que passam dia sem fazer nd e ficam procurando falhas no MYSQL ...para poder acessar...

Abraços
Leonardo Machado

[MARCELOG]

Oi Stanis,
relendo mais atentamente a sua resposta acho que dá para implementar o acesso criando uma rotina para criar usuários no mysql e outra para criação dos usuários do sistema.
Mas ainda não vai dar para detectar a alteração da senha original dos usuários mysql, já que o hash não é descriptografável.
Para uma "gambiarra", ou melhor, uma solução menos prática e menos custosa, há como verificar se o textbox (mingui) foi atualizado sem verificar e comparar o conteúdo?
Algo do tipo form.textbox.update().
Assim, jogo o hash no textbox e se ele foi alterado uso password(), caso contrário, gravo do seu conteúdo nas tabelas próprias.

Obrigado.

MarceloG.

[Stanis Luksys]

Um detalhe, Stanis: se o hash for calculado sobre nome+senha, você até pode ter vários usuários com o mesmo nome sem conflito algum, se a busca do usuário for pelo hash.

Sim, eu sei disso, eu apenas quis demonstrar de que nada adianta ter vários usuários no banco se o controle não for feito pelo sistema, pois se for desta forma o usuário acabará por ver erros de retorno do mysql. Se é para tratar pelo sistema, o mais simples é tratar só por ele, afinal para acessar o banco por outra ferramenta o sujeito teria que ter a mesma senha que está no *.prg.

Oi Stanis,
relendo mais atentamente a sua resposta acho que dá para implementar o acesso criando uma rotina para criar usuários no mysql e outra para criação dos usuários do sistema.

Não vejo vantagem alguma em se fazer isso. Inclusive considero pior, visto que um espertalhão pode desconfiar que além de usuário no sistema é também usuário no banco, pegar um phpmyadmin da vida e detonar com sua base, nem que seja com simples alterações "inocentes".

Na minha opinião o mais fácil é ter uma tabela de usuários, com nme, senha e direitos, tudo em md5.


Falou!

[Maligno]

Agora que entendi melhor. Criar usuários no banco e no sistema também. Se for isso mesmo, desaconselho. Concordo com o Leonardo. Usuário no banco só o administrador. No front-end o controle de usuários. Inclusive, fica bem mais fácil assim.

[Stanis Luksys]

Abrindo um parêntese (

Se fosse Linux até caberia esta lógica, já que o usuário logado do Sistema Operacional é soberano em todas as operações, mesmo em softwares de terceiros e contribuições, como por exemplo o próprio MySQL.

)

Isso ae!

[MARCELOG]

Bem pessoal,
é que estou pensado em termos de distribuição.
Vou distribuir o sistema junto com o mysql.
Através do instalador, efetuo a instalação do mysql e crio as pastas e jogo o meu sistema lá.
O meu potencial cliente não vai precisar saber nada de mysql.
Vai instalar o mysql, criar o "root" e pronto.
A partir daí, entrando e através do sistema, vou criar os outros usuários, etc.
A primeira coisa a sugerir para o usuário, depois da criação do bd, tabelas e usuário padrão é, através do sistema, incluir e/ou alterar a senha do "root", especialmente se ela for inexistente.
Assim, apesar das vantagens, não vai precisar ter um administrador para o bd e conhecer o mysql mais profundamente.

Mas eu me curvo a sabedoria dos mestres e, quanto a usuários, vou rever meus conceitos.

MarceloG.

Ps: o Stanis disponibilizou o exemplo de mysql com xharbour.
Nos sabemos que no executável tem o host, usuário e password definidos.

Mas se amanhã ele resolver mudar alguma coisa, vai ter de criar outro executável e disponibilizá-lo.

Eu gostaria de deixar isso livre, ou seja, abre a janela com campos de host, usuário e password para a conexão de pronto.

Se o usuário tem acesso ao mysql, ok. Se não tem, tchau!

Se tem acesso ao bd do sistema, vai continuar executando a aplicação cliente. Se não tem, tchau! (é um usuário externo qualquer)

Assim, se o cliente quer mudar de proveder e ter um novo IP a aplicação cliente continua valendo, bastando digitar o novo ip e pronto.

Da mesma forma, se mudar o servidor, nome ou ip, vai funcionar do mesmo jeito.

Tô certo?





Não quero por exemplo,

[sygecom]

Marcelo...eu toh fazendo assim hj tenho um arquivo.ini com as configurações do MYSQL....agora me diga uma coisa...pq vc jah não distribui o seu sistema com o MYSQL-NO_INSTALL....como ele vc pode jah distribuir o MYSQL com o usuario que vc desejar.....ou crie um arquivo.ini com os endereço do do MYSQL+USUARIO+SENHA...e manda bala.....se amanha ou depois seu cliente queiser mudar de provedor...é soh mudar no .INI e transferir o banco.....e como anda a pelei pela MYSQL da contrib.......puxa eu oh usando...mas confesso..toh apanhando muito....pq praticamente temos que aprender todo o mysql para usar...e a ADORDD não quebra muito galho....assim que sobrar um tempinho....vou postar minhas experiencia....

Abraços
Leonardo Machado

[Stanis Luksys]

Ps: o Stanis disponibilizou o exemplo de mysql com xharbour. Nos sabemos que no executável tem o host, usuário e password definidos.

Sim, e somente graças a isso que ele não poderá entrar no meu banco por um front-end qualquer. O usuário não sabe a senha. É uma situação diferente porque neste caso eu estaria abrindo as portas do MEU MySQL, no seu caso não, o MySQL está no PC do cara. De qualquer maneira, eu não abriria as portas, visto que usuário tem mania de querer entender de tudo e altera os dados na mão sem dó, e o pior: depois reclama.

Mas se amanhã ele resolver mudar alguma coisa, vai ter de criar outro executável e disponibilizá-lo.

Para estes serviços que inventaram os contratos de manutenção e prestação de serviços, pelo qual alias a maioria dos desenvolvedores sobrevivem.

Eu gostaria de deixar isso livre, ou seja, abre a janela com campos de host, usuário e password para a conexão de pronto.
Se o usuário tem acesso ao mysql, ok. Se não tem, tchau!

Como eu já disse isso abre brechas para que ele acesse POR FORA do sistema, mas até daria pra imaginar uma solução simples, como por exemplo o usuario do banco ser "usuario"+validador, onde o validador seja uma string constante no seu exe que só você sabe.

Assim, se o cliente quer mudar de proveder e ter um novo IP a aplicação cliente continua valendo, bastando digitar o novo ip e pronto.

Eu prefiro que deixe de valer, será que ele não vai instalar em dois provedores diferentes? Três talvez? Quinze?


Bom, eu penso um pouco diferente, eu faria as validações tudo via código fonte mesmo, demorei muito mas hoje aprendi a me prevenir, ou tentar me prevenir, contra os piratas de plantão...


Falou!

[MARCELOG]

Caro Leonardo,
nunca ouvi falar desse mysql_no_install.
Se puder dar uma dica, a mesma será bem vinda.
Quanto a peleia, tô batendo de 10 a 0 no mysql (bricadeirinha).
Mas é muito fácil.
Feita a conexão, tudo é query.
A query executa a ação e retorna a pesquisa como se fosse realizada diretamente no mysql.
A pesquisa é retornada como um vetor (1 coluna) ou matriz(mais de 1 coluna).
Os métodos neterr(), error() e errorno() retornam a ocorrência de erro, o texto do erro e o seu número respectivamente.
O método lastrec() retorna o número de resultados obtidos para a pequisa.
Já o método getrow(n) pega/recupera os dados da linha da pequisa indicada.
Finalmente, o método fieldget(n) pega/recupera os dados da coluna pesquisada.

Exemplos:

criar banco de dados

oQuery:=oConexao;query('create database pctoledo')
if oQuery:neterr()
alert('faiou '+oQuery:error(),'Erro nº '+oQuery:errorno())
endif

ver bancos de dados acessaveis pelo usuário autenticado ( 1 coluna)

oQuery:=oConexao;query('show databases')
if oQuery:neterr()
alert('faiou '+oQuery:error(),'Erro nº '+oQuery:errorno())
endif

for n:=1 to oQuery:lastrec()
oRow:=oQuery:getrow(n)
? oRow:fieldget(1)
next n

ver host, nome e senha dos usuários na tabela user do mysql ( 3 colunas)

oQuery:=oConexao;query('select host,user,password from mysql.user')
if oQuery:neterr()
alert('faiou '+oQuery:error(),'Erro nº '+oQuery:errorno())
endif

for n:=1 to oQuery:lastrec()
oRow:=oQuery:getrow(n)
? oRow:fieldget(1)+ ' '+oRow:fieldget(2)+ ' 'oRow:fieldget(3)
next n

ver o nome do usuário autenticado ( 1 coluna)

oQuery:=oConexao;query('select current_user()')
if oQuery:neterr()
alert('faiou '+oQuery:error(),'Erro nº '+oQuery:errorno())
endif

for n:=1 to oQuery:lastrec()
oRow:=oQuery:getrow(n)
? oRow:fieldget(1)
next n

ver o md5 ( 1 coluna) - um colega tá até precisando!

oQuery:=oConexao;query("select md5('pctoledo')")
if oQuery:neterr()
alert('faiou '+oQuery:error(),'Erro nº '+oQuery:errorno())
endif

for n:=1 to oQuery:lastrec()
oRow:=oQuery:getrow(n)
? oRow:fieldget(1)
next n

Viu... é bem fácil.

O resto é manipular os resultados.

MarceloG

Ps: se deu erro. É só pegar o texto ou número do erro, procurar na internet e corrigir

[sygecom]

Tche, Marcelo....isso toh usando...mas jah me deparei com varias situações que as vez deixa o cara de cabelo em Pé.....referente ao MYSQL de uma olhada nesse post abaixo onde tenho os link do no install que é soh dar uns comandos para instalar e iniciar ele....pode ser feito até mesmo direto do seu sistema.....

https://pctoledo.org/forum/viewtopic.php?t=6007

Abraços
Leonardo Machado