Segurança Digital
Argon2
Função de hashing de senhas com custo de memória, Argon2 transforma uma senha e um salt em uma saída resistente a ataques paralelos com GPU e ASIC. A RFC 9106 recomenda Argon2id, combinação das variantes i e d, e apresenta perfis como 2 GiB com 1 passagem ou 64 MiB com 3 passagens. Em plataformas de casa inteligente, protege credenciais de usuários no servidor; não serve para cifrar dados nem substitui TLS. Parâmetros precisam ser medidos no hardware e atualizados ao longo do tempo.
🛡 Níveis de Segurança
Recomendado
Argon2id com memória elevada
Argon2 pertence à classe das funções de derivação de chave baseadas em senha e foi desenhado para que cada tentativa custe não apenas ciclos de CPU, mas também memória. A RFC 9106 recomenda Argon2id para a maioria das aplicações porque combina a resistência a ataques de canal lateral da variante Argon2i com a resistência a ataques de trade-off de memória da Argon2d. O primeiro perfil recomendado pela RFC usa 2 GiB de memória, 1 passagem e paralelismo 4; é adequado quando o servidor possui recursos e a latência é aceitável. O segundo usa 64 MiB, 3 passagens e paralelismo 4, sendo mais viável em ambientes com memória limitada. Esses valores são pontos de partida, não números universais. Um servidor de automação com 8 GiB de RAM e dezenas de logins simultâneos não deve reservar 2 GiB por tentativa sem limitar concorrência. O projeto mede o tempo em produção e busca, por exemplo, 100–500 ms por verificação, conforme a experiência desejada e o risco. A memória por hash precisa ser multiplicada pelo número máximo de autenticações concorrentes. O resultado armazenado deve incluir versão, memória, tempo, paralelismo, salt e hash em formato reconhecível, permitindo rehash futuro. O salt é aleatório e único por senha, normalmente com pelo menos 128 bits. Ele não é secreto. A senha nunca é armazenada. Uma pepper secreta pode ser adicionada em HSM ou cofre, mas exige estratégia de rotação. Argon2id é suportado por libsodium, PHP, Python, Go, Java e bibliotecas modernas. A interoperabilidade depende de codificação, versão 0x13 e parâmetros idênticos. Não comparar strings de forma variável; usar função da biblioteca.
Operacional
Argon2id balanceado para serviços web
Para uma plataforma de casa inteligente que autentica moradores, instaladores e administradores, um perfil balanceado usa dezenas ou centenas de MiB e múltiplas passagens, ajustado por benchmark. O objetivo é tornar cada palpite caro para o atacante que roubou o banco, sem causar negação de serviço no login. O servidor deve aplicar rate limiting, MFA e monitoramento; Argon2 não impede tentativa online. Uma configuração de 64 MiB e 3 iterações pode consumir cerca de 64 MiB por verificação, mas o tempo depende de CPU, biblioteca e paralelismo. Um contêiner com limite de 128 MiB pode falhar sob duas autenticações. Definir limites e fila. Em clusters, todos os nós precisam suportar o mesmo perfil. A string codificada, como `$argon2id$v=19$m=65536,t=3,p=4$...`, permite que qualquer nó verifique. O sistema deve validar limites antes de processar um hash vindo de fonte não confiável, evitando que parâmetros absurdos causem exaustão. Ao migrar de bcrypt ou PBKDF2, verificar o hash antigo no login e gerar Argon2id novo com a senha em memória, sem pedir reset em massa. Senhas inativas podem permanecer antigas até o próximo login, mas contas críticas podem exigir atualização. O mecanismo de recuperação deve usar tokens aleatórios de uso único, não perguntas fracas. Em dispositivos embarcados, não executar perfil de servidor se faltam RAM e proteção. É melhor autenticar no hub seguro ou usar chaves/certificados. Argon2 em um ESP32 com pouca memória pode exigir parâmetros baixos que oferecem proteção limitada. O critério é onde o banco de senhas está armazenado e qual atacante se pretende atrasar.
Especializado
Argon2i para cenários específicos
Argon2i usa acesso à memória independente da senha e foi concebido para reduzir vazamento por side channel. Ele pode ser adequado em certos ambientes onde o atacante observa padrões de memória e o custo adicional de passagens é aceitável. A RFC 9106 ainda prefere Argon2id de forma geral. Não selecionar Argon2i apenas porque o nome sugere “mais seguro”. O modelo de ameaça precisa justificar. Em código compartilhado, virtualização hostil ou hardware com ataques de cache relevantes, a equipe deve consultar bibliotecas e orientação criptográfica atual. Argon2d usa acessos dependentes dos dados e oferece maior resistência a alguns ataques de hardware com trade-off de memória, mas é mais suscetível a canais laterais e não é a escolha padrão para senhas. A aplicação não deve expor ao usuário a seleção de variante. Isso é configuração de segurança. Um produto que permite escolher `d`, `i` ou `id` sem orientação aumenta erro. O hash deve registrar. Ao importar hashes, a biblioteca precisa suportar. A versão 1.3 do algoritmo é a referência da RFC. Implementações antigas podem usar versão anterior. O sistema deve identificar e rehash. Testes precisam incluir vetores oficiais, senhas Unicode normalizadas de modo consistente e entradas longas. A normalização é decisão da aplicação; mudar depois pode impedir login. Não truncar senha silenciosamente. O uso de UTF‑8 deve ser documentado. A função recebe bytes. O frontend e backend precisam concordar.
Evitar
Parâmetros fracos ou fixos por anos
O nível inadequado aparece quando a aplicação usa 4 MiB e 1 passagem por conveniência, copia parâmetro de exemplo antigo ou mantém o mesmo custo por dez anos. O algoritmo continua Argon2, mas a vantagem contra GPU diminui. Outro erro é usar salt fixo, igual para todos, permitindo pré-computação e revelando senhas iguais. Salt deve ser gerado por CSPRNG. Não usar nome de usuário como salt único, porque pode ser previsível e reutilizado entre sistemas. A saída não precisa ser cifrada no banco; precisa de integridade e controle de acesso, mas o atacante é modelado como capaz de roubar. Argon2 não substitui MFA, bloqueio de credenciais vazadas, rate limiting, TLS e gestão de sessão. Também não deve ser usado diretamente para derivar uma chave de disco sem definir formato, salt, parâmetros, autenticação e recuperação; soluções como LUKS já fazem. Em uma central residencial, armazenar senha de Wi‑Fi com Argon2 não ajuda se o sistema precisa recuperá-la em texto para configurar dispositivos. Nesse caso, a credencial deve ser cifrada com chave protegida, não hashed. Hashing é para verificar igualdade sem recuperar. Essa distinção evita projetos inviáveis.
🖥 Aplicações em Hardware
🔒
Plataforma e hub
Contas locais do Home Assistant, NVR e gateway
Serviços que mantêm contas locais podem usar Argon2id no backend. O banco guarda o hash codificado e metadados. O hub deve ter RAM suficiente e proteção de disco. A autenticação ocorre no processo privilegiado mínimo. Containers recebem limite compatível. Backups são cifrados porque contêm hashes, tokens e configuração. O usuário administrador usa MFA. A função é executada apenas no login e alteração de senha, não em cada comando. APIs internas usam tokens ou mTLS. Ao restaurar em hardware mais fraco, parâmetros podem causar lentidão; isso é preferível a reduzir silenciosamente. Uma migração explícita pode rehash no próximo login.
🔒
Cloud IoT
Serviço de identidade de fabricante
A cloud que autentica milhões de contas precisa balancear custo e disponibilidade. Parâmetros são benchmarkados por classe de servidor e revistos. O serviço usa salt individual, Argon2id, pepper em HSM opcional, rate limiting, MFA e detecção de senha vazada. Filas e autoscaling absorvem picos. Métricas não registram senha nem hash completo. A equipe testa DDoS de login e recuperação. A pepper aumenta proteção se banco vaza sem HSM, mas a perda da pepper impede todos os logins e a rotação exige plano. Ela não substitui salt. Em microsserviços, apenas o serviço de identidade verifica; outros recebem tokens. Isso reduz exposição.
🔒
Dispositivo embarcado
Painel local com recursos limitados
Um painel com Linux e 512 MiB pode usar Argon2id moderado. Um microcontrolador com 320 KiB não. Nesse caso, não reduzir para 32 KiB e declarar forte. Usar autenticação por chave, certificado, PAKE, secure element ou delegar ao hub. Se uma senha local é inevitável, escolher KDF compatível com recursos e reconhecer limitação. O banco local deve estar protegido. Um atacante com acesso físico pode extrair flash. Secure boot, criptografia de flash e bloqueio de debug complementam. A função deve ter implementação constante e biblioteca auditada. Não escrever Argon2 do zero. Atualizações precisam permitir elevar custo.
🔒
Ferramenta de instalação
Cofre de credenciais do integrador
Um cofre offline pode derivar chave mestra de uma senha com Argon2id e usar a chave para cifrar o banco com AES-GCM ou XChaCha20-Poly1305. Aqui Argon2 é KDF, não armazenamento de hash. O formato precisa incluir salt e parâmetros, e a cifra precisa autenticar. A senha deve ser forte porque o arquivo pode ser atacado offline. O perfil pode usar 1–2 GiB em notebook, se o tempo for aceitável. A ferramenta deve testar memória antes. Uma chave de recuperação deve ser protegida. Exportações não ficam em texto. O integrador não reutiliza a senha do portal. Esse uso difere do login, mas compartilha a função.