!script> !script> !script>
1. Consideramos um banco que possui a tabela "Usuarios". Essa tabela possui os campos "id_usuario", "login_usuario" e "senha_usuario";
2. Como padrão, utilizamos o "id_usuario" como chave primária, e o "login_usuario" como UNIQUE CONSTRAINT (para evitar uma repetição de logins). Esses campos, respectivamente, são INT AUTOINCREMENT e VARCHAR(20);
3. Esse passo é BASTANTE importante. Ao invés de colocarmos o campo "senha_usuario" como VARCHAR ou outro tipo texto, deve-se colocá-lo como VARBINARY. Feito isso, a estrutura está pronta;
4. Agora é só manipular tudo via SQL. Quando for cadastrar um usuário, não se pode mais dar um INSERT normal, e sim, um INSERT do tipo:
Feito isso, será inserido um registro que receberá um código de auto-incremento no campo "id_usuario", com o login = Juary e com uma senha = 123456. Feito isso, o procedimento está concluido. Para tal, tente dar o seguinte comando:
Esse SELECT retornará o registro que você inseriu, entretanto, no campo "senha_usuario", ele retornará caracteres "loucos", de forma que você não poderá visualizar a senha nem dessa forma e nem utilizando o Enterprise Manager;
5. Provavelmente, caso fosse omitida essa parte, alguém tentaria fazer o seguinte comando:
Um comando como esse (que normalmente poderia ser realizado pra algum tipo de autenticação), não irá fucionar de forma nenhuma. A solução então para retornar os dados que foram inseridos através do INSERT é a seguinte:
Esse comando retornará com sucesso o registro requisitado.
Agora explicando o funcionamento. O campo VARBINARY, quando recebe aquele INSERT, o registro fica encriptado (PWDENCRYPT)no campo "senha_usuario", de forma que não se pode mais "desencriptar". Após isso, o comando CONVERT, transforma o texto em VARBINARY, o que torna impossível se visualizar a senha.
Como o que foi encriptado não se pode mais "desencriptar", utilizamos o comando PWDCOMPARE para COMPARAR o que foi digitado, ou seja, não se pode re-tranformar o que foi encriptado antes na senha original, e sim, apenas comparar a senha digitada pelo usuário, convertendo-a para VARBINARY. Se isso for VERDADEIRO (por isso o "=1" no SELECT), o SELECT é realizado retornando o registro, de forma que você pode manipulá-lo da forma que desejar.
Como nem o Admin tem acesso à senha, pode-se apenas implementar uma atualização de senha (que, lógico, apenas o Admin poderia fazer com os usuários, e o usuário com si próprio), que seria da seguinte maneira, utilizando o exemplo citado:
Dessa forma, o usuário Juary teria a senha mudada.
Esse procedimento simples faz com que o banco de dados se torne mais seguro já que a senha não pode ser visualizada (apenas alterada). E, obviamente, a função de ser alterar a senha, só deve ser disponibilizada para as pessoas certas...
Data | Título |
---|---|
14/05/2024 | 21ª Imprensa no Forró |
07/05/2024 | Programação do São João 2024 de João Pessoa |
27/04/2024 | Programação da Festa de Sant’Ana 2024 |
26/04/2024 | Fortal irá ocorrer em uma nova Cidade Fortal |
21/04/2024 | Pecuária de Goiânia 2024 |
14/04/2024 | Forró du Vale abre os festejos juninos do interior da Bahia |
07/04/2024 | Festival Gastronômico de Lagoa Nova/RN 2024 |
24/03/2024 | São João 2024 de Campina Grande |
23/03/2024 | São João 2024 de Cruz das Almas |
19/03/2024 | São João de Assú/RN 2024 |
14/03/2024 | Festival Forrozar |
13/03/2024 | Samba da Raffe realiza edição especial St. Patrick’s |