I have been working on a program that uses MS Access and ODBC to connect to an SQL server. One of the requirements is that the user need not know the password for the connection to the SQL server, so I checked the 'Save Password' check box when linking my SQL tables.

Does anyone know where the password is stored and how secure it is when this action is performed?

3 Answers 3


I would like to point out, that the answer to the second part of the question has little to do with the first part.

Even if the password was stored in a super-strong encrypted fashion (it's not), this would still not be secure, in several aspects.

  1. The user has complete, unfettered access to the database. I.e. he can do anything he wants (per the permissions of the shared user... The user's privileges are restricted on the database, right?). E.g. accessing any unauthorized data, deleting other users' data, inserting garbage, etc.
  2. This sounds like there is a shared user account, that all the users have plugged into their ODBC connection... Which means, the database server has no way of limiting users' access, segregating their data, tracking who done what, etc.
  3. In any event, the ODBC password would need to be decrypted in memory, allowing the user to grab it, and then impersonate the application and again, do whatever he wants.

You'd be much better off redesigning the application, with a middle-tier and all...
I always find it odd discussing security and MS Access in the same conversation...

If you absolutely cannot change the architecture, consider using Integrated Windows Authentication, and tying user accounts (or group) to a db role for management. That way, at least each user will have his own account on the server, you can restrict access (according to the principle of least privilege), no shared accounts, and you can track each users actions on the database.


The ODBC password details can be addressed by firing up odbcad32.exe on your Windows box and interacting with the dialog box. I think the details you are looking for are found in the last few paragraphs of ACC2000: No Password Prompt Appears When Using Microsoft Access .MDB with ODBC

  • 2
    Thanks! But we generally discourage listing references rather than actually explaining the answer, especially when the reference isn't easy for many folks to follow (e.g. those without the given software on their system). And all references tend to rot over time as systems and software and web sites change. Can you paraphrase what you see there?
    – nealmcb
    Jul 15, 2011 at 15:24
  • Point taken. The good news is this reference is valid six years later for the current Microsoft Access offering. The bad news is the answer has no easy answer in my opinion. Explaining the use and role of ODBC, a middleware connector, is probably better placed in other StackExchange groups as perhaps is this question. My understanding of this audience’s baseline knowledge of this specialized technical subject suggest the read of that explanation would also be frustrating. My hope was to at least give the questioner a good starting point and perhaps quick insight. In future I'll avoid.
    – zedman9991
    Jul 15, 2011 at 16:06
  • That's interesting and surprising to hear. But I'm still just about totally in the dark. I think the aspect that bears on this site is the question of how secure that storage is, and how much of a risk it is to 'check the "save password" check box'. Other systems like Firefox often encrypt such passwords and the question is how well that is done and how strongly protected the encryption keys for that storage are.
    – nealmcb
    Jul 15, 2011 at 16:18

This was the first result in google when looking at where ODBC passwords are saved in general.

It turns out that they are stored in plaintext in the Windows registry. Open up regedit and have a look under:



You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .