Como Protegemos Suas Senhas

Nos artigos anteriores, exploramos como o HTTPS protege a rota entre seu aplicativo e nosso servidor, e como o SSH protege o próprio servidor. Agora é hora de olhar dentro do servidor — em como o Splync mantém sua senha segura quando ela chega lá. Se alguém conseguisse sua senha, essa pessoa poderia se logar em sua conta e acessar informações sensíveis, incluindo seus registros de despesas. É por isso que o Splync nunca armazena senhas em texto simples. Em vez disso, cada senha é transformada em uma versão criptografada antes de ser salva no banco de dados. O que isso significa exatamente? A criptografia é uma conversão de mão única — uma vez transformada, ela nunca mais pode ser convertida de volta para a senha original. Este método é padrão na internet, de bancos a grandes serviços de nuvem, mas muitas pessoas não sabem como realmente funciona. Vamos explorá-lo através de uma analogia simples do dia a dia.

Para entender como a proteção de senhas funciona, começamos com um método de criptografia simples chamado SHA-256. Pense nele como um liquidificador que sempre mistura os ingredientes do mesmo jeito. Se você colocar a mesma senha no liquidificador e apertar o botão, você sempre obterá o mesmo smoothie único — uma mistura embaralhada de letras e números. A ideia principal é que o processo não pode ser revertido. Assim como você não pode pegar um smoothie e separá-lo de volta na banana e no leite originais, você não pode pegar o hash embaralhado e recuperar a senha original.

SHA-256 é um dos algoritmos de criptografia mais comuns. Por exemplo, ele transforma a senha "splync1234" em "9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41". Em milissegundos, toda vez que um usuário existente insere uma senha de login, o SHA-256 sempre produz a mesma senha criptografada. O aplicativo simplesmente criptografa a senha inserida novamente e verifica se ela corresponde ao hash armazenado. Em nenhum momento o sistema sabe a senha original do usuário. Mas e se um invasor pré-calcular uma lista de senhas comuns e seus hashes (conhecido como ataque de tabela arco-íris) para adivinhar rapidamente as senhas dos usuários? Essa preocupação é muito real. É por isso que sistemas modernos, incluindo o Splync, não confiam apenas no SHA-256 puro.

O bcrypt usa um 'sal' aleatório por usuário e codifica esse sal (e o fator de custo) diretamente na string de hash armazenada. Pense no bcrypt como um liquidificador com um tempero secreto (sal) e um motor lento (fator de trabalho) — ele torna cada mistura única e mais difícil de copiar. Como o sal tem 128 bits (≈3×10³⁸ possibilidades), a mesma senha pode corresponder a um número astronomicamente grande de hashes armazenados diferentes. Isso torna tabelas arco-íris pré-computadas inúteis em larga escala. Durante o login, o Splync lê o sal e o custo da string bcrypt salva, executa novamente o bcrypt na senha inserida com esses parâmetros e compara o resultado com o hash armazenado. Se eles correspondem, a senha está correta — mas como o bcrypt é intencionalmente lento e os sais são únicos, ataques de força bruta se tornam muito mais caros para um invasor.

Vamos ver como isso funciona na prática. Se você criptografar a senha "splync1234" com bcrypt (usando custo 12), você pode obter uma string como esta: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. Nesta string bcrypt, `$2b` marca a versão do algoritmo, `$12` mostra o fator de custo (quantas vezes a senha é processada), `gBeouKYdue9uvvuV0HtGgeV` é o sal aleatório único, e `PymnrojMqP/wcRw28HFlGEGIQbyw7O` é a senha final criptografada. Como o próprio hash contém o sal e o custo, o Splync pode reproduzir o mesmo processo de criptografia para verificação extraindo esses valores da string armazenada e comparando o resultado. Por outro lado, se um invasor não souber o sal e o custo, ele não poderá criar uma única tabela arco-íris que funcione para todos os usuários.

Essa abordagem tem outra vantagem importante. Como o Splync nunca armazena senhas simples, mesmo que o banco de dados fosse vazado ou roubado, os usuários não estariam imediatamente em risco. Os invasores não podem fazer login diretamente com os dados roubados, porque o que eles têm são apenas strings embaralhadas. Este design dá aos usuários uma camada extra de proteção, além das salvaguardas que já existem em torno do próprio servidor. A criptografia de senhas não é exclusiva do Splync; é o padrão na indústria de tecnologia, usado por gigantes como Google, Apple e Amazon. O Splync foi construído de forma muito segura, e ficará ainda mais seguro à medida que continuarmos melhorando a segurança com recursos como verificação por e-mail, proteção contra força bruta e monitoramento contínuo.