![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|
|
#1
|
||||
|
||||
|
Las contraseñas se debería hacer un hash en lugar de cifrar... me explico:
pides usuario y contraseña, haces un hash de la contraseña y comparas ese hash con el que está en la Base de datos. Si se hace con el nombre de usuario, mejor. Se hace así porque no hay posibilidad de "desencriptar" y como dato sensible que es, nadie debería saber qué contraseña usa el usuario o el administrador del programa. Por supuesto debe haber una opción para "resetear" o machacar la contraseña actual si eres el administrador. Lo del hash al nombre de usuario es porque si alguien ve que hay un usuario "pablo" y sabe el día que nació su hija... pues ya sabe la contraseña ![]()
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
|
#2
|
||||
|
||||
![]() ![]() ![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#3
|
||||
|
||||
|
Cita:
.Cuando hay que proteger un dato? Se encripta. Hashear hace parte del proceso en algunas formas, pero un hash no es seguro. Un hash es: https://en.wikipedia.org/wiki/Hash_function Cita:
Asi que luego piensan: "Claro hombre, es que hay que saltear!". Y si se pega/copia sin pensar un ejemplo en la web, puedes terminar con algo errado: https://en.wikipedia.org/wiki/Salt_(cryptography) Código:
A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function Por lo tanto "hash sin cifrar" es todo lo contrario de lo que se debe usar para guardar un password. P.D: Para los que no estan al tanto: PBKDF2, bcrypt, scrypt son los que se pueden usar. Utilizar una libreria confiable hecha por expertos. JAMAS hacer "encriptacion" de tipo casera en un entorno serio de produccion. Si leen este mensaje en unos meses, es probable que todas o algunas de las funciones mencionadas dejen de ser seguras! Siempre chequea cuando es cosas de seguridad y no creas ciegamente lo que te dicen, aun cuando lo diga YO! ---- Tener usuario/clave NO ES SEGURIDAD. Autenticación, autorización, privacidad, integridad, seguridad son conceptos relacionados pero diferenciados. ---- Hacer una app segura es basicamente decir que es una app *correcta*. Por ejemplo, las injecciones SQL existen porque se usan cadenas de texto cuando realmente se quiere decir fragmentos de un lenguaje SQL. Osea, es una falla de asignar el tipo errado al dato. De igual manera, mantener la privacidad/integridad de la informacion es lo mismo que hacer una app *correcta*. Si es posible acceder a los datos remotamente, y se cree que "mis claves tienen hash salteados!" es lo que lo hace seguro, es asignar el acceso errado al dato.
__________________
El malabarista. |
|
#4
|
||||
|
||||
![]() ![]() ![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Control de Usuarios segun Tablas | diegonazaruka | Firebird e Interbase | 10 | 22-03-2010 17:46:52 |
| Control de usuarios | KeyMan | HTML, Javascript y otros | 4 | 20-04-2006 10:13:41 |
| Componente para Control de usuarios | El_Chava | Noticias | 3 | 07-09-2005 14:45:52 |
| Control de Usuarios | JamesBond_Mx | Conexión con bases de datos | 2 | 15-07-2005 03:55:51 |
| Control de usuarios concurrentes | Toni | Providers | 2 | 02-08-2004 15:43:17 |
|