Como os seus dados e os códigos dos seus vales são protegidos

1. O que conservamos, e durante quanto tempo

Por este serviço passam quatro tipos de material sensível: os códigos dos vales, os documentos de identidade e os dados neles lidos, o registo da ordem, e o registo de auditoria que anota quem acedeu a quê. O registo da ordem contém a marca do vale, o valor facial, o destino de pagamento que nos indicou, o resultado da verificação e as marcas de data e hora que a acompanham.

Cada um tem uma vida diferente. O código de um vale é o que vive menos tempo dos quatro. Existe desde o momento em que o submete até a ordem ser liquidada, e depois é destruído. Todo o resto é um registo, e os registos são conservados durante cinco anos, porque quem opera neste negócio tem de conseguir reconstituir o que fez e porquê.

Não guardamos nada que permita que dinheiro saia das suas contas. Um destino de pagamento é um endereço, não uma credencial: um endereço de carteira, um IBAN, um endereço PayPal. Não pedimos números de cartão, palavras-passe de banca eletrónica, códigos PIN nem códigos de utilização única enviados pelo seu banco. Quem lhe pedir uma dessas coisas em nosso nome não somos nós.

2. O código de um vale, da submissão à destruição

Um código segue um só caminho, e é curto.

1. Submete-o. O código viaja do seu navegador para os nossos servidores através de uma ligação cifrada. É escrito no formulário de ordem deste site e em mais lado nenhum.
2. É cifrado à chegada. Antes de ser escrito no armazenamento, o código é cifrado. Não é escrito num registo aplicacional, num relatório de erro, na cópia de segurança de um registo, nem numa mensagem de correio eletrónico.
3. Um único operador fica com a ordem. O código pode ser lido pelo operador que trata dessa ordem, e apenas enquanto a ordem estiver aberta. Não é visível para os restantes membros da equipa, e não é visível em nenhum ecrã a que possa aceder.
4. Cada leitura é registada. De cada vez que o código é decifrado e mostrado, entra uma linha no registo de auditoria: que operador, que ordem, a que horas.
5. O operador verifica-o junto do emissor. A verificação é feita por uma pessoa, por telefone ou através do canal do próprio emissor, antes de qualquer movimento de dinheiro. Como verificamos um vale descreve esse passo em detalhe.
6. A liquidação é feita por duas pessoas, não por uma. O operador que aprova a ordem não pode ser o operador que liberta o pagamento.
7. O código é destruído. Assim que a ordem é liquidada, o código é retirado do armazenamento. O que subsiste é o registo da ordem, não o código que a financiou.

Há aqui um ponto que merece ser dito com clareza: um ser humano lê mesmo o seu código. Verificar é ler o código ao emissor, por isso não pode ser de outra maneira. A questão não é se alguém o vê. A questão é quão poucas pessoas, durante quanto tempo e com que registo — e as respostas são: uma, até à liquidação, e todos os acessos registados.

3. A cifragem em repouso, e o que ela não faz

Cifragem em repouso significa que o que está no armazenamento é texto cifrado. Uma cópia da base de dados, um ficheiro de salvaguarda ou um disco retirado de uma máquina são ilegíveis sem a chave, e as chaves são guardadas separadamente dos dados que protegem, pelo que obter uma coisa não é obter a outra.

É tudo o que ela faz, e vale a pena ser claro sobre o que fica de fora.

A cifragem em repouso não protege os dados em utilização. Uma aplicação em funcionamento tem de conseguir decifrar um código para o mostrar ao operador que o está a verificar, pelo que um atacante que tome o controlo da aplicação em funcionamento está dentro da mesma fronteira em que a aplicação está. Também não protege contra uma pessoa com acesso legítimo que abuse desse acesso. E não faz absolutamente nada quanto ao que aconteceu a um código antes de chegar até nós.

É por causa dessas lacunas que existem os outros controlos. O acesso estreito, a leitura registada, a vida curta e as duas pessoas sobre o dinheiro não são um enfeite à volta da cifragem. São as peças que cobrem aquilo que a cifragem não consegue cobrir.

4. Porque guardamos uma impressão digital do número do documento, e não o número

Porque precisamos de reconhecer um documento outra vez sem guardar o número que o identifica.

Uma impressão digital é o resultado de um cálculo unidirecional. O mesmo número de documento produz sempre a mesma impressão digital, e a impressão digital não pode ser convertida de volta no número. Isso chega para o trabalho que de facto precisamos de fazer: ver que o mesmo passaporte foi apresentado em duas contas diferentes, ou que um documento que recusámos anteriormente voltou, ou que o documento em arquivo é o documento que temos à frente.

Há um ataque óbvio a esta ideia, e devemos nomeá-lo. Um número de documento é curto e segue um formato previsível, pelo que alguém na posse de uma tabela de impressões digitais simples poderia percorrer todos os números possíveis, calcular a impressão digital de cada um e procurar uma correspondência. É por isso que o cálculo inclui um valor secreto guardado separadamente da base de dados. Sem ele, uma tabela de impressões digitais roubada é uma tabela de valores que não significam nada.

A impressão digital não é a história toda, porque a imagem do documento continua a existir. É esse o assunto da secção seguinte.

5. Como os documentos de identidade são guardados e disponibilizados

São guardados fora da raiz do servidor web, que é a parte prática da resposta.

Um servidor web publica ficheiros a partir de um diretório. Tudo o que esteja dentro desse diretório está a um endereço adivinhado ou divulgado de distância de se tornar público, qualquer que fosse a intenção. Os documentos de identidade não estão nesse diretório. Nenhum endereço web aponta para eles, pelo que nenhum endereço pode ser partilhado, reencaminhado, indexado ou descoberto por força bruta.

Para ver um documento, um membro da equipa tem de ter a sessão iniciada, e o pedido passa por uma rota que verifica a sessão, verifica se essa pessoa tem direito a ver aquele documento, escreve uma linha no registo de auditoria e só então devolve a imagem. A linha é escrita quer alguém venha a ler o registo, quer não. Os ficheiros são também cifrados em repouso.

Não usamos hiperligações impossíveis de adivinhar para os documentos. Uma hiperligação que funciona para quem quer que a tenha é uma hiperligação que funciona para quem quer que a receba por reencaminhamento, inclusive por acidente. Cada visualização passa pela rota autenticada e auditada, ou não acontece.

A razão pela qual os documentos são exigidos é uma questão distinta, respondida na política de verificação de identidade. São conservados documentos dos clientes cujo volume acumulado ao longo de um período móvel de doze meses atinge EUR 1,000. Abaixo desse valor, um cliente transaciona com um nome completo e um país de residência declarados, e não há documento nenhum para guardar.

6. O registo de auditoria, e porque só admite acréscimos e é encadeado por impressões digitais

O registo de auditoria anota quem viu o quê, e está construído de forma a que as linhas não possam ser removidas ou alteradas em silêncio.

Só admitir acréscimos significa que as linhas são acrescentadas e nunca atualizadas nem apagadas. Não existe na aplicação nenhum caminho normal que edite uma linha passada, porque o valor do registo está em dizer o que aconteceu e não o que alguém preferiria que tivesse acontecido.

Ser encadeado por impressões digitais significa que cada linha transporta uma impressão digital calculada sobre o seu próprio conteúdo juntamente com a impressão digital da linha anterior. As linhas formam uma cadeia. Altere-se uma linha e a sua impressão digital deixa de corresponder, e todas as impressões digitais seguintes deixam também de corresponder. A cadeia pode ser recalculada de uma ponta à outra e conferida.

Isto não torna a adulteração impossível. Alguém com acesso suficientemente profundo poderia reescrever a cadeia inteira a partir do ponto alterado. O que isto torna difícil é a adulteração silenciosa — uma única edição discreta que não deixa rasto — porque uma única edição não é uma forma possível para o estrago.

Do que entra no registo fazem parte todos os acessos a um código de vale, todas as visualizações de um documento de identidade, todas as aprovações, todas as libertações de fundos, os eventos de sessão e as decisões de conformidade. O registo faz parte do arquivo de cinco anos.

7. Quatro olhos sobre a liquidação

O operador que aprova uma ordem não pode ser o operador que liberta o respetivo dinheiro. Duas pessoas, duas contas, duas linhas de auditoria.

A razão é estreita e prática. Uma única conta de funcionário comprometida, ou uma única conta desonesta, não consegue mover dinheiro sozinha. Consegue levar uma ordem até à beira da liquidação, e aí para, diante de outra pessoa que tem de olhar para ela.

Ao lado desta há uma segunda regra: um processo de conformidade aberto congela a liquidação. Enquanto um processo estiver aberto, nada é libertado nessa ordem — nem pela pessoa que abriu o processo, nem por mais ninguém. Congelar é fácil; descongelar exige que o processo seja encerrado nos seus próprios termos.

Dinheiro que uma só pessoa consegue mover sozinha é dinheiro que um só erro consegue mover.

8. As sessões, e porque podem ser revogadas

Aqui, uma sessão é um registo no nosso servidor, não um bilhete autónomo transportado no seu navegador. O cookie no seu navegador contém um identificador aleatório que, por si só, nada significa; o significado está do nosso lado, associado a esse identificador.

Este desenho tem uma propriedade que importa mais do que qualquer outra: como o registo é nosso, podemos terminá-lo. Terminar sessão põe fim a uma sessão, em vez de pedir ao seu navegador que se esqueça de alguma coisa. Alterar a palavra-passe põe fim às outras sessões da sua conta. Quando um membro da equipa perde o acesso, as suas sessões terminam nesse momento, e não quando um token viesse a expirar. Um token autónomo não pode ser chamado de volta depois de emitido; mantém-se válido até o seu relógio se esgotar, que é o comportamento errado no dia em que precisa que ele desapareça.

O cookie de sessão é marcado de modo a que os scripts da página não o possam ler, a que só seja enviado através de uma ligação cifrada, e a que outros sites não possam levar o seu navegador a enviá-lo. As sessões terminam ao fim de um período de inatividade e terminam também num limite absoluto, independentemente da atividade. As sessões da equipa estão sujeitas a limites mais apertados do que as dos clientes, e o acesso de um funcionário a uma ordem termina quando a ordem termina.

9. O que lhe cabe a si proteger

Parte disto só funciona se cumprir a sua parte.

• Use uma palavra-passe que não use em mais lado nenhum. Uma palavra-passe reutilizada noutro sítio é apenas tão segura quanto o site mais frágil que a detém, e nenhum controlo do nosso lado consegue distinguir uma palavra-passe correta de uma palavra-passe roubada.
• Proteja a conta de correio eletrónico associada à sua conta aqui. É a via de recuperação, o que faz dela o caminho mais fácil para entrar. Ative o segundo fator que o seu fornecedor de correio eletrónico oferecer.
• Submeta um código uma só vez, no formulário de ordem, neste site. Nunca numa mensagem de correio eletrónico, numa conversa de chat, numa captura de ecrã ou numa chamada telefónica — nem sequer para nós.
• Olhe para a barra de endereço antes de escrever um código, e chegue ao site a partir do seu próprio marcador, e não a partir de uma hiperligação que alguém lhe enviou.
• Ninguém aqui lhe pedirá a palavra-passe. Ninguém aqui lhe pedirá que compre um vale e leia o código. Ninguém aqui lhe telefonará a pedir que transfira dinheiro para o pôr a salvo. Quem nunca pede vales vale a pena ser lido antes de precisar dele.
• Se achar que outra pessoa entrou na sua conta, escreva imediatamente para [email protected]. Se achar que foi vítima de fraude, escreva para [email protected].

10. Aquilo contra o que isto não protege

Um código que já lhe saiu das mãos. O código de um vale pode ser gasto por qualquer pessoa que o tenha lido. Se o deu a alguém antes de chegar aqui, a cifragem do nosso lado não o pode chamar de volta, e a verificação pode encontrar o valor já gasto. Já enviei o código de um vale explica o que ainda pode ser feito.

Um cliente que é enganado e submete ele próprio um código. Neste caso, todos os controlos acima descritos comportam-se corretamente, e é isso que o torna difícil. A pessoa certa tem a sessão iniciada, na sua própria conta, com o seu próprio documento, na posse de um vale que comprou ela mesma. A verificação confirma que o vale está bom. Não consegue confirmar porque está a vendê-lo. Os burlões conduzem as pessoas exatamente por este caminho — a administração fiscal que tem de ser paga hoje, o técnico de apoio que encontrou um vírus, a pessoa com quem fala há semanas e que tem uma emergência no estrangeiro. As nossas perguntas e as nossas verificações apanham uma parte disto. Não apanham tudo. Se um operador lhe perguntar porque está a vender, isso não é bisbilhotice, e uma resposta curta e honesta é o caminho mais rápido. Burlas com vales descreve os padrões.

O seu próprio equipamento. Software malicioso no seu computador ou telemóvel vê aquilo que vê, incluindo um código à medida que o escreve.

Uma imitação convincente deste site. Uma ligação cifrada diz-lhe que a ligação é privada. Não lhe diz quem está do outro lado.

Nós. Nenhum operador pode prometer honestamente que os seus sistemas nunca serão violados, e não vamos ser os primeiros a fazê-lo. O que podemos fazer é limitar até onde chega uma violação: códigos que existem pouco tempo, acesso reduzido a uma pessoa e registado, chaves guardadas à parte dos dados, um registo que resiste a edições discretas, e duas pessoas necessárias para libertar dinheiro.

11. O que não afirmamos

Não temos qualquer certificação de segurança, e nenhuma é reivindicada em parte alguma desta página. Não foi concluída nenhuma auditoria independente a estes sistemas. Não está a ser comunicado nenhum resultado de teste de intrusão. Nenhuma norma está a ser sugerida pela forma como isto está redigido. Se isso mudar, esta página indicará a certificação, a norma ou a empresa, e a data.

A atividade não está sujeita a licenciamento, e não é reivindicada qualquer autorização.

Esta página descreve o modo como o serviço está construído para funcionar. Não descreve um historial, porque ainda não existe nenhum. Nada aqui deve ser lido como uma afirmação sobre volumes tratados, fraudes evitadas ou clientes servidos.

Não servimos a França, as jurisdições sujeitas ao apelo à ação do FATF, as jurisdições sob sanções abrangentes, nem os mercados onde não detemos autorização local.

12. Dizer-nos que algo está mal

Se encontrou uma falha neste site, escreva para [email protected] com detalhe suficiente para a reproduzir. Não temos um programa pago de recompensas por falhas e não vamos fingir o contrário. O que faremos é ler o que nos enviar, agir em conformidade, e não lhe mandar um advogado por ter comunicado a falha de boa-fé.

Para suspeitas de fraude numa ordem, escreva para [email protected]. Para questões sobre o que conservamos a seu respeito e sobre o que nos pode pedir para fazer com isso, consulte a privacidade ou escreva para [email protected]. Para reclamar da forma como algo foi tratado, escreva para [email protected]. As perguntas gerais vão para [email protected].

A VoucherPay LLC opera a partir dos Estados Unidos, em 1801 Peninsula Verde Dr.