Password access
 

Hola a todos, alguien sabe como obtener por programa (es decir desde una aplicacion hecha en delphi) la contraseña de un archivo de access?

Buenas tardes,

Existen programas creados para recuperar claves de Acces, hasta incluso sin diccionarios. Quizás en download.com buscando un password recovery o similar.

Más que eso no te puedo decir puesto que desconozco tus intenciones con éste tipo de herramientas.

Password access
 

Gracias por tu idea, de hecho es lo que hago actualmente con el Cain y Abel el cual me recupera la contraseña con la que esta protegido el archivo. Pero mi intencion es poder abrir una base de datos de access de una aplicacion de un tercero, levantar los datos y hacer un procesamiento de ellos. La idea es poder automatizar el proceso de apertura de la base de datos haciendo algo mas generico y que no tenga que intervenir yo manualmente para obtener esa contraseña. Espero haber sido claro en la explicacion y desde ya gracias por tu interes.

Password acces
 

Buenas a todos,

Puedo decir que soy una vistima de hexxa, ya que en mi caso, un tercero se ha dedicado a reventar la contraseña y migrar mis datos hacia su base de datos.

Para resolver esto, una de las opciones que he barajado es ir modificando periódicamente el password de la base de datos, que hasta ahora era la misma para todos los clientes. Con esto conseguiria que, al menos, mi competencia tuviese que hacer un uso exclusivo en cada migración para buscar esa clave, lo cual rerasaría su expancion.

Pero con esta medida me asalta la duda de si es facil o dificl integrar código que descifre el password de la base de datos o no. Esto es, existen progrmas que revientan los passwords en medio segundo. Pero, ¿qué código es ese? ¿Alguien me lo puede pasar para que chequee la velocidad? Lo puedo integrar yo en mi programa o mi competencia en su programa?

Espero su ayuda. También de aquellos que son amigos de lo ajeno, querido hexxa.

Hola.

Según entiendo, los programas que hacen esto, lo hacen por fuerza bruta. Van probando distintas claves hasta que logran conectarse.

Una solución para esto es usar claves largas, compuestas por combinaciones alfanuméricas de mayúsculas y minúsculas, numéricas y símbolos, para que sea mas difícil de "romper", puesto que algunos programas, en lugar de ir probando con claves aleatorias o secuenciales, hacen uso de diccionarios de palabras, con lo que van aumentando las probabilidades de dar con la clave. Por eso también es recomendable usar palabras inventadas.

En cambio si usas una clave del tipo:

AxrTu98*xpM-&$#"2AmO

obviamente un programa como estos no logrará entrarle.

Ahora, dejo constancia de que desconozco, en el caso particular de access, si sea posible obtener la contraseña directamente de la base de datos (aunque lo dudo), en ese caso, cualquier protección por contraseña sería igual que no tenerla, aunque te queda la (mala) opción de encriptar los datos.

Hasta luego.

;)

Disculpa que me entrometa, pero ¿desde cuando es una mala opción encriptar los datos?
Para mi modo de ver, si la información que se guarda puede ser considerada sencible, con más razón encriptaría.

Espero que no lo tomes a mal, pero es que me ha resultado curioso dicho comentario.
Puedo estar equivocado... es sólo una pregunta.

Saludos,

Sé que access trae una seguridad por nivel de usuarios, me topé con un caso que comenté en éste hilo.

Busca en la ayuda por "creación de una cuenta de usuario de seguridad", creo que eso es lo que me pasó la vez anterior.

VB... Access... cuantos recuerdos me traen. En fin, para ir al punto: Access no tiene un sistema de seguridad infalible por sí sólo. Para obtener una clave de un MDB no hace falta utilizar la fuerza bruta, con cualquier programa bajado de Internet o mismo con un editor hexa y la info del formato de archivo en la mano sólo es cuestión de tiempo. De hecho hasta los archivos de sesiones (MDW) tiene el mismo problema.
Con una simple búsqueda en internet con la palabra "CRACK" y "ACCESS" dan una cantidad considerable de resultados. Además dado que tiene un cartel de M$ colgado y al tener una difusión masiva es un producto tentador para las malicias de algunas personas.

En cuanto a encriptar los datos mepa que depende mucho del tipo de aplicación. Hace un tiempo opté por la encriptación (paranoia?) de cada campo, menos de las PK, en las tablas de un motor Firebird. El resultado: lentitud en ejecución, aumento considerable de tamaño, depuración imposible mediante sentencias SQL y dificultad en la exportación/migración.

Como solución para Access yo optaría por validar las conexiones a la BD (Véase: http://support.microsoft.com/kb/287655/es, UserRoster) contra alguna lista de "conexiones buenas" ajena a la BD y por supuesto: encriptada. Claro que si hablamos de una aplicación mono-usuario yo comprimiría el archivo completo protegido por contraseña y desde la aplicación lo descomprimiría en alguna carpeta absolutamente temporal.

Saludos!

Hola Delphius.

No considero que sea malo encriptar los datos, si estos son realmente sensibles.

Lo que considero malo es llegar a la opción de encriptar TODOS los datos de una BD porque la seguridad de la misma es tan mala que no te queda de otra.

Como ya ha apuntado Gydba, y creo que yo no podría decirlo mejor:

Solo por mencionar un ejemplo sensible en lo relacionado con lentitud.

Si tenes un campo de texto y haces una búsqueda:

Código SQL [-]
select *
  from tabla
 where texto starts with 'abc';

Normalmente se usaría un índice, con lo que la consulta es muy rápida.

Por el contrario, si la base de datos está encriptada, no podría usarse ni el "starts with", ni el "like", con lo que no te queda de otra que abrir la tabla e ir recorriendola registro por registro para encontrar las coincidencias, seguramente en el cliente, a menos que con access tengas forma de meter un encriptador/desencriptador en el propio motor, con lo cual, por cierto, se rompería nuevamente el esquema "seguro".

Si tenes una tabla con, por decir un número, diez mil registros, puedo asegurarte que el tiempo de respuesta será por lo menos quinientas o mil veces mayor.

Como te digo, eso es solo un ejemplo, de algunos otros que se me ocurren.

En contra parte, he visto y trabajado algunas veces con la opción de encriptación nativa de oracle. ¡que maravilla!. Está pensada para el caso que alguien logre sustraer un datafile, pues no podría hacer ingeniería inversa para obtener de vuelta los datos, pero el motor mete sus propias optimizaciones y es casi tan rápido como con datos no encriptados... ya sabes, oracle es otra historia.

Hasta luego.

;)

Gabo, Lo de los niveles de seguridad "por usuarios", así es como lo teníamos: había creado un nuevo fichero MDW, y a mi base de datos le habia eliminado los permisos del usuario ADMIN, el que está por defecto, y habia asignado permisos a un nueo usuario MyAppUser. Al abrir la base de datos, la abro con ese MDW mediante el usuario MyAppUser y su contraseña, pero los amigos de hexxa la reventaron.

Por cierto jachguate, he provado tu contraseña y otras cuantas, a la cual más rara, y la desencriptación del password continua siendo prácticamente instantánea.

En cuanto a la idea de Gydba de capar por conexiones, no comprendo el concepto, ni leyéndome la ayuda de Microsoft. En cuanto a comprimir y descomprimir la base de datos, inviable, no es monousuario. Encriptar los datos... supongo que lo reventarán exactamente igual...

Tiene dificil solución, pero muchas gracias a todos.

Esto es debido a que, como ya comentarion, seguramente access almacena la contraseña dentro del propio archivo... así las cosas, solo es cosa de saber donde encontrarla y sea la que sea la encontrarán.

No necesariamente, dado que el algoritmo para encriptar/desencriptar lo elegís vos, al igual que las llaves que uses. Para no dejar la llave por allí en el ejecutable y que la encuentren fácilmente, podrías a su vez almacenarla encriptada, o por fragmentos en diferentes recursos, de manera que solo teniendo el código de la aplicación resulte viable obtenerla de vuelta.

Si la habilidad de los chavos está en conseguir utilitarios que obtengan la clave de access, pero no está en romper algoritmos o claves de encriptación la van a tener difícil, incluso con algoritmos sencillos basados en shl/xor, como los que podés encontrar en la jvcl: xorEncode, xorDecode, xorString, en la unidad jvStrUtils.

Claro que también hay métodos mas elaborados ya implementados desde delphi.

Como se ha dicho antes... la contraparte de esto es que la aplicación se ralentizará.

Hasta luego.

;)