September 3rd, 2003, 08:46 PM
The company I work for uses a particular application to keep track of client information (including soc. sec. numbers). We email an export file once a week to kep the main database up tp date. Recently I got nosy, and discovered the file was actually an .mdb file. So i tried to fire it up into microsoft access. It tells me I don't have permission to open it. (no big surprise)
I open it in a hex editor and figure out a couple things. One, that it was compiled with Microsoft's Jet database engine (it says in plain text), and that a whole lot of other information is in plain text also. The most sensitive data fortunately is not plain text, but I can't see that it would be that hard to retrieve.
I know this sounds like a loaded question, but it's not. I'm trying to convince our IT (loose description) that there is a security risk based on the following assumption. If I can step around the password check, and I think I can, the document should open...
My argument has been that the file should be encrypted before being sent, and that there should be a checksum to make sure no "extra" bits of code have hitchiked along.
Is my assumption correct, and are my arguments correct? If I am correct, how can I show this person that I am correct?
September 3rd, 2003, 09:02 PM
I was able to find a utility to crack access mdb passwords in about 2 minutes. I downloaded it, and cracked a newly created password protected access 2000 mdb in under a minute. As default SMTP is clear text I would say that your information is not being transferred in a very secure manner at all.
September 3rd, 2003, 09:12 PM
You are 100% correct this is very insecure. The protection on an Access Database (Which is the JetEngine and why you see that in the .mdb) is easily cracked by many programs and hence should not be transferred via e-mail which is easily intercepted or sniffed. There are programs available for secure file transfers, one is SecureFX which uses FTP over a SSH2 connection and features an Explorer like GUI for ease of use.
\"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier
September 3rd, 2003, 09:17 PM
I tried to go that route also. It didn't work. I don't have my notebook in front of me right now, but when Googled for information about the database, the particular article I pulled up described how the password is stored, etc. Since the software we use creates the database, and software on the other end reads the database, the user (me) has no need to have the password.
But after looking at another document from microsoft, it looks like I need to reset the properties of my access to do what I want.
I agree. From what I have seen, it is a crappy way to store and transfer this kind of data...
Thanks you for your input.
EDIT: Hmm, maybe I need to snoop a little around the proggie and see if it is indeed on my drive.
September 3rd, 2003, 09:24 PM
A way you may be able to convince your administrator or whoever is in charge that there is a security risk is to obtain permission to crack the file (security testing) and do it right in front of the admin. I think that that would be pretty irrefutable proof that the system is not secure. If that still does not help, good luck.
ERROR: No Keyboard Detected
Press F1 to continue....
September 3rd, 2003, 09:45 PM
Just a quick update...I did find a different program that told me the database actually was not pass protected...so I just need to figure out why I don't have admin rights with access.
Thanks for the input!!!
September 3rd, 2003, 10:10 PM
One way to increase the security, without makin
I'll try that again!
To increase security, without making major changes to your transmission method, would be to:
1. Secure the database using standard MS Access Workgroup security.
2. Provide the recepient with a copy of the workgroup file, along with their relevant user account details.
3. Continue to send the MDB file, but do not send the MDW file.
Without both files, the security is going to be a damn sight harder to crack!
Hope this helps,
Please do not feed the trolls.
September 4th, 2003, 01:50 AM
thanks for everyone that has helped me thus far. After working on this for a little while, and trying a few different apps to recover passwords, I feel that I have taken 1 step foreward and 2 steps back.
2 of the 3 apps I used claimed the database is not password protected. I think that assessment is probably correct. So my assumptions about the lack of protection have proven true.
I still have not been able to find a way to prove to my admin that the database is vulnerable. Yes, I understand that I need to crack it right in front of them..that is spot on accurate...
So now I am down to 2 options. One, figure out why on earth I can't give myself admin privileges in Access (probably because I'm doing something stupid), or figure out how to step around the password check.
Anyway, at this point, any helpful references or applicable tutorials to get my brain re-fired would be appreciated.
September 4th, 2003, 08:55 AM
crack it! dont so hard to work.... OfficeRecovery?
September 4th, 2003, 09:03 AM
Is that under the job description? Probably not... so screw it. Even if your trying to help, thats a good way for someone to get you fired then replace you with the one of hundreds of other peaple waiting to take your spot off of the IT food-chain. You've reported a problem, they've most likely ignored, but atleast your being paid under other peaple's mistakes. Enought said.
Originally posted here by qinanty
crack it! dont so hard to work.... OfficeRecovery?