No fim das contas, parece mais realista usar senhas geradas aleatoriamente e gerenciá-las com um gerenciador de senhas com algo como 2FA.
Estou usando voltwarden em um servidor homelab.
Eu tendo a olhar com ceticismo para esse tipo de abordagem de definir senhas por meio de derivação (derivation). O principal motivo para usar um gerenciador de senhas é justamente que, por mais cuidadoso que eu seja, não tem como saber em qual serviço vai acontecer um vazamento. Nesse caso, quando houver um incidente, parece importante poder descartar a senha antiga e gerar uma senha completamente nova. Com um método baseado em derivação, isso parece difícil.
Daria para lembrar quantas vezes aquela senha derivada já foi gerada e incluir esse número na derivação, mas aí a pessoa teria que se lembrar de quantas vezes trocou a senha em cada serviço.
Então, como solução temporária, eu uso o ano ou o mês nas regras de derivação de senha que utilizo pessoalmente.
No sistema do trabalho existe uma regra que exige trocar a senha de login todo mês, e sem usar esse método de derivação eu acabava não conseguindo lembrar das mudanças a cada vez. Ao mesmo tempo, também não posso reutilizar senhas antigas, então, já que vou trocar todo mês de qualquer forma, acabei criando e usando uma regra de derivação meio improvisada que inclui informações de ano e mês.
Eu também, no lugar onde trabalhava antigamente, como a regra da porta de acesso tinha que ser trocada todo mês, acabei criando uma regra parecida usando ano e mês. Mas eram 4 dígitos...
últimos 2 dígitos do ano × 2 dígitos do mês, pegando os 2 últimos dígitos do produto, e os 2 últimos dígitos da soma
ex) março de 2023: produto 69, soma 26 -> 6926
Parecia bom, mas fiquei surpreso ao ver que, para mudar a senha, seria preciso mudar o nome de usuário (normalmente deve ser o ID também...). Pensando no método, faz sentido que seja assim.
6 comentários
Também existe o lesspass.com, que pode ser considerado o precursor.
No fim das contas, parece mais realista usar senhas geradas aleatoriamente e gerenciá-las com um gerenciador de senhas com algo como 2FA.
Estou usando
voltwardenem um servidor homelab.Eu tendo a olhar com ceticismo para esse tipo de abordagem de definir senhas por meio de derivação (
derivation). O principal motivo para usar um gerenciador de senhas é justamente que, por mais cuidadoso que eu seja, não tem como saber em qual serviço vai acontecer um vazamento. Nesse caso, quando houver um incidente, parece importante poder descartar a senha antiga e gerar uma senha completamente nova. Com um método baseado em derivação, isso parece difícil.Daria para lembrar quantas vezes aquela senha derivada já foi gerada e incluir esse número na derivação, mas aí a pessoa teria que se lembrar de quantas vezes trocou a senha em cada serviço.
Então, como solução temporária, eu uso o ano ou o mês nas regras de derivação de senha que utilizo pessoalmente.
No sistema do trabalho existe uma regra que exige trocar a senha de login todo mês, e sem usar esse método de derivação eu acabava não conseguindo lembrar das mudanças a cada vez. Ao mesmo tempo, também não posso reutilizar senhas antigas, então, já que vou trocar todo mês de qualquer forma, acabei criando e usando uma regra de derivação meio improvisada que inclui informações de ano e mês.
Eu também, no lugar onde trabalhava antigamente, como a regra da porta de acesso tinha que ser trocada todo mês, acabei criando uma regra parecida usando ano e mês. Mas eram 4 dígitos... últimos 2 dígitos do ano × 2 dígitos do mês, pegando os 2 últimos dígitos do produto, e os 2 últimos dígitos da soma
ex) março de 2023: produto 69, soma 26 -> 6926
Parecia bom, mas fiquei surpreso ao ver que, para mudar a senha, seria preciso mudar o nome de usuário (normalmente deve ser o ID também...). Pensando no método, faz sentido que seja assim.