manejo de contraseñas en sql server

10/12/2004 - 21:28 por Juan Carlos | Informe spam
Hola:

Tengo una duda de como diseñar la parte de seguridad para una aplicación que
usa SQL Server.

Para un sistema que estamos construyendo es parte de los requerimientos de
alguna forma manejar usuarios y contraseñas de acceso al programa, donde
además los usuarios y contraseñas tienen que caducar cada cierto tiempo
configurable, y que cuando las contraseñas hayan caducado, el sistema le
pueda ofrecer al usuario cambiar la contraseña.

Este sistema hace uso de SQL Server 2000 para almacenar/recuperar los datos.
Los datos van a ser principalmente un registro (una especie de "log" ) de
operaciones llevadas a cabo por los usuarios. La aplicación va a correr en
un conjunto chico de PCs dedicados que usan un SQL server para acceder a los
datos.
Para todos los registros de la base de datos se tiene que tener el usuario
que ejecuto la operacion (el registro "registra" esa operación).
Como dije, los PCs son dedicados y no existe un servidor de dominio en la
red. Todas las máquinas tendrían Windows XP.

La duda me surge es cuál es la mejor forma de hacer este manejo de
usuarios/contraseñas tanto para el acceso al sistema como para la base de
datos. No tengo mucha experiencia en estas cosas, asì que agradezco su
ayuda.

Se me ocurren por ejemplo:
1) Que la autenticación al sistema sea a través del sistema operativo, que
el acceso a la base de datos sea un acceso "integrado" y que el manejo de la
caducidad de usuarios y contraseñas se haga en el servidor (Windows XP).
2) Que la autenticación al sistema se haga contra el SQL Server, que en SQL
Server se haga todo el manejo de usuarios/contraseñas. El tema de la
caducidad no sé como sería (no sé si se puede hacer ese control en SQL
Server).
3) Que todo el tema de usuarios/permisos/caducidad sea manejado por la
aplicación (lo que no implica que no sea almacenado en la base de datos) y
el acceso a la base de datos sea con un usuario y contraseña "hardcodeados"
(fijos para la aplicación).

Saludos,
Juan Carlos

Preguntas similare

Leer las respuestas

#1 Maxi
10/12/2004 - 21:37 | Informe spam
Hola, mira lo mejor seria usar seguridad integrada y darle al SO el manejo
que estas comentando. Esto es valido si todas las estaciones de trabajo son
clientes Windows, de lo contrario no podras aprovechar esta ventaja :(

Otro tema es la autentificacion a la aplicacion ( o sea, que cosas puede o
no hacer dicho usuario dentro de esta ), esto tambien lo podrias hacer con
seguridad integrada o bien guardar los registros en una tabla y ahi
establecer los permisos.


Salu2
Maxi


"Juan Carlos" escribió en el mensaje
news:
Hola:

Tengo una duda de como diseñar la parte de seguridad para una aplicación
que
usa SQL Server.

Para un sistema que estamos construyendo es parte de los requerimientos de
alguna forma manejar usuarios y contraseñas de acceso al programa, donde
además los usuarios y contraseñas tienen que caducar cada cierto tiempo
configurable, y que cuando las contraseñas hayan caducado, el sistema le
pueda ofrecer al usuario cambiar la contraseña.

Este sistema hace uso de SQL Server 2000 para almacenar/recuperar los
datos.
Los datos van a ser principalmente un registro (una especie de "log" ) de
operaciones llevadas a cabo por los usuarios. La aplicación va a correr en
un conjunto chico de PCs dedicados que usan un SQL server para acceder a
los
datos.
Para todos los registros de la base de datos se tiene que tener el usuario
que ejecuto la operacion (el registro "registra" esa operación).
Como dije, los PCs son dedicados y no existe un servidor de dominio en la
red. Todas las máquinas tendrían Windows XP.

La duda me surge es cuál es la mejor forma de hacer este manejo de
usuarios/contraseñas tanto para el acceso al sistema como para la base de
datos. No tengo mucha experiencia en estas cosas, asì que agradezco su
ayuda.

Se me ocurren por ejemplo:
1) Que la autenticación al sistema sea a través del sistema operativo, que
el acceso a la base de datos sea un acceso "integrado" y que el manejo de
la
caducidad de usuarios y contraseñas se haga en el servidor (Windows XP).
2) Que la autenticación al sistema se haga contra el SQL Server, que en
SQL
Server se haga todo el manejo de usuarios/contraseñas. El tema de la
caducidad no sé como sería (no sé si se puede hacer ese control en SQL
Server).
3) Que todo el tema de usuarios/permisos/caducidad sea manejado por la
aplicación (lo que no implica que no sea almacenado en la base de datos) y
el acceso a la base de datos sea con un usuario y contraseña
"hardcodeados"
(fijos para la aplicación).

Saludos,
Juan Carlos


Respuesta Responder a este mensaje
#2 Gustavo Larriera [MVP]
10/12/2004 - 21:46 | Informe spam
Si vas a programar usando .NET, te recomiendo que consideres usar el
Authorization and Profile Application Block.

http://msdn.microsoft.com/library/d...uthpro.asp

Gustavo Larriera, MVP
Uruguay LatAm
http://sqljunkies.com/weblog/gux/
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.
"Juan Carlos" wrote in message
news:
Hola:

Tengo una duda de como diseñar la parte de seguridad para una aplicación
que
usa SQL Server.

Para un sistema que estamos construyendo es parte de los requerimientos de
alguna forma manejar usuarios y contraseñas de acceso al programa, donde
además los usuarios y contraseñas tienen que caducar cada cierto tiempo
configurable, y que cuando las contraseñas hayan caducado, el sistema le
pueda ofrecer al usuario cambiar la contraseña.

Este sistema hace uso de SQL Server 2000 para almacenar/recuperar los
datos.
Los datos van a ser principalmente un registro (una especie de "log" ) de
operaciones llevadas a cabo por los usuarios. La aplicación va a correr en
un conjunto chico de PCs dedicados que usan un SQL server para acceder a
los
datos.
Para todos los registros de la base de datos se tiene que tener el usuario
que ejecuto la operacion (el registro "registra" esa operación).
Como dije, los PCs son dedicados y no existe un servidor de dominio en la
red. Todas las máquinas tendrían Windows XP.

La duda me surge es cuál es la mejor forma de hacer este manejo de
usuarios/contraseñas tanto para el acceso al sistema como para la base de
datos. No tengo mucha experiencia en estas cosas, asì que agradezco su
ayuda.

Se me ocurren por ejemplo:
1) Que la autenticación al sistema sea a través del sistema operativo, que
el acceso a la base de datos sea un acceso "integrado" y que el manejo de
la
caducidad de usuarios y contraseñas se haga en el servidor (Windows XP).
2) Que la autenticación al sistema se haga contra el SQL Server, que en
SQL
Server se haga todo el manejo de usuarios/contraseñas. El tema de la
caducidad no sé como sería (no sé si se puede hacer ese control en SQL
Server).
3) Que todo el tema de usuarios/permisos/caducidad sea manejado por la
aplicación (lo que no implica que no sea almacenado en la base de datos) y
el acceso a la base de datos sea con un usuario y contraseña
"hardcodeados"
(fijos para la aplicación).

Saludos,
Juan Carlos


Respuesta Responder a este mensaje
#3 Juan Carlos
10/12/2004 - 22:07 | Informe spam
Bueno, muchas gracias por la respuesta.

¿Para la parte de registrar quien hizo cada cambio que seria mejor?
¿Uso triggers que setean automáticamente para cada registro quién fue el
usuario que lo originó (a nivel de base de datos) o lo inserto desde la
aplicación (por ejemplo obteniendo el usuario desde la variable de entorno
"USERNAME")?

La parte de autenticacion "en la aplicación" con seguridad integrada sería
definiendo grupos a nivel del sistema operativo y obteniendo el grupo desde
el sistema operativo?

Gracias,
Juan Carlos.


"Maxi" escribió en el mensaje
news:u1$h$
Hola, mira lo mejor seria usar seguridad integrada y darle al SO el manejo
que estas comentando. Esto es valido si todas las estaciones de trabajo


son
clientes Windows, de lo contrario no podras aprovechar esta ventaja :(

Otro tema es la autentificacion a la aplicacion ( o sea, que cosas puede o
no hacer dicho usuario dentro de esta ), esto tambien lo podrias hacer con
seguridad integrada o bien guardar los registros en una tabla y ahi
establecer los permisos.


Salu2
Maxi


"Juan Carlos" escribió en el mensaje
news:
> Hola:
>
> Tengo una duda de como diseñar la parte de seguridad para una aplicación
> que
> usa SQL Server.
>
> Para un sistema que estamos construyendo es parte de los requerimientos


de
> alguna forma manejar usuarios y contraseñas de acceso al programa, donde
> además los usuarios y contraseñas tienen que caducar cada cierto tiempo
> configurable, y que cuando las contraseñas hayan caducado, el sistema le
> pueda ofrecer al usuario cambiar la contraseña.
>
> Este sistema hace uso de SQL Server 2000 para almacenar/recuperar los
> datos.
> Los datos van a ser principalmente un registro (una especie de "log" )


de
> operaciones llevadas a cabo por los usuarios. La aplicación va a correr


en
> un conjunto chico de PCs dedicados que usan un SQL server para acceder a
> los
> datos.
> Para todos los registros de la base de datos se tiene que tener el


usuario
> que ejecuto la operacion (el registro "registra" esa operación).
> Como dije, los PCs son dedicados y no existe un servidor de dominio en


la
> red. Todas las máquinas tendrían Windows XP.
>
> La duda me surge es cuál es la mejor forma de hacer este manejo de
> usuarios/contraseñas tanto para el acceso al sistema como para la base


de
> datos. No tengo mucha experiencia en estas cosas, asì que agradezco su
> ayuda.
>
> Se me ocurren por ejemplo:
> 1) Que la autenticación al sistema sea a través del sistema operativo,


que
> el acceso a la base de datos sea un acceso "integrado" y que el manejo


de
> la
> caducidad de usuarios y contraseñas se haga en el servidor (Windows XP).
> 2) Que la autenticación al sistema se haga contra el SQL Server, que en
> SQL
> Server se haga todo el manejo de usuarios/contraseñas. El tema de la
> caducidad no sé como sería (no sé si se puede hacer ese control en SQL
> Server).
> 3) Que todo el tema de usuarios/permisos/caducidad sea manejado por la
> aplicación (lo que no implica que no sea almacenado en la base de datos)


y
> el acceso a la base de datos sea con un usuario y contraseña
> "hardcodeados"
> (fijos para la aplicación).
>
> Saludos,
> Juan Carlos
>
>


Respuesta Responder a este mensaje
#4 MAXI
10/12/2004 - 22:43 | Informe spam
Hola para tu primer pregunta te envio un articulo que escribi sobre dicho
tema, leelo que seguro te ayuda mucho ;)

Para la segunda pregunta te comento:

Una opcion puede ser la que indicas y la otra que levantes el usuario de
windows y uses ese para definirle los permisos. La recomendacion de Gux es
adecuada si usas :NET, de todas formas miralo antes de implementar porque
ese AP tiene algunos detalles :(

http://www.microsoft.com/spanish/ms...art168.asp

Un abrazo




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messenger:

"Juan Carlos" escribió en el mensaje
news:
Bueno, muchas gracias por la respuesta.

¿Para la parte de registrar quien hizo cada cambio que seria mejor?
¿Uso triggers que setean automáticamente para cada registro quién fue el
usuario que lo originó (a nivel de base de datos) o lo inserto desde la
aplicación (por ejemplo obteniendo el usuario desde la variable de entorno
"USERNAME")?

La parte de autenticacion "en la aplicación" con seguridad integrada sería
definiendo grupos a nivel del sistema operativo y obteniendo el grupo
desde
el sistema operativo?

Gracias,
Juan Carlos.


"Maxi" escribió en el mensaje
news:u1$h$
Hola, mira lo mejor seria usar seguridad integrada y darle al SO el
manejo
que estas comentando. Esto es valido si todas las estaciones de trabajo


son
clientes Windows, de lo contrario no podras aprovechar esta ventaja :(

Otro tema es la autentificacion a la aplicacion ( o sea, que cosas puede
o
no hacer dicho usuario dentro de esta ), esto tambien lo podrias hacer
con
seguridad integrada o bien guardar los registros en una tabla y ahi
establecer los permisos.


Salu2
Maxi


"Juan Carlos" escribió en el mensaje
news:
> Hola:
>
> Tengo una duda de como diseñar la parte de seguridad para una
> aplicación
> que
> usa SQL Server.
>
> Para un sistema que estamos construyendo es parte de los requerimientos


de
> alguna forma manejar usuarios y contraseñas de acceso al programa,
> donde
> además los usuarios y contraseñas tienen que caducar cada cierto tiempo
> configurable, y que cuando las contraseñas hayan caducado, el sistema
> le
> pueda ofrecer al usuario cambiar la contraseña.
>
> Este sistema hace uso de SQL Server 2000 para almacenar/recuperar los
> datos.
> Los datos van a ser principalmente un registro (una especie de "log" )


de
> operaciones llevadas a cabo por los usuarios. La aplicación va a correr


en
> un conjunto chico de PCs dedicados que usan un SQL server para acceder
> a
> los
> datos.
> Para todos los registros de la base de datos se tiene que tener el


usuario
> que ejecuto la operacion (el registro "registra" esa operación).
> Como dije, los PCs son dedicados y no existe un servidor de dominio en


la
> red. Todas las máquinas tendrían Windows XP.
>
> La duda me surge es cuál es la mejor forma de hacer este manejo de
> usuarios/contraseñas tanto para el acceso al sistema como para la base


de
> datos. No tengo mucha experiencia en estas cosas, asì que agradezco su
> ayuda.
>
> Se me ocurren por ejemplo:
> 1) Que la autenticación al sistema sea a través del sistema operativo,


que
> el acceso a la base de datos sea un acceso "integrado" y que el manejo


de
> la
> caducidad de usuarios y contraseñas se haga en el servidor (Windows
> XP).
> 2) Que la autenticación al sistema se haga contra el SQL Server, que en
> SQL
> Server se haga todo el manejo de usuarios/contraseñas. El tema de la
> caducidad no sé como sería (no sé si se puede hacer ese control en SQL
> Server).
> 3) Que todo el tema de usuarios/permisos/caducidad sea manejado por la
> aplicación (lo que no implica que no sea almacenado en la base de
> datos)


y
> el acceso a la base de datos sea con un usuario y contraseña
> "hardcodeados"
> (fijos para la aplicación).
>
> Saludos,
> Juan Carlos
>
>






Respuesta Responder a este mensaje
#5 Juan Carlos
10/12/2004 - 23:32 | Informe spam
Gracias a ambos por sus respuestas.

Usaré triggers entonces.

Para la parte de de seguridad de la aplicación, es una aplicación Win32
hecha en Visual C++ .NET , por lo que supongo que no me sirve el
"application block".
Todavía no sé como crear usuarios de Windows desde Visual C++ pero lo
averiguaré por otro lado.

Muchas gracias,
Juan Carlos


"MAXI" escribió en el mensaje
news:
Hola para tu primer pregunta te envio un articulo que escribi sobre dicho
tema, leelo que seguro te ayuda mucho ;)

Para la segunda pregunta te comento:

Una opcion puede ser la que indicas y la otra que levantes el usuario de
windows y uses ese para definirle los permisos. La recomendacion de Gux es
adecuada si usas :NET, de todas formas miralo antes de implementar porque
ese AP tiene algunos detalles :(

http://www.microsoft.com/spanish/ms...art168.asp

Un abrazo




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messenger:

"Juan Carlos" escribió en el mensaje
news:
> Bueno, muchas gracias por la respuesta.
>
> ¿Para la parte de registrar quien hizo cada cambio que seria mejor?
> ¿Uso triggers que setean automáticamente para cada registro quién fue el
> usuario que lo originó (a nivel de base de datos) o lo inserto desde la
> aplicación (por ejemplo obteniendo el usuario desde la variable de


entorno
> "USERNAME")?
>
> La parte de autenticacion "en la aplicación" con seguridad integrada


sería
> definiendo grupos a nivel del sistema operativo y obteniendo el grupo
> desde
> el sistema operativo?
>
> Gracias,
> Juan Carlos.
>
>
> "Maxi" escribió en el mensaje
> news:u1$h$
>> Hola, mira lo mejor seria usar seguridad integrada y darle al SO el
>> manejo
>> que estas comentando. Esto es valido si todas las estaciones de trabajo
> son
>> clientes Windows, de lo contrario no podras aprovechar esta ventaja :(
>>
>> Otro tema es la autentificacion a la aplicacion ( o sea, que cosas


puede
>> o
>> no hacer dicho usuario dentro de esta ), esto tambien lo podrias hacer
>> con
>> seguridad integrada o bien guardar los registros en una tabla y ahi
>> establecer los permisos.
>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Juan Carlos" escribió en el mensaje
>> news:
>> > Hola:
>> >
>> > Tengo una duda de como diseñar la parte de seguridad para una
>> > aplicación
>> > que
>> > usa SQL Server.
>> >
>> > Para un sistema que estamos construyendo es parte de los


requerimientos
> de
>> > alguna forma manejar usuarios y contraseñas de acceso al programa,
>> > donde
>> > además los usuarios y contraseñas tienen que caducar cada cierto


tiempo
>> > configurable, y que cuando las contraseñas hayan caducado, el sistema
>> > le
>> > pueda ofrecer al usuario cambiar la contraseña.
>> >
>> > Este sistema hace uso de SQL Server 2000 para almacenar/recuperar los
>> > datos.
>> > Los datos van a ser principalmente un registro (una especie de


"log" )
> de
>> > operaciones llevadas a cabo por los usuarios. La aplicación va a


correr
> en
>> > un conjunto chico de PCs dedicados que usan un SQL server para


acceder
>> > a
>> > los
>> > datos.
>> > Para todos los registros de la base de datos se tiene que tener el
> usuario
>> > que ejecuto la operacion (el registro "registra" esa operación).
>> > Como dije, los PCs son dedicados y no existe un servidor de dominio


en
> la
>> > red. Todas las máquinas tendrían Windows XP.
>> >
>> > La duda me surge es cuál es la mejor forma de hacer este manejo de
>> > usuarios/contraseñas tanto para el acceso al sistema como para la


base
> de
>> > datos. No tengo mucha experiencia en estas cosas, asì que agradezco


su
>> > ayuda.
>> >
>> > Se me ocurren por ejemplo:
>> > 1) Que la autenticación al sistema sea a través del sistema


operativo,
> que
>> > el acceso a la base de datos sea un acceso "integrado" y que el


manejo
> de
>> > la
>> > caducidad de usuarios y contraseñas se haga en el servidor (Windows
>> > XP).
>> > 2) Que la autenticación al sistema se haga contra el SQL Server, que


en
>> > SQL
>> > Server se haga todo el manejo de usuarios/contraseñas. El tema de la
>> > caducidad no sé como sería (no sé si se puede hacer ese control en


SQL
>> > Server).
>> > 3) Que todo el tema de usuarios/permisos/caducidad sea manejado por


la
>> > aplicación (lo que no implica que no sea almacenado en la base de
>> > datos)
> y
>> > el acceso a la base de datos sea con un usuario y contraseña
>> > "hardcodeados"
>> > (fijos para la aplicación).
>> >
>> > Saludos,
>> > Juan Carlos
>> >
>> >
>>
>>
>
>


Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida