Control de usuarios

[anubis]

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]]

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]

Buscaré en los foro s de nuevo.
Gracias

[anubis]

Empezado por anubis

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 Notevi]

Exactamente, ¿qué duda tienes, anubis?

[Neftali [Germán.Estévez]]

Empezado por anubis

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.

Empezado por anubis

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]]

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]]

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]

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 Notevi]

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

[[Lepe]]

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

[Casimiro Notevi]

[mamcx]

Empezado por Lepe

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

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)

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 Notevi]

[anubis]

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

[anubis]

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]

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]

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 Notevi]

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]

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.