Título: leer user y password en archivos aleatorios Publicado por: corlo en 4 Enero 2021, 23:17 pm Hola soy corlo
tengo el siguiente problema cuando pongo lo siguiente en el apartado leer user y password Text1.Text = Access.uname Text2.Text = Access.passwd el problema es cuando estoy leyendo el user y password introduzca datos diferentes en el text1.text y el text2.text , y pongo los datos que hay en fichero siempre me dice bienbenido y va al form2 en cambio cuando quito Text1.Text = Access.uname Text2.Text = Access.passwd siempre me dice El archivo no existe Aqui pongo el codigo Código:
la pregunta seria: como solucionar el tema de los avisos en el apartado leer 1. para ir al formulario dos 2. para el registro no existe Gracias Título: Re: leer user y password en archivos aleatorios Publicado por: BlackZeroX en 5 Enero 2021, 06:31 am Es mejor usar SQLite que esto, pues no muy "legible".
http://leandroascierto.com/blog/vbsqlite3/ saludos. Título: Re: leer user y password en archivos aleatorios Publicado por: corlo en 5 Enero 2021, 09:48 am Gracias por responder BlackZeroX (Astaroth)
pero yo tengo el problema en archivo aleatorio no en sql creo que se entiende el problema que hay se trata de leer el user y password y que me avise de que vaya al formulario2 cuando existe un usuario y cuando no que vaya a el registro no existe. gracias Título: Re: leer user y password en archivos aleatorios Publicado por: EdePC en 5 Enero 2021, 17:04 pm No le veo mucho sentido a tu código esa parte de 'leer, lo has leído y entendido bien?
Para responder tus preguntas finales habría que re-escribir casi toda esa parte dependiendo de tu objetivo final, a mi parecer quieres poner en los TextBox un User y Password, luego estos buscarlos en el Archivo y si están ir al Form2, caso contrario mostrar un Error. - Veo que no has puesto un bucle para buscar en varios registros, aunque al parecer lo estabas poniendo - Tus condicionales IF tiene una pinta muy rara, estás usando And donde debes usar Or y viceversa. Para no irse por las nubes y no desvirtuar mucho tu código te pongo este ejemplo donde se lee solo el primer registro para verificar que el User y Password dados en los TextBox por parte del Usuario son iguales a los almacenados en el primer registro del Archivo: Código
- Ahí he editado el For para que haga lea Registro a Registro, en cada leída va a comprobar si los datos puestos por el Usuario en los TextBox corresponden a los del Registro leído, para esto es buen idea usar Trim debido a que los datos de los TextBox y en particular del Registro leído va a tener varios espacios vacíos de relleno hasta completar 30 caracteres. Trim elimina los espacios. -- Si los Registros coinciden simplemente termina el Sub dando antes el MsgBox de bienvenida y muestra el Form2. -- Si los ningún registro coincide pasa a ejecutar la última parte que siempre muestra un MsgBox de Archivo/Registro no encontrado y vacía los TextBox. Con respecto al SQL, pues dependerá de si se van a utilizar Datos Relacionados o Estructuras de Datos complejos, para este caso no lo veo necesario salvo que sea para practicar su uso. Título: Re: leer user y password en archivos aleatorios Publicado por: corlo en 5 Enero 2021, 18:16 pm muchas gracias EdePC
justo lo que necesitaba tema resuelto Título: Re: leer user y password en archivos aleatorios Publicado por: Serapis en 6 Enero 2021, 21:34 pm muchas gracias EdePC El tema no está bien resuelto.justo lo que necesitaba tema resuelto Es muy mala idea (y eso que este foro tiene un nombre muy específico), dejar user y password en texto plano en un fichero. Como mínimo, en el fichero se deberían guardar el hash de ello, concatenados en el orden que prefieras. tu en tu código trar leer sendos datos d elos textbox, deberías crear el hash de cada dato y concatenarlos en el mismo orden y forma que se hizo para guardarlo al fichero, solo si coincide es cuando debes dar por válido la concordancia. Por supuesto, no lo hagas tan simple, aquí un ejemplo desde el que partir: Código
En la línea: "Hash = Codificar(UserHash, PasswordHash)", es para complicar el caso un algo más que: la simple concatenación como en: "hash = userHash & PasswordHash", conviene hacer algo más, para complicar una fácil intrusión... 'Codificar' debería ser una función (más o menos compleja) que devuelve un string. Finalmente en tu fichero, una sola línea debería contener dicho valor devuelto como 'hash', por tanto puede tener un largo distinto, pués ocupa una sola línea. Con 'Line Input' se puede leer línea a línea un fichero... igualmente siempre considera eliminar espacios a ambos lados de un string leído de fichero. Date cuenta que incluso aunque el fichero solo precisa tener 1 única identificación, el fichero podría contener (por ejemplo), 200 identificaciones generadas aleatoriamente, de modo que cualquier intento de intrusión en principio es más complicado que 'solo' abrir un fichero de texto plano, o abrir un texto plano y encontrar 'lo que es'. Como se verifica la identidad con todas las posibles (supuestas identidades) contenidas en el fichero, si existe acaba por encontrarla y piensa que verificar 200 ni 2000 identidades es lento, además justamente las verificaciones de identidad son precisamente los algoritmos donde no interesa optimizar al máximo en velocidad, por asunto de no facilitar la tarea a estrategias de fuerza bruta. Código
No añado más código... con lo siguiente ya debe debe darte idea, para tu hacer modificaciones a tu antojo y elegancia: Código
La funcion 'Hashing()' podría ser una llamada a un algotimo de resumen como 'Md5', 'RC4', o cualquier otro disponible, incluso una codificacón 'Base64', sería preferible a un text plano, la función ' Codificar' interpuesta entre los datos de origen y el dato final, lo complica lo suficiente como para que tareas de fuerza bruta, fracasen... *** Esto supone que siempre se verifiquen todas las entradas del fichero, aún cuando ya la haya encontrado, y no que devuelva cuando la encuentre... el tiempo que tarda en encontrarlo, podría arrojar pistas sobre si está al comienzo o al final. De este modo, tarda lo mismo sea la primera o la última entrada. Es fácil demostrarlo y localizar la identidad concreta. Imagina que el fichero tiene 100 entradas y yo añado entre cada línea del fichero 10.000 más. Puedo hacer un bucle para hacer lo siguiente: verificaridentidad, calcular tiempo utilizado y anotar tiempo y ciclo. mover las primeras 10.001 lineas al final del fichero. Tras los 100 ciclos (una por cada entrada), tendré 100 tiempos anotados, las diferencias de 'salir' cuando se encuentre una identificación válida queda reflejado en las respuestas que arroja dicho bucle, luego así es deducible cual es la identificación válida. Imagina (por simplicidad para comprenderlo), que la identidad correcta e sla primera línea... en el bucle uno tarda 1, luego como baja al final del fichero, el tiempo que marca será 100, en el siguiente ciclo, 99,98, 97... Imaginemos que es la línea 50 la que contiene la identidad... en el primer ciclo tarda 50, en el segundo 49, en el 3º 48... lega un punto que es el menor de todos (cuando sea la línea 1ª como se describe en el parráfo anterior), cmo justo cuando tarda menos (es la primera y s epasa al final) coincide que será la última y tardará más, luego... la respuesta correcta se haya en el cclo cuya tiempo es el menor de todos y al que le sigue el ciclo cuyo tiempo es el mayor de todos (o casi en ambos casos, ya que posibles interrupcciones hardware (por ejemplo), pueden variar un poco el caso... En cambio si siempre analiza todas las entradas, el tiempo es básicamente el mismo cada vez (inapreciable a efectos prácticos). Otra forma es no leer las líneas en orden, si no crear un array con tantas entradas como líneas tenga el fichero y barajarlo 'desordenar el array' con una función aleatoria, luego se lee cada línea en el orden que marca el array... ahí si exige acceso aleatorio (para que la lectura de cada línea tenga un tiempo sin dependencia del orden que ocupa en el fichero), por lo que en tal caso 'Line Input', no sería el modo de lectura adecuado al caso. Todavía incluso ocultando una identidad entre otras 200, es factible de ser descubierta, en un 'tiempo' equivalente al de una búsqueda binaria. Eso sí se requiere saber en todo momento que la cuenta que hace el login es la misma cada vez... si son varias cuentas las que se loguean, resultará más complicado (tiempo en el sentido de intentos). Veamos, si abro el fichero y elimino la mitad primera de las líneas y guardo el fichero. Cuando intente loguearse ocurrirá una d edos cosas: logra identificarse, no logra identificarse. Si logra identificarse, señala que la identidad está en la mitad que dejaste en el fichero, y si no logra identificarse (o bien se equivocó a introducir sus datos o bien) consta la identidad en la mitad retirada del fichero (por ello falla, no la encuentra). Ahora contmaos solo con la mitad de líneas que sabemos que es correcta el resto son elimiandas... nuevamente de estas copiamos y cortamos la mitad, y se sigue el proceso hasta que el fichero solo contenga una única línea que es la que arroja la identidad correcta. Una errada solución a la que cabría que se llegue sería comprobar antes de nada que el tamaño del fichero es el que se espera... pero esto puede también falsificarse, si tras eliminar la mitad del contenido interesado, lo remplazo con contenido aleatorio, el tamaño del fichero permanece invariable, pero básicamente sabe uno que en ese contenido aleatorio (o no aleatorio), no está la identifidad... La solución para solventar este caso, consiste en hashear todo el fichero y ver que el mismo no ha sido modificado desde la última vez que se modificó. Esto es cuando se añade un login al mismo se hashea el fichero y se guarda dicho hash (preferiblemente en otro destino distinto al equipo). La desventaja es tener que guardar dicho dato fuera dle equipo, lo que le leva a uno a preguntarse, y por que nó guardar la identidad también fuera del equipo?. Si solo es uno, es igualmente válido pero si ha de tener muchas, la solución resultará engorrrosa (para un entorno no profesional que asumo es el caso). Básicamente una solución infalible solo existe en dos situaciones: - El hardware colabora: Si hay partes dle hardware del euipo que apoyan soluciones d eidentificación, pero deslocalizadas del S.O. (es decir como si poseyera un segundo procesador con un mini S.O. dedicado solo a mantener cuestiones seguridad y por tanto inaccesible e inalterable desde el otro procesador... y una conmutación en el equipo (un botón tecla, etc...), que permita saltar entre uno y otro S.O. - El sistema de identificación se guarda fuera del equipo, de odo que cualquier intrusión ni siquiera tenga posibilidad de saber dónde o cómo localizarlo... por lo tanto no podrá probar ninguna técnica (aparte del pishing). ...pués el factor humano es y seguirá siendo un punto débil, antes se consideraba el punto más débil, pero a causa de la enorme cantidad de fallos descubierta en los diseños, se puede considerar que como trasl el diseño, está el ser humano, hereda el 'punto débil'... y por tanto es razonable considerar que están a la par. No obstante considera que si hay demasiadas 'puertas' en cuanto a la seguridad es fácil que dado el valor del 'cebo' tras la puerta, se pierda fácilment el interés en intentar la intrusión... pero incluso aunque el valor del 'cebo' sea nulo, no conviene nunca dejar un texto plano... no es propio de programadores solo de idiotas. (nota: No he probado el código, lo he escrito al vuelo (después de enviar he corregido algo rápido de sintaxis, cono nombres de variables o constantes, etc..), puede que precise alguna corrección que queda a tu esfuerzo). Título: Re: leer user y password en archivos aleatorios Publicado por: corlo en 7 Enero 2021, 12:52 pm gracias Serapis por la informacion
con el codigo de EdePC ya me vale, porque hace lo que yo necesito, osea leer text1 y text2 y va al form2, y cuando no existe me dice error registro no existe, cuando creas el user y password lo guarda tal y como lo has escrito, yo tengo a 10 usuarios y no hay problema ninguno. siempre va bien saber varios temas. gracias Título: Re: leer user y password en archivos aleatorios Publicado por: BlackZeroX en 1 Febrero 2021, 08:25 am El tema es solo de Accesos, si se requiriera algo de seguridad (mayor nivel), cifrado o X es mejor AES 128 (Estándar mínimo para codificación en bancos) o superior (AES 256, 1024, etc, el numero 128 es la longitud de la clave compartida en este caso 128/8 = 16 caracteres, en fin que si con salt se complica y ya mínimo requieres mas de 4 años por decir algo pero aquí lo dicen un poco mas con un análisis en base a números… cifrado: ¿qué tan seguro es AES?
(http://www.dataqubo.com/encriptacion-que-tan-seguro-es-aes/) para adivinar la cadena cifrada). VB6 AES 256 (https://www.vbforums.com/showthread.php?862103-VB6-Simple-AES-256-bit-password-protected-encryption) Chilkat ActiveX Downloads (128-bit, 192-bit, and 256-bit AES encryption in ECB (Electronic Cookbook), CBC (Cipher-Block Chaining), and other modes) (https://www.example-code.com/vb6/crypt2_aes.asp) o cualquier otro algoritmo: VB6 lista de algoritmos para cifrar (https://www.example-code.com/vb6/encryption.asp) Habitualmente es mejor programar esto en capas/fases y no mezclar todo, de tal manera que se pueda rehusar y entender. Por cierto... Código
Mejor. Código
Saludos. |