Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

método pwdencrypt() de SQL

05/11/2003 - 20:58 por Jackson Jimenez | Informe spam
Ayuda Hacer una pregunta
Hola.

Tengo un detalle del método pwdencrypt() de SQL.

En la versión 7.0 Estardard ó 2000 Estandard, el
pwdencrypt() me funciona para encriptar campos varbinary
(40) de passwords en una base de datos, pero al tratar de
migrar esta base de datos a una versión Enterprise 2000,
el método pwdcompare() no me devuelve el valor correcto,
debido a que al momento de pasar el valor del password la
longitud varbinary resultado del pwdencrypt() es mas
largo.

Segun este algoritmo que se utiliza el pwdencrypt:

declare @w_crypt_pwd varbinary(40),
@in_password varchar(20)

Select @in_password = 'prueba'

select @w_crypt_pwd = convert(varbinary(40),pwdencrypt
(@in_password))
select @w_crypt_pwd


El resultado del password "prueba" en SQL 7.0 STD es:
0x2131235D375D2B5540272B5555355027

Pero en SQL 2000 Enterprise el resultado del
password "prueba" en SQL 7.0 STD es:
0x01006A13FD640EF790088DB469988BD69BC1CA6A059F556D06642A2E
722DE1534535256BA45D4C70

Nota: Hay que notar de que estos valores (hex) no son los
mismos, ya que al ejecutar el script varias veces estos
valores cambian aleatoriamente, pero la longitud es lo
que más me llama la atención.

Por favor, me podrías orientar en como se puede migrar
esta BD de Estandard a Enterprise para poder seguir
ejecutando el pwdencrypt y pwdcompare.


Saludos...
email Siga el debateRespuesta 2 respuestasRespuesta Tengo una respuesta
DRAGON AGE™: INQUISITION – Matadragones
 

Leer las respuestas

#1 Javier Loria
05/11/2003 - 23:26 | Informe spam
Hola:
El procedimiento pwdencrypt() es un procedimiento de Sistema NO
DOCUMENTADO de MS, es bastante natural que MS cambien sin ninguna
consideracion dicho procedimiento. Esto por supuesto hace incompatible su
uso entre versiones.
Es natural que las funcion genere valores diferentes cada ocasion, ya
que tiene un algoritmo que agrega SAL al resultado. Esto es que agrega datos
generados de forma aleatoria para hacer mas dificil el encontrar la llave
original.
Se que no te va a gustar mucho, pero yo aprovecharia para cambiar tu
aplicacion y dejar de usar estas funciones, talvez programando la propia :(
Desgraciadamente no puede sugerirte ninguna, porque estoy acostumbrado a
usar la seguridad integrada de Windows.

Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Jackson Jimenez escribio:
Hola.

Tengo un detalle del método pwdencrypt() de SQL.

En la versión 7.0 Estardard ó 2000 Estandard, el
pwdencrypt() me funciona para encriptar campos varbinary
(40) de passwords en una base de datos, pero al tratar de
migrar esta base de datos a una versión Enterprise 2000,
el método pwdcompare() no me devuelve el valor correcto,
debido a que al momento de pasar el valor del password la
longitud varbinary resultado del pwdencrypt() es mas
largo.

Segun este algoritmo que se utiliza el pwdencrypt:

declare @w_crypt_pwd varbinary(40),
@in_password varchar(20)

Select @in_password = 'prueba'

select @w_crypt_pwd = convert(varbinary(40),pwdencrypt
(@in_password))
select @w_crypt_pwd


El resultado del password "prueba" en SQL 7.0 STD es:
0x2131235D375D2B5540272B5555355027

Pero en SQL 2000 Enterprise el resultado del
password "prueba" en SQL 7.0 STD es:
0x01006A13FD640EF790088DB469988BD69BC1CA6A059F556D06642A2E
722DE1534535256BA45D4C70

Nota: Hay que notar de que estos valores (hex) no son los
mismos, ya que al ejecutar el script varias veces estos
valores cambian aleatoriamente, pero la longitud es lo
que más me llama la atención.

Por favor, me podrías orientar en como se puede migrar
esta BD de Estandard a Enterprise para poder seguir
ejecutando el pwdencrypt y pwdcompare.


Saludos...

Preguntas similares

 

Busqueda sugerida :