DEV Community: Gideon Cohen

Arquitetando a Próxima Geração: Microsserviços e a Engenharia de Baixa Latência na Web3

Gideon Cohen — Wed, 11 Feb 2026 10:01:54 +0000

A transição para a era da "Finança Cognitiva" exige uma infraestrutura que vá além dos modelos de exchange tradicionais. No ecossistema SQHWYD, implementamos uma arquitetura baseada em microsserviços para garantir que o sistema seja modular, resiliente e escalável horizontalmente. Esta abordagem permite que componentes críticos, como o Matching Engine, operem de forma independente de serviços de interface ou custódia, evitando que falhas em um módulo impactem todo o ecossistema.

O coração técnico desta operação é o nosso motor de correspondência, engenheirado para processar milhões de ordens por segundo com latência sub-milisegundo. Utilizamos processamento in-memory para garantir velocidade máxima em cancelamentos e execuções , além de filas de mensagens assíncronas via Apache Kafka para assegurar que nenhum evento de transação seja perdido sob carga extrema.

Como consultor de segurança, priorizamos a Unity Layer™, que abstrai a complexidade entre CeFi e DeFi. Ela funciona como o "sistema nervoso" da plataforma, integrando-se nativamente com protocolos como Aave e Lido para oferecer rendimentos com um único clique. Essa integração é protegida por uma doutrina de "Segurança em Primeiro Lugar", utilizando carteiras de Computação de Múltiplas Partes (MPC) que eliminam pontos únicos de falha ao distribuir os estilhaços das chaves privadas. O objetivo final é uma infraestrutura massivamente escalável, pronta para a economia tokenizada de trilhões de dólares do amanhã.

https://www.sqhwyd.net/

Sessão e identidade: por que o “contexto” decide a segurança de uma ação

Gideon Cohen — Sun, 25 Jan 2026 04:07:29 +0000

Sou Gideon Cohen, consultor de segurança e criptografia do SQHWYD. Este post é informativo e técnico; não é aconselhamento financeiro, jurídico ou de investimento.

Em produtos financeiros digitais, segurança raramente falha por falta de criptografia. Ela falha por identidade e sessão. Uma credencial pode vazar, um token pode ser copiado e um dispositivo pode estar comprometido sem sinais óbvios. O que separa um incidente pequeno de um grande é o quanto o sistema confia em suposições.

A abordagem baseada em contexto reduz esse risco. Em vez de tratar todo acesso como igual, o sistema avalia sinais do ambiente: dispositivo conhecido, consistência de uso, mudanças bruscas e ações sensíveis. Isso permite fricção proporcional. Operações comuns seguem fluidas; operações críticas exigem validações adicionais.

Outro ponto é o “escopo” de credenciais. Tokens e chaves precisam ter permissões mínimas e duração adequada. Um token amplo demais vira multiplicador de impacto. Rotação e revogação práticas completam o ciclo, porque nenhum controle é perfeito: quando há suspeita, o sistema precisa invalidar rápido e registrar o motivo.

Por fim, logs úteis são parte do produto. Se uma decisão de segurança foi tomada, ela deve ser rastreável. Com trilha e critérios claros, o time reduz falsos positivos, melhora resposta e evita improvisos. Em segurança, contexto não é luxo; é o que torna decisões previsíveis.

https://www.sqhwyd.net/

Sessões e credenciais: o ponto fraco mais comum em produtos financeiros

Gideon Cohen — Mon, 12 Jan 2026 09:35:34 +0000

Sou Gideon Cohen, consultor de segurança e criptografia do SQHWYD. Este post é técnico e informativo; não é aconselhamento financeiro, jurídico ou de investimento.

Em produtos que lidam com dinheiro, autenticação é mais do que login e senha. É um conjunto de decisões de engenharia que define o custo de um ataque e o custo de um erro humano. Um fluxo rápido pode ser frágil; um fluxo rígido demais pode empurrar usuários para atalhos inseguros. O equilíbrio vem de camadas e de sinais confiáveis.

Um ponto subestimado é a sessão. Muitas invasões não acontecem porque alguém “quebrou criptografia”, mas porque a sessão ficou exposta: dispositivo compartilhado, navegador desatualizado, extensões invasivas ou tokens que vivem tempo demais. Uma boa arquitetura de sessão tem expiração coerente, revogação simples e visibilidade para o usuário revisar acessos e encerrar sessões que não reconhece.

Outro ponto é reduzir o poder de uma credencial. Em APIs, chaves e tokens deveriam ter escopo mínimo e duração adequada, com rotação e revogação planejadas. A diferença é enorme entre “uma chave vazou” e “tudo vazou”. O mesmo vale para permissões internas: separar responsabilidades e limitar privilégios diminui o raio de explosão de falhas operacionais.

Por fim, há o elemento humano. Segurança precisa ser compreensível. Alertas claros, sinais consistentes contra phishing e confirmações em ações sensíveis funcionam porque diminuem decisões impulsivas. A meta não é impedir o uso; é impedir o uso errado quando a distração aparece.

https://www.sqhwyd.net/

Passkeys e autenticação resistente a phishing: o que muda de verdade para produto e engenharia

Gideon Cohen — Tue, 06 Jan 2026 10:01:06 +0000

Gideon Cohen (CA) — consultor de segurança e criptografia da SQHWYD.

Autenticação é onde fricção e risco se encontram. Times de produto querem reduzir abandono. Times de segurança querem reduzir tomada de conta. Por anos, o compromisso foi aumentar etapas. O problema é que ataques mudaram. Phishing ficou mais convincente do que a maioria das pessoas consegue avaliar com atenção constante.

O que autenticação resistente a phishing tenta fazer é simples de explicar: reduzir dependência de “atenção perfeita do usuário”. Quando um método exige que o usuário digite uma senha e confirme um código em qualquer página que pareça legítima, o atacante só precisa clonar a experiência e controlar o ritmo. A interface vira o vetor. E interface é fácil de copiar.

O ganho real de mecanismos resistentes a phishing é o vínculo com o domínio legítimo. Quando a credencial não funciona fora do domínio correto, o phishing perde o núcleo do golpe. Isso não elimina risco, mas elimina uma classe inteira de ataque com bom custo-benefício.

Para times de produto, a implementação que dá certo é aquela que respeita a experiência e protege recuperação. Se você melhora login, mas mantém recuperação como um atalho frágil, você só mudou o lugar onde o atacante entra. Recuperação é parte do sistema de autenticação, não um detalhe de suporte.

Para engenharia, o foco precisa incluir sinais. Autenticação não termina em “success”. Ela precisa produzir observabilidade: padrões de dispositivo, mudanças de localização, tentativas repetidas, ritmo anômalo. E precisa de controles de abuso que não punam usuários legítimos com falsos positivos constantes. Segurança que destrói experiência vira desativada ou ignorada.

Para segurança, a pergunta útil é medição. Você não mede por quantas pessoas habilitaram um recurso. Você mede por redução de resets por golpe, queda de ATO, redução de tickets de “perdi acesso”, aumento de sucesso de login com menos atrito e diminuição de casos em que um usuário foi conduzido a autorizar a ação errada.

No fim, o que funciona é o que reduz dependência de heroísmo. Se o seu sistema exige que o usuário seja perfeito todos os dias, o atacante vai ganhar em um dia ruim. A missão de um bom desenho de autenticação é tornar o dia ruim menos caro.

https://www.sqhwyd.net/

npm audit Won't Save You: Why We moved to TEEs (Trusted Execution Environments)

Gideon Cohen — Thu, 18 Dec 2025 12:07:59 +0000

As developers, we are obsessed with code quality. We run linters, we do static analysis, and we patch dependencies. But in the world of digital asset custody, I’ve learned a hard lesson: Perfect code running on compromised hardware is still a vulnerability.

I’m Gideon Cohen. After years of auditing smart contracts (and founding Halborn), I’ve shifted my focus to infrastructure architecture at SQHWYD. The biggest gap I see in Web3 development right now isn't in Solidity; it's in the server environment.

If your private key management service runs on a standard Linux instance, you are at the mercy of the OS kernel. A rootkit, a zero-day in the hypervisor, or a rogue admin with sudo access can dump the memory and extract the keys. Encryption at rest means nothing if the key must be decrypted in RAM to sign a transaction.

The Shift to Enclaves This is why we are enforcing the use of TEEs (Trusted Execution Environments), like Intel SGX or AWS Nitro Enclaves.

A TEE acts as a "black box" within the CPU. It isolates the signing logic and the key shards from the rest of the system. Even the operating system cannot peek inside. Even I, as the security advisor, cannot SSH in and read the memory.

How we implement it:

Isolation: The signing service runs inside the enclave.

Attestation: Before the enclave receives a key shard, it must cryptographically prove (Remote Attestation) that it is running the correct, unadulterated binary.

Ephemeral Execution: The key is reconstructed (via MPC), signs the tx, and vanishes—all within the encrypted memory space of the CPU.

We need to stop building financial apps like they are social networks. The stakes are different. If you are building custody solutions, move the trust anchor from the Admin to the Silicon.

https://www.sqhwyd.net/