Stesso utente, diversi punti di accesso, password diverse?

Perché hai una politica sulle password in primo luogo? È per evitare le password che sono "troppo deboli" (nel senso di: "troppo facilmente indovinato"). Le password deboli cessano improvvisamente di avere importanza sul sito Web solo perché lo stesso nome utente + password anche fornisce l'accesso all'applicazione back-end?

Se la politica della password sul sito Web ha un senso, deve applicarsi a tutte le password che funzionano sul sito Web.

D'altra parte, una politica più rigida per il back-end che per il sito Web può avere senso: le password che concedono l'accesso ad entrambe sono, tecnicamente, "più potenti" password, quindi è concepibile che dovrebbero essere "più forti". Ma questo è un argomento che agita la mano.

Il mio consiglio è il seguente: se l'applicazione Web e l'applicazione di back-end concedono l'accesso agli stessi dati, le politiche delle password dovrebbero essere identiche per entrambi. Ad esempio, applicare le regole più severe ovunque. Se riesci a costringere i clienti a seguire queste regole, sicuramente puoi fare lo stesso con i dipendenti?

Forse hai bisogno dell'autenticazione a due fattori in scenari che richiedono una convalida più strong in scenari "rischiosi" come VPN e web.

RSA, Arcot e Symantec sono alcuni che vengono in mente che offrono il doppio fattore

Stai usando un sistema di autenticazione? O devi creare account su ciascun sistema per gli utenti?

Se si dispone di un sistema di autenticazione, richiedere a tutti di registrarsi dall'applicazione Web (criterio severo) e disattivare la funzionalità di configurazione / modifica della password sul back-end. La politica della password viene applicata al momento della creazione / modifica, pertanto è necessario che ONE inserisca le proprie password in modo che vengano create e modificate.