Creo que te estás complicando demasiado sin necesidad ;)
Los usuarios los controlas mediante una simple tabla de usuarios: codigo, nombre, login, password. Donde el password lo puedes guardar cifrado, no creo que necesites complicarte más.
Luego, lo normal, al iniciar el programa pides login y password, compruebas que son correctas y listo.
Además puedes tener una tabla de permisos para cada opción del programa. Por ejemplo, ahí ya puedes extenderte según lo que necesites para cada usuario le permites entrar (o no entrar) en ventas, informes, etc. Tienes montones de formas de hacerlo, algo simple puede ser una tabla de permisos: codigo, opcion, usuario, permitir-sn. Por lo que tendrías registros del tipo:
1, 10, 1, S
2, 20, 1, N
3, 30, 1, S
4, 10, 2, N
...
También puedes tener una tabla de las distintas opciones, lo que antes he indicado como 10, 20, 30: tabla opciones: codigo, opcion.
10, Ventas
20, Compras
30, Informes
40, ...
Pero todo esto depende de lo que necesites, lo mismo te sobra que te falta, debes evaluarlo tú mismo.

Si quieres aprender y tienes tiempo, hazlo con Lazarus en Linux, también existen los componentes IBX para Lazarus en Linux.
Si tienes prisa, hazlo con lo que mejor conoces.

Muchas, gracias casimiro lo probaré así como dices.
Y si, ya, probé los ibx en Linux pero de csmbiar el puerto 3050 por otro no de puede :(

¿No se puede cambiar el puerto? ¿y eso?
Por cierto, ¿para qué quieres cambiarlo?

Tienes el escenario mas facil y mas dificil: Que tu seas el cliente (ppal), y aun no sabes que hacer. Bueno, ya entenderas porque los clientes nos la ponen dificil: Si ni nosostros mismos nos entendemos ;)

Asi que coincido con Casimiro que hay que acotar los requerimientos.

La cosa es que te estas enruedando con detalles de implementacion e infraestructura, en vez de lo que *realmente* daria valor a ese proyecto.

Como te dije: Tener usuarios y claves no es seguridad. Es TOTALMENTE posible tener una app segura, y no implementar este tema.

Si los usuarios que usan un sistema son *confiables*, entonces para que hacer que le den vuelta a todo? Pon la autenticacion a nivle del OS (ie: Que usen las claves del windows/linux como usuarios, y que la tengan al entrar a salvapantallas) e integrar "autenticacion integrada" entre el OS y la BD. Pfff!! Un modulo menos que hacer.

----

Si no te quieres enruedar mucho, te recomiendo que uses una herramienta como https://trello.com/, y pongas una tarea por cada cosa que tengas que hacer en la app. Usas mockups y conversa con la gente como quieres hacer todo. Desahcer/rechacer el programa en esta etapa es trivial.

Y lo importante:

Preguntate: Esto que voy a hacer es CRUCIAL y provee VALOR al proyecto/usuarios? O es solo una excusa que me estoy poniendo pa irme por las ramas? O es solo algo que *creo* que tengo que hacer *ya* pero que puedo dejar para *luego*?

Como este tema, puedes tomarte algo de tiempo para entenderlo bien. MIentras es muy dificil "meter la seguridad" en una app insegura, la realidad es que como te explique "una app segura es una app correcta". Si el codigo es correcto, desacoplado y simple, asegurarlo es trivial.

Y con lo de windows o linux: Da igual, excepto si el usar uno u otro impacta negativamente a tus usuarios. Es lo mismo: Es usar sistema operativo X crucial y provee VALOR al proyecto/usuarios, o es solo una excusa que me estoy poniendo pa irme por las ramas?

Sobre hash ó encriptar, creo mamcx ha dado sus razones bien fundadas... pues vale, se encripta. En la práctica se resume a llamar a una función que hace un hash o a otra que encripta, así que no hay que darle más vueltas.

No sé si Interbase puede o no cambiarse el puerto. Firebird viene de Interbase 6 y en el archivo Firebird.conf se le puede cambiar el puerto perfectamente. También puedes usar los componentes IBX en Delphi para trabajar con Firebird 2.5 (aunque claro está no puedes usar todas las funcionalidades de Firebird porque IBX no las implementa, te permite hacer un programa completo, con triggers, procedimientos almacenados, eventos, excepciones, etc).

El databaseName sería: <servidor><puerto>:<ruta de la base de datos o alias>
osea: 192.168.0.10/2525:MiFarmacia

donde:
- la IP es la del servidor donde el servidor Firebird está instalado
- /2525 es el puerto por el que el servidor Firebird está escuchando
- "MiFarmacia" es un alias a la base de datos, se define en Firebird.conf también. Así no se sabe en qué carpeta del servidor está la Base de datos. También se puede poner la ruta local de la Base de datos c:\miprograma\BBDD\mifarmacia.fdb

Saludos

Y de ser el caso, el puerto se puede cambiar a nivel de router.

Tenéis, razón en todo la verdad. Efectivamente poniendo el host así si traga. Gracias a todos, voy a poner en práctica todo lo q, habéis dicho y os voy comentando, aunque creo q abriré otro post

Pregunto, otra vez :), ¿para qué quieres cambiar el puerto?

Casimiro, sé que no me preguntas a mí, pero me meto en todo :D

En mi caso es otra aplicación que usa una distribución de Firebird "personalizada", lo pongo entre comilla porque no han seguido las instrucciones que vienen en Firebird\docs para ese menester, así que le han puesto el nombre de su empresa al servicio de Windows "Firebird_MiEmpresa", pero nada mas.

Tras semanas de investigar por qué nuestro programa falla "algunas veces" en "algunas empresas" resulta que al ser el mismo ordenador servidor, corriendo dos Firebirds de instalación standar, por el mismo puerto, con el mismo nombre de instancia de Firebird...pues tú me dirás...

Solución: Seguir lo que dice en <Firebird>\docs\ para crear un Firebird personalizado para tu aplicación. No servía Alias ni ficheros de configuración por temas de los que no puedo hablar.

mamcx: En mi caso lo del router no me valía. El otro programa no recibiría ningún paquete, aunque confieso que no me importaría hacerlo :D:D

Saludos!

Los amigos tienen permiso para meterse en todo :p
Por cierto, ¿por qué tienes más de un firebird en un mismo servidor? No le veo sentido.