As escolhas básicas são: alguma coisa que você seja (autenticação biométrica, por exemplo), alguma coisa que você tenha (um token de senhas com temporizador) ou alguma coisa que você saiba (uma senha ou uma frase de segurança).

A biometria não funciona muito bem, pois é preciso existir um leitor biométrico seguro do outro lado. O número de usuários com um desses equipamentos é praticamente nulo. Os tokens com temporizadores são caros, precisam ser enviados para os usuários e carregados para lá e para cá. Nenhum dos dois métodos funciona quando um computador, e não uma pessoa, precisa de autenticação.

O que sobra, então, são as senhas, e isso apresenta dois problemas: você precisa autenticar alguma coisa e alguma precisa autenticar você.

Uma das coisas mais difíceis de fazer com segurança é autenticar algo, pois, a menos que o usuário digite a senha toda vez que utilizar um programa, é preciso armazenar as credenciais em um lugar onde o programa possa recuperá-las.

Então, o que pode ser feito para que as senhas estejam seguras? O método tradicional é a criptografia das senhas; no entanto, para descriptografá-las é preciso... bem, uma senha. Voltamos à estaca zero, mas com uma vantagem, a senha está protegida no caso de um invasor conseguir copiá-la do sistema. Mas esse esquema de proteção não funciona no caso de um programa que precise ser executado se intervenção humana (a senha do banco de dados usada por um aplicativo web PHP no momento de uma requisição, por exemplo) como foi o caso dos ataques aos clientes da Network Solutions, que comprometeram os blogs do WordPress acessando os bancos de dados com a senha salva no arquivo de configuração do WordPress, que podia ser lido por outros usuários no mesmo servidor.

O melhor (e único) modo de proteger senhas armazenadas para uso automático é a aplicação de permissões severas de arquivos que não permitam que outros usuários os acessem. Com sorte, o programa pode ser inicializado com privilégios elevados e depois derrubá-los, permitindo, assim, a restrição de acesso ao arquivo de configuração de um usuário específico que não seja usado para mais nada. No entanto, isso geralmente não existe em aplicativos web e programas relacionados.

Para aplicativos de desktop locais que precisam ser autenticados em uma servidor remoto (por exemplo, um cliente se email ou um programa que seja executado em segundo plano ), é possível utilizar um sistema de armazenamento de chaves, como o Gnome Keyring ou o KDE Kwallet. A autenticação no armazenamento de chaves é feita, e depois o Keyring ou Kwallet libera o acesso de credenciais e senhas armazenadas para os programas que solicitam. Logicamente, isso não funciona muito bem em aplicativos não vigiados e que não são executados no desktop.