Política de Segurança

Um sistema que guarda o extrato de alguém deve explicar como o protege — e, principalmente, o que ainda não protege. A segunda metade deste documento é a que importa mais, porque é a que ninguém costuma escrever.

1. Sua senha

• A senha nunca é gravada. O que fica no banco é um resumo criptográfico produzido por bcrypt, um algoritmo feito de propósito para ser lento, o que torna inviável testar bilhões de tentativas contra o banco caso ele vaze.
• Não há como voltar do resumo à senha. Nem para quem administra o servidor, nem para quem escreveu o programa.
• O mínimo exigido é de oito caracteres.

2. Sua sessão

• Ao entrar, o servidor assina um token (JWT, algoritmo HS256) que só carrega o número da sua conta e a validade. Ele não contém nome, e-mail nem dado financeiro.
• O token viaja num cookie httpOnly, invisível para o JavaScript da página. Assim, uma falha de script na interface não consegue roubar sua sessão.
• SameSite=Lax impede que outro site use a sua sessão para agir em seu nome — é a defesa contra CSRF.
• A cada requisição, além de conferir a assinatura, o servidor busca a sua conta no banco. A assinatura prova que o token saiu daqui; a consulta prova que a conta ainda existe.
• A sessão vale trinta dias, e sair da conta a encerra na hora.

3. Contra tentativa e erro

• Cinco senhas erradas travam novas tentativas, com bloqueio que cresce a cada rodada — um minuto, cinco, quinze, uma hora. Quem esqueceu a senha mal percebe o primeiro minuto; quem está varrendo senhas para de valer a pena.
• A trava fica gravada no banco, e não em memória: reiniciar o servidor não a zera.
• E-mail inexistente e senha errada produzem a mesma mensagem, e o sistema gasta o mesmo tempo de processamento nos dois casos. Sem isso, a diferença de tempo de resposta contaria a quem tenta invadir quais e-mails estão cadastrados.
• A criação de contas também é freada por origem, para um script não encher o banco.

4. Isolamento entre contas

Toda consulta ao banco filtra pelo número da sua conta, sem exceção. Não existe tela, filtro ou endereço que devolva o dado de outra pessoa — e o banco reforça isso por estrutura, com cada tabela apontando para o dono. Ao apagar um usuário, tudo o que é dele é apagado junto, em cascata.

Toda entrada que chega ao servidor é validada por esquema antes de tocar o banco, e as consultas usam parâmetros — não texto montado —, o que fecha a porta de injeção de SQL.

5. O aplicativo instalado

Se você instalou o FinanCerto na tela inicial, ele guarda arquivos no seu aparelho para abrir rápido e funcionar sem rede. A regra ali é uma só e é deliberada: nenhum conteúdo da sua conta é gravado no aparelho.

Ficam guardados apenas código, estilo, fontes e ícones — coisas que não são de ninguém. Página, saldo, extrato e resposta do servidor vão sempre à rede. O motivo é duplo: o armazenamento do navegador sobrevive ao “Sair da conta”, e saldo velho que abre instantâneo é pior que saldo nenhum, porque não avisa que está desatualizado.

6. O que o sistema NÃO faz

• Não há verificação em duas etapas. Quem souber sua senha entra.
• O banco não é criptografado em repouso. Seus valores estão em texto legível no arquivo do servidor. Quem tem acesso ao disco tem acesso aos números — só a senha é irreversível.
• Não há registro de acessos bem-sucedidos. O sistema anota falhas de login, não entradas. Não existe uma tela de “seus últimos acessos”.
• Não há recuperação de senha. Como o sistema não envia e-mail, esquecer a senha significa depender de quem administra o servidor.
• O HTTPS não vem embutido. Proteger o tráfego entre o seu navegador e o servidor é responsabilidade de quem hospeda. Sem HTTPS, sua senha atravessa a rede legível — veja as Diretrizes.
• O backup sai sem criptografia. É de propósito, e passa a ser sua responsabilidade a partir do download.
• Não há auditoria externa. Este sistema não passou por teste de invasão nem por revisão de segurança independente.

7. O que depende de você

• Uma senha longa e usada só aqui. Um gerenciador de senhas resolve as duas coisas.
• Sair da conta ao usar computador compartilhado.
• Baixar o backup de vez em quando. Nenhuma proteção deste documento cobre um disco que queimou.
• Guardar o arquivo de backup em lugar restrito.

8. O que depende de quem hospeda

• Uma chave AUTH_SECRET longa e aleatória, diferente da do exemplo. Ela é o que impede qualquer pessoa de forjar uma sessão.
• HTTPS na frente do sistema.
• Cópia de segurança do arquivo do banco, e restrição de quem acessa o servidor.
• Manter as dependências atualizadas.

9. Encontrou uma falha?

Se você encontrou uma vulnerabilidade, avise antes de tornar pública, e dê tempo para a correção. Descreva o que é possível fazer com a falha e como reproduzi-la. Não use dados de outra pessoa para demonstrar o problema — uma conta de teste criada por você mesmo prova a mesma coisa e não expõe ninguém.