Aplicaciones Autenticación

Hola, y porque no usar la seguridad integrada?

Si quieres usar la de SQL yo uso esto:

1. Las claves de los Logins las paso con el algotirmo HASH (o md5 en su
defecto)
2. No guardo la clave en ningun ini ni nada por el estilo, sino que armo la
pantalla de Bienvenida para que el usuario la introduzca, luego le aplico
HASH y comparo con la de SQL

Ademas de esto, ninguno de mis usuarios tiene acceso a nada, solo a ejecutar
SP, ademas que utilizo funciones de aplicacion, con lo cual tengo el tema
bien controladito y si alguien saca una clave no puede hacer nada de nada
:-)

Suerte



Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Pao" escribió en el mensaje
news:250f01c49f3c$ab8041a0$
Hola a todos:

He notado que hay muchas aplicaciones, donde las
estaciones clientes o los servidores por la aplicación
evidentmente realizan conexiones hacía bases de datos en
SQLServer (Autenticaciñon Mixta, pero no usan usuarios de
Windows solo de SQL) usando mecanismos como ADO, ODBC,
para la programación; donde se define un usuario y un
password de la base y ese tipo de información.

La aplicación que puede estar en el cliente o servidor
necesita leerlos a los datos de autenticación de alguna
parte, para ello utilizan archivos .ini, regedit, ODBC,
File DSN en las estaciones clientes o del servidor para
almacenar está información delicada, que en la mayoria de
los casos está expuesta como texto plano sin encriptación.
Por lo tanto el riesgo es sumamente alto.

Necesito alguna sugerencia de que implementar un esquema
seguro y tener un estandar para el desarrollo de las
futuras y actuales aplicaciones.

Se han estado creando programas de encriptación para de
alguna manera manterer esta información encriptadad, pero
como que no hay un estandar, unas utilizan un dll con un
algoritmo tal y otras otro..eso depende quien cree la
aplicación.

Agradecería me digan de una o varias alternativas que nos
ayuden a manejar estos casos de manera segura a fin de
poder también hacerlo un estándar para el desarrollo de
las aplicaciones. El front-End usado es Visual Basic,
ASP,Vbscript.


Muchas gracias por su ayuda.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.764 / Virus Database: 511 - Release Date: 15/09/2004

Puedes guiarte por los artículos de la universidad .net,
http://www.microsoft.com/spanish/ms...d/uni.net/

Aunque esta web está orientada a .NET, esto es aplicable a cualquier
lenguaje y/o plataforma.


ING. JOSE DAVID GALVIZ MUÑOZ
MCAD
DCE Cuarta Estrella

"Pao" escribió en el mensaje
news:250f01c49f3c$ab8041a0$
Hola a todos:

He notado que hay muchas aplicaciones, donde las
estaciones clientes o los servidores por la aplicación
evidentmente realizan conexiones hacía bases de datos en
SQLServer (Autenticaciñon Mixta, pero no usan usuarios de
Windows solo de SQL) usando mecanismos como ADO, ODBC,
para la programación; donde se define un usuario y un
password de la base y ese tipo de información.

La aplicación que puede estar en el cliente o servidor
necesita leerlos a los datos de autenticación de alguna
parte, para ello utilizan archivos .ini, regedit, ODBC,
File DSN en las estaciones clientes o del servidor para
almacenar está información delicada, que en la mayoria de
los casos está expuesta como texto plano sin encriptación.
Por lo tanto el riesgo es sumamente alto.

Necesito alguna sugerencia de que implementar un esquema
seguro y tener un estandar para el desarrollo de las
futuras y actuales aplicaciones.

Se han estado creando programas de encriptación para de
alguna manera manterer esta información encriptadad, pero
como que no hay un estandar, unas utilizan un dll con un
algoritmo tal y otras otro..eso depende quien cree la
aplicación.

Agradecería me digan de una o varias alternativas que nos
ayuden a manejar estos casos de manera segura a fin de
poder también hacerlo un estándar para el desarrollo de
las aplicaciones. El front-End usado es Visual Basic,
ASP,Vbscript.


Muchas gracias por su ayuda.

Podría empezarse a utilizar. Habrá que considerarlo.
Pero si no tienes forma de usarla y tampoco puedes
utilizar una pantalla en la cual te pida los datos...que
sugieres hacer???
Por otro lado porque es necesario no manejar la misma
clave aplicativa que la de base?? Por el hecho de que te
la pueden capturar por la red???
Explicame como hacer más segura una aplicación en ese
sentido, es correcto o no que yo use esto pero manejando
la misma clave de SQL que por el front-En en la ventana.


Mostrar la cita

Hola, y porque no usar la seguridad integrada?

Si quieres usar la de SQL yo uso esto:

1. Las claves de los Logins las paso con el algotirmo

HASH (o md5 en su
Mostrar la cita

defecto)
2. No guardo la clave en ningun ini ni nada por el

estilo, sino que armo la
Mostrar la cita

pantalla de Bienvenida para que el usuario la introduzca,

luego le aplico

Mostrar la cita

HASH y comparo con la de SQL

Ademas de esto, ninguno de mis usuarios tiene acceso a

nada, solo a ejecutar
Mostrar la cita

SP, ademas que utilizo funciones de aplicacion, con lo

cual tengo el tema
Mostrar la cita

bien controladito y si alguien saca una clave no puede

hacer nada de nada
Mostrar la cita

:-)

Suerte



Salu2
-

-
Mostrar la cita

Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
-

-
Mostrar la cita

Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Pao" escribió en el mensaje
news:250f01c49f3c$ab8041a0$
Hola a todos:

He notado que hay muchas aplicaciones, donde las
estaciones clientes o los servidores por la aplicación
evidentmente realizan conexiones hacía bases de datos en
SQLServer (Autenticaciñon Mixta, pero no usan usuarios de
Windows solo de SQL) usando mecanismos como ADO, ODBC,
para la programación; donde se define un usuario y un
password de la base y ese tipo de información.

La aplicación que puede estar en el cliente o servidor
necesita leerlos a los datos de autenticación de alguna
parte, para ello utilizan archivos .ini, regedit, ODBC,
File DSN en las estaciones clientes o del servidor para
almacenar está información delicada, que en la mayoria de
los casos está expuesta como texto plano sin encriptación.
Por lo tanto el riesgo es sumamente alto.

Necesito alguna sugerencia de que implementar un esquema
seguro y tener un estandar para el desarrollo de las
futuras y actuales aplicaciones.

Se han estado creando programas de encriptación para de
alguna manera manterer esta información encriptadad, pero
como que no hay un estandar, unas utilizan un dll con un
algoritmo tal y otras otro..eso depende quien cree la
aplicación.

Agradecería me digan de una o varias alternativas que nos
ayuden a manejar estos casos de manera segura a fin de
poder también hacerlo un estándar para el desarrollo de
las aplicaciones. El front-End usado es Visual Basic,
ASP,Vbscript.


Muchas gracias por su ayuda.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.764 / Virus Database: 511 - Release Date:

15/09/2004
Mostrar la cita

.

A ver, utilizar siempre la misma cuenta para mi es un enorme agujero de
seguridad, porque le estas dando muchos permisos a tus usuarios finales :(

Que pasaria si encontras a un usuario un poco picaron y hace SqlInject? a la
lona con todo :(, ademas si siempre usas el mismo usuario y se te ocurre
poder armar algun control de auditoria, no seria muy bueno porque no sabrias
realmente quien esta haciendo la operacion, ni hablar a la hora de
administrar tu SQL y que veas en la "Actividad Actual" un centenar de tareas
todas con el mismo login, la verdad que es un lio total y totalmente
inseguro.

Deberias de tener una sesion por usuario o sino usar la autentificacion de
Windows :-)

Ahora, si no quieres usar pantalla de Bienvenida estas en serios problemas,
porque guardar las claves es algo muy critico de verdad, con lo cual estas
teniendo un enorme agujero de seguridad mas.






Maxi

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

Msn Messager:

"Pao" escribió en el mensaje
news:3fc001c49f4e$dd429410$
Podría empezarse a utilizar. Habrá que considerarlo.
Pero si no tienes forma de usarla y tampoco puedes
utilizar una pantalla en la cual te pida los datos...que
sugieres hacer???
Por otro lado porque es necesario no manejar la misma
clave aplicativa que la de base?? Por el hecho de que te
la pueden capturar por la red???
Explicame como hacer más segura una aplicación en ese
sentido, es correcto o no que yo use esto pero manejando
la misma clave de SQL que por el front-En en la ventana.


Mostrar la cita

Hola, y porque no usar la seguridad integrada?

Si quieres usar la de SQL yo uso esto:

1. Las claves de los Logins las paso con el algotirmo

HASH (o md5 en su
Mostrar la cita

defecto)
2. No guardo la clave en ningun ini ni nada por el

estilo, sino que armo la
Mostrar la cita

pantalla de Bienvenida para que el usuario la introduzca,

luego le aplico

Mostrar la cita

HASH y comparo con la de SQL

Ademas de esto, ninguno de mis usuarios tiene acceso a

nada, solo a ejecutar
Mostrar la cita

SP, ademas que utilizo funciones de aplicacion, con lo

cual tengo el tema
Mostrar la cita

bien controladito y si alguien saca una clave no puede

hacer nada de nada
Mostrar la cita

:-)

Suerte



Salu2
-

-
Mostrar la cita

Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
-

-
Mostrar la cita

Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Pao" escribió en el mensaje
news:250f01c49f3c$ab8041a0$
Hola a todos:

He notado que hay muchas aplicaciones, donde las
estaciones clientes o los servidores por la aplicación
evidentmente realizan conexiones hacía bases de datos en
SQLServer (Autenticaciñon Mixta, pero no usan usuarios de
Windows solo de SQL) usando mecanismos como ADO, ODBC,
para la programación; donde se define un usuario y un
password de la base y ese tipo de información.

La aplicación que puede estar en el cliente o servidor
necesita leerlos a los datos de autenticación de alguna
parte, para ello utilizan archivos .ini, regedit, ODBC,
File DSN en las estaciones clientes o del servidor para
almacenar está información delicada, que en la mayoria de
los casos está expuesta como texto plano sin encriptación.
Por lo tanto el riesgo es sumamente alto.

Necesito alguna sugerencia de que implementar un esquema
seguro y tener un estandar para el desarrollo de las
futuras y actuales aplicaciones.

Se han estado creando programas de encriptación para de
alguna manera manterer esta información encriptadad, pero
como que no hay un estandar, unas utilizan un dll con un
algoritmo tal y otras otro..eso depende quien cree la
aplicación.

Agradecería me digan de una o varias alternativas que nos
ayuden a manejar estos casos de manera segura a fin de
poder también hacerlo un estándar para el desarrollo de
las aplicaciones. El front-End usado es Visual Basic,
ASP,Vbscript.


Muchas gracias por su ayuda.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.764 / Virus Database: 511 - Release Date:

15/09/2004
Mostrar la cita

.

Ok, pero porque en tu pantalla. usas el algoritomo Hash...
La clave que digita el usuario es la misma del login de
SQL???
Si le pones el algoritmo hash es para que nadie la obtenga
por la red???
Esas son mis dudas respecto a ese caso.

Muchas gracias

Mostrar la cita

A ver, utilizar siempre la misma cuenta para mi es un

enorme agujero de
Mostrar la cita

seguridad, porque le estas dando muchos permisos a tus

usuarios finales :(
Mostrar la cita

Que pasaria si encontras a un usuario un poco picaron y

hace SqlInject? a la
Mostrar la cita

lona con todo :(, ademas si siempre usas el mismo usuario

y se te ocurre
Mostrar la cita

poder armar algun control de auditoria, no seria muy

bueno porque no sabrias
Mostrar la cita

realmente quien esta haciendo la operacion, ni hablar a

la hora de
Mostrar la cita

administrar tu SQL y que veas en la "Actividad Actual" un

centenar de tareas
Mostrar la cita

todas con el mismo login, la verdad que es un lio total y

totalmente
Mostrar la cita

inseguro.

Deberias de tener una sesion por usuario o sino usar la

autentificacion de
Mostrar la cita

Windows :-)

Ahora, si no quieres usar pantalla de Bienvenida estas en

serios problemas,
Mostrar la cita

porque guardar las claves es algo muy critico de verdad,

con lo cual estas
Mostrar la cita

teniendo un enorme agujero de seguridad mas.






Maxi

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

Msn Messager:

"Pao" escribió en el mensaje
news:3fc001c49f4e$dd429410$
Podría empezarse a utilizar. Habrá que considerarlo.
Pero si no tienes forma de usarla y tampoco puedes
utilizar una pantalla en la cual te pida los datos...que
sugieres hacer???
Por otro lado porque es necesario no manejar la misma
clave aplicativa que la de base?? Por el hecho de que te
la pueden capturar por la red???
Explicame como hacer más segura una aplicación en ese
sentido, es correcto o no que yo use esto pero manejando
la misma clave de SQL que por el front-En en la ventana.


Mostrar la cita

Hola, y porque no usar la seguridad integrada?

Si quieres usar la de SQL yo uso esto:

1. Las claves de los Logins las paso con el algotirmo

HASH (o md5 en su
Mostrar la cita

defecto)
2. No guardo la clave en ningun ini ni nada por el

estilo, sino que armo la
Mostrar la cita

pantalla de Bienvenida para que el usuario la introduzca,

luego le aplico

Mostrar la cita

HASH y comparo con la de SQL

Ademas de esto, ninguno de mis usuarios tiene acceso a

nada, solo a ejecutar
Mostrar la cita

SP, ademas que utilizo funciones de aplicacion, con lo

cual tengo el tema
Mostrar la cita

bien controladito y si alguien saca una clave no puede

hacer nada de nada
Mostrar la cita

:-)

Suerte



Salu2

-
Mostrar la cita

-
Mostrar la cita

Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET

-
Mostrar la cita

-
Mostrar la cita

Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Pao" escribió en el mensaje
news:250f01c49f3c$ab8041a0$
Hola a todos:

He notado que hay muchas aplicaciones, donde las
estaciones clientes o los servidores por la aplicación
evidentmente realizan conexiones hacía bases de datos en
SQLServer (Autenticaciñon Mixta, pero no usan usuarios de
Windows solo de SQL) usando mecanismos como ADO, ODBC,
para la programación; donde se define un usuario y un
password de la base y ese tipo de información.

La aplicación que puede estar en el cliente o servidor
necesita leerlos a los datos de autenticación de alguna
parte, para ello utilizan archivos .ini, regedit, ODBC,
File DSN en las estaciones clientes o del servidor para
almacenar está información delicada, que en la mayoria de
los casos está expuesta como texto plano sin

encriptación.
Mostrar la cita

Mostrar la cita

Por lo tanto el riesgo es sumamente alto.

Necesito alguna sugerencia de que implementar un esquema
seguro y tener un estandar para el desarrollo de las
futuras y actuales aplicaciones.

Se han estado creando programas de encriptación para de
alguna manera manterer esta información encriptadad, pero
como que no hay un estandar, unas utilizan un dll con un
algoritmo tal y otras otro..eso depende quien cree la
aplicación.

Agradecería me digan de una o varias alternativas que nos
ayuden a manejar estos casos de manera segura a fin de
poder también hacerlo un estándar para el desarrollo de
las aplicaciones. El front-End usado es Visual Basic,
ASP,Vbscript.


Muchas gracias por su ayuda.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system

(http://www.grisoft.com).
Mostrar la cita

Mostrar la cita

Version: 6.0.764 / Virus Database: 511 - Release Date:

15/09/2004
Mostrar la cita

.

.