Uma breve e incompleta história sobre senhas: aliados e inimigos

OK, então como devem ser as nossas senhas para que sejam seguras? Devemos considerar alguns fatores. Em primeiro lugar, uma senha é um parâmetro, que passará por uma função para gerar um hash, que por sua vez será armazenado em uma base de dados. Um atacante pode usar funções que produzam o hash armazenado no banco de dados, através de tentativa e erro, adivinhando a senha definida pelo usuário.
Portanto, senhas são um recurso valioso que influem diretamente na segurança ou resistência à ataques.

Não é uma boa prática armazenar senhas criptografadas com chaves simétricas. Alguma vez você recebeu e-mails para recordar senhas que a traziam no corpo da mensagem? Pecado capital. Outro aspecto importante é o universo de caracteres permitidos, se houver a mensagem “somente utilizar caracteres alfanuméricos” ou “sua senha contém caracteres inválidos”, atenção, é uma indicação que as coisas não estão implementadas da maneira correta.

Breve e incompleta historia de las contraseñas, aliados y enemigos imagen

https://imgs.xkcd.com/comics/password_strength.png

Uma senha tem dois componentes principais: o número de caracteres e sua extensão. Você já jogou na loteria? Se você escolhe um número da sorte, como 01729, terá cinco cifras e cada uma delas com dez possibilidades, o que resulta na probabilidade de 1 em cem mil de você acertar os números sorteados. Esse é o mesmo conceito que podemos aplicar para o tamanho a senha. Quanto menos caracteres são permitidos, mais probabilidade de acerto estamos dando ao atacante.

Vimos antes que se um sistema restringe a seleção de caracteres especiais, significa ter menor nível se proteção. A intenção não é ruim e pode ser resultado de um controle defensivo como, por exemplo, evitar as injeções SQL quando se está introduzindo uma senha. Mas esse recurso não é o ideal, indica implementação incorreta.

Breve e incompleta historia de las contraseñas, aliados y enemigos (II) imagen 2

https://imgs.xkcd.com/comics/exploits_of_a_mom.png

O armazenamento de senhas não deve ser realizado assim, de maneira direta, com texto puro para os campos da base de dados que armazenam seus valores, só se deve armazenar seu hash. Dessa maneira, podemos ter uma senha “apagar banco de dados” que ela não executará nenhum comando.

As únicas restrições que se devem impor ao usuário são aquelas que o obriguem a criar senhas mais robustas. Tamanho mínimo, inclusão de caracteres especiais e o mais importante: que não seja uma senha habitual. Aqui podemos conta com bibliotecas que analisam a previsibilidade da senha proposta pelo usuário. Por exemplo, “12345” ou “qwerty”.

Uma senha para controlar todas as outras

O grande dilema de um usuário médio de informática é o seguinte: “uso 30 ou 40 sites diferentes em que tenho uma conta, como recordar a senha de cada um deles”? O fluxo de pensamento do usuário (qualquer usuário) é o mesmo que o de um líquido, continuar pelo caminho que ofereça menos resistência. Naturalmente a resposta seria ter uma senha fácil de lembra e que seja utilizada para todos os sites.

As listas de previsibilidade de senha se nutrem desse vício perverso. Assim, mesmo que tenhamos uma função hash robusta, criptografia com chave simétrica secreta e protegida, a falha segue ativa por conta do usuário, de sua má prática. O parâmetro imperfeito da equação.

Proteger o usuário é o mesmo que colocar cada vez mais travas, o que impacta o nível de usabilidade do site ou aplicação, o que não é algo positivo. Por isso, ao invés de criar obstáculos, precisamos de soluções que, neste caso, são os gerenciadores de senha. Eles centralizam, geram, propõem, armazenam e recuperar senhas conforme necessário.

Sejam eles integrados ao navegador ou na forma de software de terceiros, o gerenciador de senha permite obter um equilíbrio razoável entre segurança e comodidade. A única senha que precisaremos relembrar é a mestra que decifra o conteúdo do gerenciador, e esse é o único ponto de falha do gerenciador, ao perder senha mestra perde-se toda a base de senhas do usuário. Se trocarmos “perder” por “vazar” o cenário se torna mais trágico ainda. Usar a mesma senha para diversos sites causa, ainda, outro mal: atacantes sabem desse costume e utilizam as credencias em diversos sites e aplicações.

https://xkcd.com/792/

O segundo factor

O plano B. Quando tudo está perdido como evitamos o uso de uma senha descoberta através da derivação de um hash? Protegendo o início da seção com um segundo círculo de proteção, mas que esteja baseado em outro tipo de autenticação, não em uma senha. Para recordar: o que sabemos, temos ou somos.

Os códigos de uso único, o gerador de códigos aleatórios, a leitura de digitais, etc. Cada vez mais nos acostumamos a associar o início de uma seção com uma fechadura adicional, essa é uma medida que sacrifica um pouco da comodidade em prol da comodidade ao, por exemplo, exigir um segundo fator de segurança quando iniciamos uma seção em um dispositivo novo ou posição geográfica.

Essa não é uma bala de prata, longe disso. Mas consegue desempenhar sua função sem incomodar muito, ainda que dependa da aceitação do usuário, é um mecanismo simples e cômodo de implementar que se encontra cada vez mais e mais nos websites.

Nesse sentido, a ElevenPaths, unidade de cibersegurança da Telefônica, pensou em como melhorar a experiência do uso de um segundo fator de autenticação com uma proposta original: o melhor companheiro de uma fechadura é o cadeado. O Latch permite ter um segundo fator de segurança e mais: desconectar a autenticação quando ela não é necessária. Com plugins e SDK para diversas aplicações e linguagens de programação, além de um gerenciador TOTP para criar tokens de segundo fator de autenticação, é uma solução completa e intuitiva com clientes para todos os principais sistemas operacionais móveis.