DPAPI memorizza i dati protetti crittografati con la chiave DPAPI dell'utente, che viene a sua volta crittografata con una derivata (tramite PBKDF2) della password NTLM. Inoltre, le informazioni chiave relative a DPAPI sono memorizzate in un'area di memoria protetta all'interno del sottosistema di sicurezza (LSA), rendendo particolarmente difficile compromettere le chiavi master al di fuori di un contesto amministrativo.
Le due principali preoccupazioni nel modello di minaccia di DPAPI sono gli attacchi offline (ad esempio il disco rigido rubato) o un utente malintenzionato che tenta di compromettere i dati protetti da DPAPI di un altro utente. Entrambe queste minacce sono adeguatamente protette contro DPAPI.
Il timore che DPAPI consenta un facile recupero dei dati è infondato; il fatto che sia possibile recuperare le informazioni è dovuto al fatto che l'utente è stato registrato come utente legittimo. Effettuare l'accesso come qualsiasi altro utente renderebbe impossibile tutto ciò, come si farebbe per recuperare i dati protetti da DPAPI da un'immagine disco offline (a meno che non si conosca la password dell'utente che ha salvato i dati).
Qualsiasi soluzione implementata da te con AES (o qualsiasi altro codice) sarà meno sicura in questi casi.
Detto questo, se il modello di sicurezza dell'applicazione prevede l'assegnazione di password di servizio agli utenti in un file di testo crittografato, c'è ben poco da impedire loro di decodificarlo e ottenere le password. Sembra un candidato per aver loro autenticare i sistemi di back-end con i loro account utente individuali o avere un servizio di intermediazione a cui gli utenti si autenticano e che possono quindi effettuare richieste di servizio back-end per loro conto.