Como validar Acceso al sistema

[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.

[marcoszorrilla]

Yo en concreto a lo que se teclea le aplico el algoritmo correspondiente para convertirlo en algo ilegible que compararé con la clave de igual a igual, por lo tanto es indiferente que tecleen por ejemplo el signo =.

Por otra parte no uso ningúna máscara para que puedan teclear cualquier cosa y así sea más dificil econtrar la clave por azar.

A los 3 intentos fallidos el sistema se cierra por completo.

A pesar de todo, pienso que cualquier Hacker, quer merzca ese nombre se saltaría la clave sin mucha dificultad. (la mía).

Recuerdo hace tiempo que con un amigo discutíamos acerca de la seguridad de cualquier sistema, en mi opinión si hay verdadero interés por saber algo se sabrá y no hay clave que se resista ·$$$$$$$.

Un Saludo.

[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

[marcoszorrilla]

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

No hay nada que disculpar hombre, es muy interesante el tema que se está abordando y han sido muy oportunas tus pinceladas acerca de los posibles ataques contra la seguridad.

Yo recuerdo haber visto un programa que pulsando sobre un edit revelaba la clave tecleada aunque solamente se estuvieran mostrano asteriscos.

Un Saludo.

[roman]

Sí, sí. Entiendo eso pero sigo sin ver, aún permitiendo la inyección, cómo va a poder acceder al sistema estando de por medio la verificación de contraseña.

Es decir, si mi consulta es

Código SQL [-]
select usuario, password from usuarios
where usuario = :usuario

inyectando los caracteres que mencionas, ciertamente la consulta me va a regresar registros.

Pero si después de ello hago algo como

Código Delphi [-]
if DataSet['password'] <> EditPassword.Text then
  abort;

o mejor aún

Código Delphi [-]
if DataSet['password'] <> Encrypt(EditPassword.Text) then
  abort;

¿entonces de qué sirve haber inyectado caracateres?

// Saludos