Vorrei sottolineare che la risposta alla seconda parte della domanda ha poco a che fare con la prima parte.
Anche se la password è stata memorizzata in modo crittografato super-strong (non lo è), questo non sarebbe comunque sicuro, in diversi aspetti.
- L'utente ha accesso completo e senza restrizioni al database. Cioè può fare tutto ciò che vuole (secondo le autorizzazioni dell'utente condiviso ... I privilegi dell'utente sono limitati sul database, destra ?). Per esempio. accesso a dati non autorizzati, cancellazione di dati di altri utenti, inserimento di rifiuti, ecc.
- Sembra che ci sia un account utente condiviso, che tutti gli utenti abbiano collegato la loro connessione ODBC ... Il che significa che il server del database non ha modo di limitare l'accesso degli utenti, segregare i loro dati, tracciare chi ha fatto cosa, ecc.
- In ogni caso, la password ODBC dovrebbe essere decrittografata in memoria , consentendo all'utente di afferrarla, quindi impersonare l'applicazione e, di nuovo, fare ciò che vuole.
Faresti molto meglio a ridisegnare l'applicazione, con un livello intermedio e tutti ...
Trovo sempre strano discutere di security
e MS Access
nella stessa conversazione ...
Se non è possibile modificare l'architettura, prendi in considerazione l'utilizzo dell'autenticazione integrata di Windows e legando gli account utente (o il gruppo) a un ruolo db per la gestione. In questo modo, almeno ogni utente avrà il proprio account sul server, è possibile limitare l'accesso (in base al principio del privilegio minimo), nessun account condiviso ed è possibile tenere traccia delle azioni degli utenti sul database.