Posts Tagged ‘ criptografia

Hackeando RFID, se incomodando com a American Express

RFID (Radio-frequency Identification, ou Identificação por Rádio-Freqüência) é uma dessas tecnologias que tem um grande hype em volta, como o bluetooth ou a biometria, mas que é, também como esses, amplamente furada em termos de segurança.

Além dos problemas óbvios de privacidade, de se ter um cartão dentro do bolso transmitindo o teu nome e possivelmente o número do teu cartão de crédito para quem quiser ler, a criptografia normalmente empregada é nada mais do que precária. Há pouco tempo o Reino Unido resolveu implantar RFID nos seus passaportes. Em menos de 48 horas a criptografia foi quebrada e passaportes falsos foram feitos.

Este vídeo do BoingBoingTV explica muito bem a situação:

Estes cartões, por sinal, estão sendo distribuídos no Brasil, com a mesma (falta de) criptografia.

Obviamente, qualquer um que pretenda usar um cartão de crédito vai se manter bem longe da American Express. Mas a Visa e outras companhias já têm suas versões também.

Um leitor de RFID pode ser encontrado no ebay por 8 dólares, mais o frete para o Brasil, no máximo 25 dólares. E nem passa da cota, muito provavelmente nem imposto será cobrado. Então qualquer jaguara com 40 pila e um notebook pode roubar um cartão desses.

Como o tio ali no vídeo disse, as empresas não estão preocupadas em criar um sistema seguro, mas sim um sistema que pareça seguro para o consumidor. É importante estar alerta disso ao aderir a uma nova tecnologia.

Todas essas empresas estão cientes dos riscos da tecnologia, mas preferem esconder tudo.

Adam Savage, dos Mythbusters falou sobre isso na HOPE, uma conferência Hacker há pouco tempo:

[youtube]http://www.youtube.com/watch?v=-St_ltH90Oc[/youtube]

[Link para quem lê o feed]

RFID não é de um todo mau. A tecnologia é excelente para marcar gado, por exemplo. Mas eu não usaria nem mesmo para comanda de restaurante. Onde há seres humanos, há risco de segurança.

A Importância do Backup

Eu era um cara negligente com backups, como a grande maioria. Confiava cegamente nos meus HDs, e mais ainda na minha falta de capacidade de estragar tudo. Até a terceira ou quarta vez que eu perdi dados por falha de hardware ou puta bocabertice mesmo. Aí eu comecei a levar a sério esse negócio de becápi.

Hoje, por exemplo, eu fui fazer a atualização de um maravilhoso plugin que eu uso, o XHTML Video Embed, que gera código XHMTL strict para vídeos do youtube, bastando usar tags e o endereço do clipe. Eu dependo um monte desse plugin, todos os posts com vídeos daqui estão com ele. O problema é que, por algum motivo, a versão nova que saiu hoje não funciona. Dá caca total, nem ativa o plugin. E agora, José? Simples: restaurar o backup. Dois minutinhos depois eu estava com a versão velha (e estável) do plugin rodando.

Agora você me diz que fazer backup é chato, tedioso, para pessoas com muito tempo livre. E eu digo que sim, pode até ser, mas como eu sou um cara legal, vou te ensinar a automatizar isso tudo.

Vamos começar do começo, e vamos por partes, como diria Jack.

Você vai precisar, indispensavelmente, de um servidor com suporte a cronjobs. Se o seu servidor não suporta, corra e assine outro, porque é um servidor muito furreco esse que você tem. Eu recomendo o Dreamhost.

A seguir, você precisa criar uma pasta para armazenar os backups no seu servidor. Por favor, faça um serviço de gente normal, e deixe essa pasta fora da webroot, que é aquela pasta acessível pelo navegador, senão qualquer jaguara pode acabar por descobrir onde está teus backups e te pegar a DB, dados confidenciais, etc, etc.

Dentro desta pasta você precisa de pelo menos três outras pastas: uma para os backups diários, outra para os semanais, e outra para os mensais. Já deu para ver aqui que você fará 3 scripts, certo? Vamos detalhá-los.

O primeiro script toma conta dos backups diários e de remover os que já têm mais de uma semana. O seguinte código deve ser salvo num arquivo de texto, e você deve dar permissão de execução (vulgo chmod +x) nele. No cron, que provavelmente fica no painel do seu servidor, adicione este script para ser rodado diariamente. O código é esse:

#!/bin/bash
suffix=$(date +%y%m%d)
nice -19 tar -czf caminho_do_backup_diário/backup-$suffix.tar.gz pasta_a_ser_salva
mysqldump –opt -uuser_do_mysql -psenha_do_mysql -h host_do_mysql database | gzip -c > caminho_do_backup_diário/database-$suffix.sql.gz
find caminho_do_backup_diário -type f -mtime +7 | xargs rm

Substitua o que está marcado pelo que deve ser substituído.

Explicando: a primeira linha somente informa o sistema de que isto se trata de um shell script. A segunda linha gera um sufixo baseado na data, de modo a que cada arquivo seja gerado com um nome diferente. A terceira linha compacta com o tar.gz a pasta que você quiser. Ela pode ser repetida para compactar em arquivos separados pastas separada, só trocar o nome do arquivo (no caso, backup-*). A terceira linha fará um dump da DB e a compactará. Finalmente, a última linha procura por arquivos com mais de uma semana e os exclui.

Para o backup semanal, o script é o mesmo, somente trocando o caminho_do_backup_diário pelo caminho_do_backup_semanal. Além disso, a última linha deve ser:

find caminho_do_backup_semanal -type f -mtime +30 | xargs rm

De modo a deletar todos os arquivos com mais de um mês. Este script deve ser posto no cron para rodar semanalmente.

Finalmente, o script do backup mensal também deve ser igual aos anteriores, mas removendo a última linha, ou substituindo o -mtime +x pelo valor em dias a guardar o backup. Eu prefiro guardar para sempre, já que eles não são muito grandes, mas 365 deve ser um bom valor para isso. Lembre-se também de alterar o caminho do backup para a pasta de backups mensais, para que um script não interfira no outro. Novamente, mande o cron rodar este script mensalmente.

Agora você deve estar com um bom sistema de backup criado. Você terá sempre um backup de cada um dos últimos 7 dias, um de cada semana do último mês, e um de cada mês, podendo assim reverter para o que for mais conveniente. Vale lembrar que, se der uma zica geral no teu servidor, isso não vai te salvar. Em tese, a empresa de hospedagem deve se responsabilizar pelos dados, mas, se não der… Bem, ferrou. Isso deve aumentar as tuas chances, mas vale a pena baixar estes backups de vez em quando também para o PC.

Outra possibilidade seria enviar estes backups para o email, usando o comando mail. Mas isto não é exatamente seguro, então pode-se criptografar estes backups com o pgp. Mas isso é só para os extremamente paranóicos.

Estou indo implementar isso agora.

HSBC parou no tempo

Está se tornando comum ver notícias de empresas que perderam dados de clientes, normalmente porque não têm nenhuma noção de segurança digital, e muitas vezes, nem de segurança física. Largam notebooks por aí, têm máquinas com firewalls precários, deixam discos de backup atirados… O resultado é como o meu armário: tende ao caos.

A mais nova empresa a perder dados relativamente importantes de clientes, como nome, data de nascimento e detalhes de seguros foi o HSCB, na Inglaterra. O detalhe é que os dados estavam em um disquete. É, isso mesmo. Essas coisas quadradas que os mais velhos devem ter nas gavetas, e tem gente que jura que chegou a usar um uma vez.

Disquetão

Creative Commons License photo credit: kalleboo

O outro problema é que eles estavam enviando o disquete. Partindo do princípio que eram dados importantes, e que eram no máximo um mega e quebrados de dados, custava mandar por email? É pra isso que existe criptografia, pombas!

Não sei porque ainda me surpreendo.

[Fonte: ZeroHora]

 
SEO Powered by Platinum SEO from Techblissonline