5 respuestas en este tema

[Gaston]

Pues eso, me pidieron que implemente usuarios y contraseñas en mis programas. Además unos campos extras para en base al nivel de usuario, las operaciones que puede realizar. Eso no es problema, el tema es donde guardo de manera "lo más segura posible" los datos, se me ocurrió un binario, pero acudo a ustedes para que me digan si sirve o no. Como utilizo SQLite, debo encontrar algo que no implique bases de datos.

 

Saludos.

[seoane]

Una forma simple es guardar en donde tu quieras (un fichero de texto, un .ini, un xml, etc...) el nombre de usuario, permisos y un hash.

 

Por ejemplo, si el usuario es "pepe", su contraseña es "clave", y su rol es "administrador" podemos guardar en un fichero:

pepe;administrador;b6b93c125ee897ec079eb40a483b5f8ca9229f5e033976c43f7ea35c35e85c95

 

El hash del final lo calculamos como sha256(pepe;calve;administrador;secreto)  donde "secreto" es un codigo que solo "conoce" nuestro programa.

 

Asi si alguien abre el fichero solo podria conocer los nombres de los usuarios, pero no podria conocer sus contraseñas, ni cambiar ni sus permisos sin que el hash quedara invalidado.

 

Claro esta que si alguien analizara el codigo en ensamblador de nuestro programa instruccion a instruccion podria descubrir como se calcula el hash, pero contra eso no hay ningun sistema invulnerable. Ademas que pocas personas sabrian hacerlo

 

Saludos

[Delphius]

Algunas buenas prácticas:

1. Las contraseñas JAMAS se guardan. Sobre todo cifradas. En su lugar se almacena un hash que se obtiene como función de ésta. Esto permite que no pueda ser reversible.

2. Por consiguiente se debe emplear algoritmos de reducción hash.

3. Por lo que más quieras, no inventes tu propio algoritmo. Usa algoritmos fuertes, estándares y ya conocidos y probados.

4. Además de usar un algoritmo hash estándard asegúrate de que el mismo acepte Salt.

5. Incorpora mecanismos de doble autenticación.

6. Añade elementos de seguridad alrededor del archivo, db, registro, etc. o el medio del cual te sirvas para guardar la data. De nada sirve poner los mejores algoritmos hash+salt si al final cualquiera puede hacerse del archivo. Por ej, usar perfiles de usuario a nivel SO para impedir que se tenga acceso al directorio.

7. Piensa en la seguridad física primero antes la lógica. Sobre todo si tus aplicaciones corren en C/S y sobre todo si es un servidor dedicado. Hay que reducir y limitar los potenciales puntos de acceso a la infraestructura.

8. Enseña y educa a los usuarios. Son la cadena más débil. Muchos ataques se hacen por ingeniería social. De que sirve tanta seguridad si luego el usuario tendrá pegado un papelito en su escritorio el user+password, además debe de evitarse el compartir cuentas... ¿Sabes como se hizo uno de los mayores ataques a una Central Nuclear? No se requirió de un gran super hacker... simplemente se tenía un equipo que hizo inteligencia y vigilancia a la persona indicada. Una vez robada la contraseña se entró y se enviaron e-mails con virus en archivos adjuntos... algún 2do cayó en la trampa, activo el gusano y pum.

 

Ahora que leíste estos puntos te invito a leerlos en el orden inverso   Listo. Ya sabes por donde debes comenzar a hacer las cosas.

 

Saludos,

[Gaston]

Gracias seonae y Dilphius por las sugerencias, empezaré a probar lo más simple, un archivo de texto o un ini con el pass cifrado.

 

 

8. Enseña y educa a los usuarios.

 

Imposible, son de los que dejan el papelito con las claves pegados al monitor, se pasan las claves, etc... es decir todo mal y no puedo hacer nada, o lo acepto así o me voy y aparece otro programador que no le molesta.

 

En realidad lo quieren para tener un control interno de quienes hacen que cosas, y también para limitar a ciertos usuarios a que por ejemplo tengan acceso solo a los reportes. Obvio tendré que, mediante triggers, llevar un control de todo en una tabla, pero me estoy yendo por las ramas.

 

Veré que me sale y luego lo posteo aquí mismo.

 

Saludos.

[Delphius]

¿Cifrado? Había comentado que no se debe cifrar.

Y un ini no me parece la mejor opción. Muy fácil de editar y que le metan mano.

Saludos

[Gaston]

¿Cifrado? Había comentado que no se debe cifrar.

Y un ini no me parece la mejor opción. Muy fácil de editar y que le metan mano.

Saludos

 

Toda la razón Delphius, en realidad no es crifrado, me expresé mal, es un hash.

Y tampoco será un ini, será una tabla en SQLite, más difícil de editar, no para nosotros, pero sí para el usuario común. De paso me simplifico la elaboración de los reportes.

 

Una vez más no sabía como encarar el tema y me ayudaron. Muchas gracias.

 

Saludos.