Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Lazarus, FreePascal, Kylix, etc. (https://www.clubdelphi.com/foros/forumdisplay.php?f=14)
-   -   Control de usuarios (https://www.clubdelphi.com/foros/showthread.php?t=89362)

anubis 09-11-2015 00:37:17

Control de usuarios
 
Estuve buscando pero no encontré alguna respuesta indicada.
La recomendación, en firebird, algunos di es guardse las contraseñas en una tabla de la, bd pero no lo veo conveniente, alguna idea de si hay otra opción?.
Por otro lado, para controlar los permisos o a q partes pueden estsr autorizados, eso se vería, o, sería más bien como un array?

Gracias a, todos

AgustinOrtu 09-11-2015 00:51:29

En realidad se ha hablado por los foros

Hay muchas formas de implementarlo. Una clasica y facil pero no lo mas flexible que gustaria, es almacenando un flag integer separando en modulos tu programa; luego cuando inicializas los formularios activas/desactivas botones, actions, etc

anubis 09-11-2015 01:37:16

Buscaré en los foro s de nuevo.
Gracias

anubis 09-11-2015 01:40:43

Cita:

Empezado por anubis (Mensaje 499052)
Buscaré en los foro s de nuevo.
Gracias

Perdón. Se agradece la respuesta, veré si hay más respuestas de lo mismo en los foros. Y de paso veré esa, opción q me dices porque ando bloqueado.

Casimiro Noteví 09-11-2015 09:43:36

Exactamente, ¿qué duda tienes, anubis?

Neftali [Germán.Estévez] 09-11-2015 12:10:57

Cita:

Empezado por anubis (Mensaje 499049)
La recomendación, en firebird, algunos di es guardse las contraseñas en una tabla de la, bd pero no lo veo conveniente

¿Porqué no lo ves conveniente?
Es un dato como otro cualquiera (visto informáticamente y a la hora te tratarlo) por lo tanto hay que hacer con él lo mismo que harías con los otros; Guardarlo en la Base de Datos.
Al ser contraseñas, lo lógico es que estén encriptados, pero por lo demás es como cualquier otro.


Cita:

Empezado por anubis (Mensaje 499049)
para controlar los permisos o a q partes pueden estsr autorizados, eso se vería, o, sería más bien como un array?

Dependerá de qué quiereas controlar y como.
En ese sentido das muy pocos detalles para saber qué estructura se debería almacenar.
En cuanto a lo que comentas de que "eso se vería", pues se aplica lo mismo dicho anteriormente. Si es necesario, se encripta el dato y listo.

AgustinOrtu 09-11-2015 15:24:20

Habría que preguntarle al jefe que información considera de carácter más sensible, si las contraseñas o "todo lo demás" :)

AzidRain 10-11-2015 01:17:33

Busca UserControl Components, es un componente brasileño que anda por ahi y que viene con fuentes y todo. Hace todo lo necesario para controlar usuarios y maneja solito toda la gestión de los mismos sin que metas ni una sola línea de código. Yo los uso desde hace años y nunca me han dado problemas.

anubis 13-11-2015 06:45:48

Gracias por las respuestas.

Pues veréis, es muy gracioso porque tenemos instalado en la empresa una aplicación en la, q la base de datos esta en firebird instalada en el servidor y sin csmbiar la clave por defecto. Con un control de usuarios donde se guardan en una, tabla dentro de la misma base de datos y sin encriptar las contraseñas por lo q es muy fácil verlas. De ahí q preguntara si era conveniente o no hacerlo así.
Evidentemente mi idea era meter la base de datos en un servidor sin acceso físico, csmbiar la clave maestra, cambiar el puerto y ponerle alias.

Por otro lado, la respuesta de Flags me parece interesante a falta de otra idea, como la, del componente brasileño q recomendáis q lo voy a buscar.

Ya os diré como me fue

Gracias amigos.

Casimiro Noteví 13-11-2015 09:47:10

Por supuesto, las claves y campos "críticos" hay que guardarlos cifrados,

Lepe 13-11-2015 23:33:45

Las contraseñas se debería hacer un hash en lugar de cifrar... me explico:

pides usuario y contraseña, haces un hash de la contraseña y comparas ese hash con el que está en la Base de datos. Si se hace con el nombre de usuario, mejor.

Se hace así porque no hay posibilidad de "desencriptar" y como dato sensible que es, nadie debería saber qué contraseña usa el usuario o el administrador del programa. Por supuesto debe haber una opción para "resetear" o machacar la contraseña actual si eres el administrador.

Lo del hash al nombre de usuario es porque si alguien ve que hay un usuario "pablo" y sabe el día que nació su hija... pues ya sabe la contraseña :p

Casimiro Noteví 13-11-2015 23:38:37

^\||/^\||/^\||/

mamcx 14-11-2015 00:19:38

Cita:

Empezado por Lepe (Mensaje 499329)
Las contraseñas se debería hacer un hash en lugar de cifrar... me explico:

Se hace así porque no hay posibilidad de "desencriptar" y como dato sensible que es, nadie debería saber qué contraseña usa el usuario o el administrador del programa.

No. Casi-correcto, pero casi-correcto en seguridad es igual a incorrecto ;).

Cuando hay que proteger un dato? Se encripta. Hashear hace parte del proceso en algunas formas, pero un hash no es seguro.

Un hash es:

https://en.wikipedia.org/wiki/Hash_function
Cita:

A hash function is any function that can be used to map data of arbitrary size to data of fixed size.
Es posible deducir el valor de un hash? Por supuesto. De hecho se hace TODO EL TIEMPO. Le suenan las "hash tables"?.

Asi que luego piensan: "Claro hombre, es que hay que saltear!". Y si se pega/copia sin pensar un ejemplo en la web, puedes terminar con algo errado:

https://en.wikipedia.org/wiki/Salt_(cryptography)
Código:

A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function
Noten que menciona: Por cada password, saltear (muchos ejemplos tienen un salt global), y que se debo usar un hash criptografico (ie: probado para encriptar).

Por lo tanto "hash sin cifrar" es todo lo contrario de lo que se debe usar para guardar un password.

P.D: Para los que no estan al tanto: PBKDF2, bcrypt, scrypt son los que se pueden usar. Utilizar una libreria confiable hecha por expertos. JAMAS hacer "encriptacion" de tipo casera en un entorno serio de produccion. Si leen este mensaje en unos meses, es probable que todas o algunas de las funciones mencionadas dejen de ser seguras! Siempre chequea cuando es cosas de seguridad y no creas ciegamente lo que te dicen, aun cuando lo diga YO!

----

Tener usuario/clave NO ES SEGURIDAD.

Autenticación, autorización, privacidad, integridad, seguridad son conceptos relacionados pero diferenciados.

----

Hacer una app segura es basicamente decir que es una app *correcta*. Por ejemplo, las injecciones SQL existen porque se usan cadenas de texto cuando realmente se quiere decir fragmentos de un lenguaje SQL. Osea, es una falla de asignar el tipo errado al dato.

De igual manera, mantener la privacidad/integridad de la informacion es lo mismo que hacer una app *correcta*. Si es posible acceder a los datos remotamente, y se cree que "mis claves tienen hash salteados!" es lo que lo hace seguro, es asignar el acceso errado al dato.

Casimiro Noteví 14-11-2015 00:29:07

^\||/^\||/^\||/

anubis 14-11-2015 01:11:49

Y eso como se hace, q quedaría guardsdo o como

anubis 15-11-2015 06:31:40

No se si sera correcto, pero lo que hice fue usar en lazarus el componente FBAdmin, que me permite tratar directamente con los usuarios almacenados directamente en firebird y solo voy a meter los usuarios encriptados en una tabla de la base de datos para asignarles flag en base a que opciones pueden o no usar.

Si lo veis correcto?.

Gracias

mamcx 15-11-2015 18:07:54

Programar al estilo voodo ("pinchemos a ver donde duele") nunca es buena idea. Al igual que siempre, el camino a la respuesta correcta es la pregunta correcta. Del mismo modo, cual, exactamente, es el problema que tienes?

Especificamente:

Que es lo que pretendes proteger?

Aunque seguramente terminaras usando librerias/componentes hechos por otros, sino tienes claro que es lo que quieres proteger, no sabras si al usuarlo estaras haciendo bien o mal...

anubis 16-11-2015 20:42:54

Hola,
Mira la base de datos esta, alojada en un, servidor al, q no tienen acceso físico. Los datos, la verdad no se cuales se deben o no de proteger, solo es para desarrollar o mejorar el producto, que, finalmente, es transparente para el usuario final, solo podrá acceder a, donde se le permita

Casimiro Noteví 16-11-2015 20:49:58

No sé si no te entiendo, pero tú tienes que saber PERFECTAMENTE qué requiere el cliente para poder decidir qué vas a hacer y cómo vas a hacerlo.
Si tú no conoces PERFECTAMENTE los requerimientos del cliente, luego te encontrarás con los problemas típicos de: "Eso no es lo que yo quería", "Yo esperaba que esto funcionase de otra forma", "Esto no se parece a lo que hablamos", etc.

anubis 17-11-2015 04:59:36

Gracias por todas las respuestas,

Vereis todavia no se como voy a hacer todo el programa.
Nose si lo voy a hacer en linux o windows, nose que componente usar para firebird, que es con lo que me muevo, porque usaba zeos que es multibase, pero queria usar el que trae por defecto lazarus o bien los componentes ibx que segun, son mas rapidos pero estos ultimos no dejan cambiar el puerto por defecto.

Asi que el cliente digamos que soy yo mismo, la verdad, mi mujer con otros socios van a poner una farmacia y lo que van a querer es lo normal para cualquier empresa de ventas de productos, que no lo tengo complicado, ya hice una parecida para una tienda, pero en este caso queria perfeccionarla mas y no andar con parches posteriores.

La estructura la tengo mas o menos hecha, pero me falta implementarla.

Por eso preguntaba la mejor manera de gestionar usuarios, tanto al solicitar el login y contraseña (que ya me habeis dicho que las encripte, algunos con hash y otros decis que no).

Mi idea inicial era esa, tener la base de datos en un servidor, con la base de datos en alias y luego el programa cliente que acceda a ella. Quiza encriptar el archivo ini que es donde va a estar los parametros de conexion para que no se vean.
Lo de usar linux es simplemente por experimentar pero me vais a decir que si experimento y no funciona el sistema se podria caer sino lo domino.

Asi que bueno, resumiendo las posiblidades que me habeis dado podria hacer lo siguiente:

Encriptar los usuarios y las passwords de la base de datos,
usar flags en una tabla para ver bien a que pueden acceder los usuarios o que se les permite.

De ahi ir viendo las opciones que van saliendo.

Si bien es cierto que algunas cosas de este post no debieran de ir aqui, si las comento de pasada.
Si estuve buscando tambien la opcion de conectar una terminal bancaria al programa pero creo que es muy complicado y la otra opcion seria la de facturacion; como no estoy registrado en hacienda como generador, tengo que buscar un programa de facturacion registrado para que, con una pasarela o intermediario, le pase los datos para la factura.

disculpadme de verdad por tanta pregunta y muchas gracias por todas las respuestas.


La franja horaria es GMT +2. Ahora son las 20:48:25.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi