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.
- 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.
- 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.
- 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
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.