Como validar Acceso al sistema

[alcides]

Gracias Neftali por ayudarme, voy a tratar y luego te hago saber,
porque realmente lo que no he podido es validar el nombre del usuario ya creado, cuando se pide el acceso.


alcides
Rep.Dom.

[marcoszorrilla]

Ahondando en la situación se supone que la clave esta encriptada por un algoritmo, hecho por ti mismo, no se te estará olvidando de desencriptar la clave para compararla con la introducida por el usuario, o también puedes utilizar lo contrario encriptar lo que introduce el usuario y compararlo con la clave que tienes en la tabla.

Un Saludo.

[alcides]

Hola marcoszorrilla,
esto es lo que hago para validar mediante un qry el nombre del usuario,
esto lo hago en el on change del campo.

ls_Nombre := Tbl_UsuarioNombre_Usuario.AsString;
Qry_Usuario.Close;
with qry_Usuario do begin
with sql do begin
clear;
add ('select * from Usuario');
add ('where Nombre_Usuario ='+(ls_Nombre));
open;
if recordcount <> 0 then begin
ShowMessage('!!!!!!Nombre de Usuario Incorrecto ');
Abort;
end;
end;
end;

y no me funciona, a ver que estoy haciendo mal

Gracias,

Alcides
Rep.Dom.

[marcoszorrilla]

Código Delphi [-]
  ls_Nombre := Tbl_UsuarioNombre_Usuario.AsString;
   Qry_Usuario.Close;
   with qry_Usuario do begin
   with sql do begin
   clear;
   add ('select * from Usuario');
   add ('where Nombre_Usuario ='+(ls_Nombre));
   open;
    if recordcount = 0 then   begin
      ShowMessage('!!!!!!Nombre de Usuario Incorrecto ');
      Abort;
      end;
   end;
   end;

Un Saludo

[mamcx]

Aprovecho, ahora que la seguridad esta de moda, a apuntar que ese tipo de codigo esta invitando a todo el mundo a hacer una injeccion Sql.... O sea, se puede ingresar a la aplicacion si cracking ni brute-forcing ni nada...

Pillan por que?

[marcoszorrilla]

Conste que yo no utilizo SQL para comprobar las claves.
1.- Se teclea el nombre de Usuario
2.- La clave
3.-Abro tabla usuarios busco el nombre si existe
4.-Compruebo su clave que lógicamente está encriptada.

En caso negativo presento mensaje de error.

Usuario inexistente o clave incorrecta.

Un Saludo.

[mamcx]

Puede que el esquema que tengas sea seguro, pero la mayoria de las veces no es. Injeccion Sql o Injeccion de codigo implica que se esta insertando codigo que ANULA o REEMPLAZA el existente. La mayoria de los sistemas/codigo de Login hechos por personas que no saben que es Sql Injeccion generan una alta probabilidad de que el sistema sea violado.

La injeccion funciona, en el ejemplo presente, asi:


1- El codigo original

Código Delphi [-]
      add ('where Nombre_Usuario ='+QuoteStr(ls_Nombre)));
    open;
     if recordcount = 0 then   begin
       ShowMessage('!!
 !!!!Nombre de Usuario Incorrecto ');

2- Lo que el programador SUPONE que esta pasando

Código SQL [-]
    where Nombre_Usuario = 'Mamcx'

3- Lo que cualquier hacker, o de hecho, un programador con nada que hacer, digitaria en el nombre de usario/clave algo como ' OR 1=1 ''=



4- Lo que va a pasar

Código SQL [-]
     where Nombre_Usuario = '' OR 1=1 OR ''=''

Ahora bien, marcoszorrilla tiene un esquema que PARECE mas seguro, pero quien sabe?. Si la base de datos es Paradox, es probable que si. Si es un motor sql, a lo mejor no.

Si el codigo es:

Código Delphi [-]
    dsUsuarios.Filter:=ls_Nombre;    
      if recordcount = 0 then   begin
          ShowMessage('!!!!!!Nombre de Usuario Incorrecto ');

Le pasa lo mismo. Si es:

Código Delphi [-]
     dsUsuarios.Locate(ls_Nombre...    
       if recordcount = 0 then   begin
         ShowMessage('!!!!!!Nombre de Usuario Incorrecto ');

La anterior injeccion falla (creo. No he probado). Pero se puede trabajar un poco mas. Aun un codigo que use parametros y un procedimiento almacenado o use Locate o Find PUEDE ser suceptible a la injeccion. Ahora, no he probado con Localte o Find, pero seguro que con parametros de texto y SP se puede...

La UNICA forma de estar seguro, es que el usuario/clave tenga una mascara que solo acepte caracteres validos.

[roman]

Empezado por mamcx

esta invitando a todo el mundo a hacer una injeccion Sql

¿Podrías explicar un poco más? Eres la segunda persona en pocos dias que menciona el tema dejando a muchos en ascuas.

Por otra parte, al menos yo no alcanzo a ver dónde está el problema. La consulta sólo da por condición el nombre de usuario así que aun inyectando código sql de manera que se "encuentre" al usuario, la posterior verificación de contraseña fallará.

Si no es así estaré encantado y agradecido de que menciones dónde está la falla.

// Saludos

[mamcx]

Disculpa... solo estaba creando expectacion, nada de quedarme con el secretico...!

Hay varios tipos de ataques, a saber, los Sql Injeccion, los Code/Scripts Injeccion, los Buffer Overrund, etc.. que se valen de que el programador confia en que el usuario/aplicacion esta digitando caracteres validos. Es probable que se haya creado un esquema de validacion de caracteres para las cajitas y de hecho, eso cura en gran medida el mal.

Sin embargo, si la aplicacion es distribuida o es tipo Web, el cliente que usa el usuario NO ES NI TIENE que ser el UNICO cliente posible. O sea, si el codigo de validacion es JavaScript y Ok, se filtran caracteres invalidos. Pero el hacker simplemente analiza hacia donde van los Request de la pagina y coje los QueryString o el Form y manda el mismo la solicitud. Si SOLAMENTE en el cliente se valido, el servidor quedara expuesto... quiere decir, se debe volver a revalidar en el servidor toda entrada que PUEDA ser digitada por un usuario, incluyen las URL, los QueryString, las cajas, combos, etc Y LOS CAMPOS ESCONDIDOS (que aproposito se usan para hacer suplantaciones bien bizarras).

Ahora, estos problemas son mas grandes en las aplicaciones Web y distribuidas, no tanto en las Desktop pero es bueno ir haciendose a la practica