I noticed that there was a bit of confusion about MindRape's comments and I thought I would help clear them up. What he is talking about is that when one Microsoft Access database attaches to tables from another Microsoft Access database, the connection string (including the password) is stored in the MSysObjects table. Since you will need the database password to attach a table, you must have a database with the table already attached. However, it is not uncommon (and considered good practice) to have one database for code and another for the data tables. The point is to keep your code in a separate database and attach to the other tables so that when you update your code, you just replace the code database. The obvious problem with this is that the password to the data database is stored in the MSysObjects table of the code database. The quickest solution is to encrypt the database as well as using password protection. Of course, one should also set the proper rights and permissions on a production database. As added protection, the tables could all be attached in code using an autoexec macro. You could use the ACL to limit database access, but MindRapes' method would simply require read access. If you take away read access to the database, it isn't very useful. This same problem shows up anywhere you must save the connection string to a database. I often find passwords visible in plaintext in an executable that access a protected database. Connection strings can also be exposed on poorly protected .asp pages and cgi scripts. In short, it would be nice if Access encrypted the connection string by default but since it doesn't this is probably more of a misconfiguration exploit rather than a software bug. .sozni ____________________________________________________________________ Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:32:51 PDT