Lo siento, no era un reclamo sino una forma de expresar mis observaciones sobre lo que me parecía una visión reduccionista del problema.
Cita: Si es un error fatal porque la informacion queda a plenitud del usuario que ingrese, igual si creara 1 o 5 usuarios adicionales de los administradores por defecto de cada manejador, no seria mejor crear uno por cada usuario que tenga el sistema?
Esa es precisamente la forma correcta de hacerlo: Un user por cada usuiario de la página, con permisos permisos restrictuivos para acceder a las tablas de la base.
Y atención, estoy hablando de acceder
a las tablas y no de acceder
a la base.
Esa es precisamente la ventaja de los DBMS, y que, garantizo, MySQL maneja muy bien.
Cita: esto se puede hacer igual si uno valida los usuarios desde tabla tambien puede volver algo seguro el ingreso,
En realidad no, porque con el user y algún trabajo puedes acceder a la base por fuera de la aplicación, por lo que la seguridad implementada por medio de tablas propias dependerá de lo finamente programado de la aplicación misma.
No es lo mismo.
Te cuento algo de las experiencias en la empresa en que trabajo:
En uno de los proyectos que usamos tenemos un usuario que tiene permisos sólo para ver una tabla, porque es en esa sola tabla donde está la información que grabará. Esa misma tabla se usa luego para habilitarlo como user de la base (restringido a tres tablas solamente), pero la tarea de darle alta sólo la tiene otra categoría de usuario del sistema y nadie más. Y no es una tarea On-Line.
Todo esto permite que si el user entrase por fuera de la página, sólo podría ver esa tabla, que de todos modos tiene información encriptada, y es transitoria...
A otro nivel, otro de los proyectos (multiusuario y de acceso remoto, tiene implementada la seguridad de usuarios en varios niveles.
Por un lado, sólo dos categorías de usuarios peuden crear usuarios, y ninguno puede crear un superusuario. Y los usuarios que pueden crear tienen perfiles fijos, y no se pueden modificar por fuera del sistema (tienen cuádruple certificación).
Por otro lado, sólo el root puede crear esos dos usuarios, y sólo a través de la interfase programada, porque el algoritmo de encriptación no es de MySQL.
Además, la mayoría de los usuarios no tienen permisos para acceder más que a una tabla (sesiones), y sólo pueden ver sesiones dentro de la interfase (están encriptadas); el resto de las tareas se realizan por stored procedure, por lo que no tienen acceso al código, ni pueden hacer nada que el SP no contenga.
El sistema es suficientemente restrictivo para el acceso a datos de modo que ni accediendo a la misma tabla, dos personas pueden llegar a leer la misma información si no pertenecen a la misma categoría del mismo lugar de trabajo.
Como estas tareas son por SP, y dentro de la aplicación está todo creado por parámetros (no hay invocaciones a tabas ni a sentencias), el sql-injection no hace efecto porque cualquier cosa que le quieras insertar sólo genera errores, y si quieres reemplazar el nombre del SP por una sentencia, también, porque el objeto creado es un StoredProcedure y no un string...
O sea, hemos tratado de hacer el sistema lo mas impenetrable posible, y creemos haber hecho un buen trabajo, aunque nos ha llevado casi dos años afinarlo, porque el requisito esencial era que debía estar creado en MySQL...
Ojalá hubiese sido en otra cosa, no hubiésemos tenido que crear tantas cosas.