Otro que opina de metido, jeje: En el caso que se olvide la clave, simplemente se le cambia por una nueva clave aleatoria. Saludos Leandro
On Nov 13, 2007 5:27 PM, Esteban Grinberg <[EMAIL PROTECTED]> wrote: > Si es un valor encriptado, existe la posibilidad de que te descubran la > clave de encriptacion y por lo tanto, accedan a la combinacion > usuario-password. > En cambio, si se almacena el hash (mas un valor salt), salvo por fuerza > bruta, no hay forma descubrir el password. > > Ademas puede darse esta situacion: > Existe el usuario AAA, cuya password es BBB. > Pero puede existir el usuario AA, cuya password sea ABBB. En tal caso, con > este sistema, no podrias distinguir una cosa de la otra (salvo que se ponga > algun caracter en el medio que los separe y se valide que tanto el usuario > como el password no puedan tener como parte del valor ese caracter, lo que > me parece un poco rebuscado). > > Saludos > > > > On Nov 13, 2007 3:51 PM, Carlos Peix <[EMAIL PROTECTED]> wrote: > > > > > > Hola Daniel, > > > > Creo que el problema que mencionas no seria tal, imagino que la PK o clave > para buscar el registro seria justamente el dato cifrado. El usuario ingresa > usuario y clave, encriptas y con el resultado haces el query en la base de > datos. Si no encontras registro entonces ese usuario y password no existe. > De todas maneras hay algunos puntos oscuros: > > > > - Los algoritmos de hash aseguran que es (casi) imposible que dos datos > distintos arrojen el mismo hash (colision), pero que dice de la posibilidad > de colision de dos datos distintos con passwords distintos? > > - Como garantizas que no existan dos usuarios con el mismo login? > > - Como recuperas una cuenta de un usuario que se olvido el password? > > - Por que la Sibarita es tanrica? > > > > Carlos Peix > > > > > > ________________________________ > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Calvin > > Sent: Martes, 13 de Noviembre de 2007 03:31 p.m. > > > > To: [EMAIL PROTECTED] > > Subject: [dbms] Re: Re: Marcas de garantía en los registros > > > > > > > > > > > > Opinión de metido.... > > > > Si no guardas ninguna de las dos cosas, como cotejas que ese resultado se > corresponda con el usuario que se supone que deberia coincidir jose? > > > > Osea, en la tabla alguna referencia univoca necesitarias, y si estas en un > ambiente desconectado? como harias un cambio de password? ( algo, aunque no > se un user id deberiá viajar junto al resultado. ( osea no evitas guardar el > usuario ), me parece un metodo medio enredado che..... > > > > Saludos > > > > Daniel Calvin > > > > > > El día 13/11/07, Carlos Peix <[EMAIL PROTECTED]> escribió: > > > > > > > > > No estoy seguro de las ventajas de ese enfoque, lo viste en algun lado? > > > > > > Algunas cosas no me cierran, por ejemplo, porque es necesario que sea un > algoritmo simetrico? como relacionas el modulo de autenticacion con el de > autorizacion? > > > > > > Otra pregunta, cuales errores de programacion evitas de esta manera? > > > > > > Carlos Peix > > > > > > ________________________________ > From: [email protected] [mailto: [EMAIL PROTECTED] On Behalf Of Jose Mariano > Alvarez > > > Sent: Martes, 13 de Noviembre de 2007 12:58 p.m. > > > To: [EMAIL PROTECTED] > > > Subject: [dbms] Re: RE: Marcas de garantía en los registros > > > > > > > > > > > > Para validar usuarios lo mejor es cifrar mediante una algoritmo > simetrico el usuario con la contraseña, > > > De esa manera no se guarda ninguna de las dos cosas y se requiere que el > usuario conozca los dos datos.. > > > Evita tambien errores de programacion. > > > > > > > > > Saludos > > > > > > -- > > > -------------------------------- > > > Atte. > > > Ing. Jose Mariano Alvarez > > > SQL Total Consulting > > > > > > > > > > > > > > > On Nov 13, 2007 11:38 AM, Juan Carlos Barrios <[EMAIL PROTECTED]> > wrote: > > > > > > > podrias crear un campo donde guardes un hash de los > > > > campos que no queres que se cambien, tambien podes > > > > agregarle mayor seguridad con otra tabla que guarde la > > > > integridad vertical. > > > > para que no puedan borrar registros > > > > > > > > --- "Alejandro A. ALEKSICH" <[EMAIL PROTECTED] > > > > > escribió: > > > > > > > > > Gracias a todos, espectaculares las respuestas!. > > > > > > > > > > > > > > > > > > > > -----Mensaje original----- > > > > > De: Carlos Peix [mailto:[EMAIL PROTECTED] ] > > > > > Enviado el: Martes, 13 de Noviembre de 2007 08:30 > > > > > a.m. > > > > > Para: [EMAIL PROTECTED] > > > > > Asunto: [dbms] RE: [dbms] Marcas de garantía en los > > > > > > > > > registros > > > > > > > > > > Hola Alejandro, > > > > > > > > > > Lo que necesitas hacer es posible, yo le he hecho en > > > > > algunas tablas, por > > > > > ejemplo > > > > > de autenticacion de usuarios. Incluso es la manera > > > > > en que almaceno los > > > > > passwords > > > > > en aplicaciones que deben cumplir con estandares de > > > > > seguridad. > > > > > > > > > > Existe una operación de cifrado (ya hay algun mail > > > > > que te recomienda algo) > > > > > que > > > > > te permite procesar todos los datos sensibles > > > > > mediante esta funcion > > > > > matematica a > > > > > la que agregas una clave (solo de conocimiento > > > > > tuyo). Esta funcion > > > > > matematica > > > > > devuelve un hash, esto es, un dato de longitud fija > > > > > que podes almacenar en > > > > > otra > > > > > columna. > > > > > > > > > > Esta funcion matematica te asegura que desde ese > > > > > dato, el hash, no puede > > > > > obtenerse ni los datos ni la clave. Esto es > > > > > efectivamente una firma > > > > > electronica > > > > > sobre los datos. > > > > > > > > > > Para verificar si los datos fueron modificados solo > > > > > tenes que reprocesar los > > > > > datos de origen con tu clave privada y verificar si > > > > > el hash producido > > > > > coincide > > > > > con el original (verificar las firmas). > > > > > > > > > > Dependiendo del motor de base de datos que uses > > > > > tendras sera mas facil o no > > > > > implementar esto. Parece que hay alguna funcion en > > > > > SQLServer, pero te > > > > > sugiero > > > > > que utilices algun algoritmo que tambien tenga > > > > > soporte en el framework. > > > > > > > > > > En el caso del passaword, se procesa con esta > > > > > funcion y se almacena el hash, > > > > > descartando el password real, luego, para verificar > > > > > el password, volves a > > > > > procesar y comparas los hashes. > > > > > > > > > > Carlos Peix > > > > > > > > > > > -----Original Message----- > > > > > > From: [email protected] [mailto: [EMAIL PROTECTED] On > > > > > Behalf Of > > > > > > Alejandro A. ALEKSICH > > > > > > Sent: Lunes, 12 de Noviembre de 2007 09:05 p.m. > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: [dbms] Marcas de garantía en los > > > > > registros > > > > > > > > > > > > Tengo la siguiente situación: > > > > > > Trabajamos sobre una base de datos editando y > > > > > agregando > > > > > > registros, finalizado el trabajo "devolvemos" la > > > > > base al cliente. > > > > > > El tema es que quiero crear una "marca" sobre los > > > > > registros > > > > > > tal cual le entrego al cliente, algo así como un > > > > > precinto de > > > > > > seguridad. > > > > > > ¿hay alguna manera de hacer esto?. > > > > > > Pensé en agregar un campo Guid o timestamp y > > > > > guardar el valor > > > > > > de cada registro en una base de datos separada, la > > > > > pregunta > > > > > > es: el valor de este campo puede ser editado ?, si > > > > > los > > > > > > valores son coincidentes al estado inicial, ¿puedo > > > > > afirmar > > > > > > que ese registro nunca fue modificado? > > > > > > > > > > > > Hay que tener en cuenta que el cliente es el > > > > > propietario de > > > > > > los datos, o sea tiene pleno derechos sobre ellos. > > > > > Solo > > > > > > quiero evitar que nadie cambie malintesionadamente > > > > > los datos > > > > > > y luego me atribuyan el error a mí trabajo. > > > > > > > > > > > > Se trabaja con SQL2k > > > > > > > > > > > > Gracias.- > > > > > > > > > > > > > > > > > > __________ Información de NOD32, revisión 2653 > > > > > (20071112) __________ > > > > > > > > > > > > Este mensaje ha sido analizado con NOD32 > > > > > antivirus system > > > > > > http://www.nod32.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________ NOD32 2653 (20071112) Information > > > > > __________ > > > > > > > > > > This message was checked by NOD32 antivirus system. > > > > > http://www.eset.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <P>Juan Carlos Barrios</P> > > > > Lider de Proyectos > > > > Axyonar > > > > www.axyonar.com.ar > > > > [EMAIL PROTECTED] > > > > cel. 15 6181-1094 > > > > <P>te (011) 6091-3030</P> > > > > > > > > > > > > Compartí video en la ventana de tus mensajes (y también tus fotos > de Flickr). > > > > Usá el nuevo Yahoo! Messenger versión Beta. > http://ar.beta.messenger.yahoo.com/ > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Daniel A. Calvin > > Cooperator Team Member > > http://www.cooperator.com.ar > > Microsoft Certified Professional > > > > -- > "Si llegue a ver tan lejos, es porque me subi en hombros de gigantes" > Issac Newton
