If you limit the menus, etc., that are available (and definitely set the startup so the database window is not visible) that will help limit what users can do. Go to Tools, Startup, and uncheck most or all of the options.
Another good practice is to avoid making the MDB front end application file available to users. Create an MDE file (Tools, Database Utilities, Make MDE file) and only have that available for users. By doing that you prevent users from modifying or even seeing the code behind forms and reports.
Another step is to set most (or all) of the tables to be hidden. This means that if someone does successfully start with the shift kep they still won't see the tables immediately. Yes, they can make them visible, but whenthey are not seen it removes some of the temptation. If you really have problems with users, I'd consider hiding the real tables and setting up tables with almost the same names that are visible, have almost no data in them, and are really not usedexcept as diversions from the real (hidden) tables.
It's extremely difficult (if not impossible) to completely stop someone from using the SHIFT method of starting so the Autoexec macros aren't executed, so removing as much "temptation" from sight as possible (with the MDE file and hidden tables) may help a lot.
By the way, although removing the menus (thereby removing the access to the menu for changing passwords) should help prevent users from changing their passwords, I'm not sure why users should not be able to change their passwords. With Access security (if that's what you are using) you can always clear the password if necessary. Normally passwords in any security system cannot be read by the security administrator, just cleared or changed.