ASPECTO.Net – Notícias

A Juliana Barreto, da Info, divulgou que o Google ajuda a descobrir senhas de blogs, especificamente o Wordpress. Outros meios de comunicação também divulgaram, mas mencionei a Info por ser um canal de renome quanto as informações de tecnologia (embora o MeioBit já se tornou o canal mais poderoso e correto em minha opinião).

Tudo não passou de uma notícia divulgada apressadamente, sem uma apuração cuidadosa do fato. Levo em conta que uma jornalista que esteja trabalhando na Info conheça algo de tecnologia, ou pelo menos sabe onde procurar informações que dêem embasamento às suas informações e notícias. Tivemos, infelizmente, uma disseminação da insegurança àqueles que utilizam o wordpress.

O Élcio, preocupado com a falta de segurança noticiada, resolveu apurar e o resultado é muito diferente do divulgado. Convido-os a visitar o Blog Fecha Tag para ver o que ele escreveu (e também convido-os a acompanhar, pois há conteúdo de primeira qualidade). De qualquer forma, peço licença a ele para copiar aqui:

Para começar, leia o trecho a seguir desta notícia na INFO Online:

Mas, quando tentou o Google, o especialista descobriu que serviço de publicação de blogs Wordpress é vulnerável a pesquisas específicas. O site armazena dados como hashes MD5, que podem conter senhas, de uma maneira visível ao buscador. Bastaria informar um trecho do algoritmo para encontrar dados relacionados ao usuário e suas senhas.

Uau, belo trabalho jornalístico esse hein? Espalhando o medo. Imagine a reação de um leigo, que tenha um um blog Wordpress, ao ler essa pérola da desinformação. Não parece, lendo esse texto, que o Wordpress tem uma seríssima falha de segurança que pode ser explorada usando o Google? Que se alguém “informa um trecho do algoritmo” vai descobrir uma porção de dados seus? Bom, fui ao site do sujeito e li o artigo em que ele explica como quebrou a senha.

O que aconteceu é que o Wordpress do tal Murdoch foi invadido por um cracker, que criou uma conta de usuário. O Wordpress guarda suas senhas em um formato chamado MD5, um formato de criptografia que transforma qualquer senha num hexadecimal de 32 caracteres, assim:

• “Sylar” = 7bef5e9683a92c37a266283bf229c2e8
• “Cap. Nascimento” = 40a4b69d3132bd562dc03e2de30fda3e
• “Pat Morita” = 261f3880c4eab23075356dbc6b5befc3

O Wordpress faz isso para proteger você. Se alguém invadir seu blog, mesmo assim não vai descobrir sua senha. Então o Murdoch não tinha a senha do sujeito que invadiu o blog dele, tinha apenas o texto “20f1aeb7819d7858684c898d1e98c1bb”. O jeito comum de se descobrir essa senha é o chamado ataque de dicionário. Você consegue um enorme dicionário de palavras e nomes comuns, e faz um programa que converte cada um deles para MD5. Se, ao converter algum, você encontrar o tal texto “20f1…”, pronto, você descobriu qual é a senha.

O problema é que esses ataques levam tempo, pois o computador tem que processar milhões de palavras. E se a senha não for uma palavra comum do dicionário, ela não vai ser encontrada. Assim, “banana” vai ser encontrada, mas “Xbanana43″ não. Acontece que palavras muito, muito comuns, como “banana”, ou nomes de pessoas, provavelmente já tem seu hash MD5 publicados em alguma página na web. E, se está publicado, o Google encontra. Por exemplo, procure pelo MD5 de banana.

Então, ao procurar o MD5 da senha do invasor, o Murdoch achou páginas como essa aqui, uma lista de pessoas chamadas “Anthony”. Ele resolveu tentar então “Anthony” como senha, e funcionou.

Perceba que isso não torna o Wordpress mais vulnerável, porque a senha ia ser descoberta de qualquer maneira, só ia levar um pouco mais de tempo. E para fazer isso, o sujeito tem que ter acesso ao banco de dados com as senhas. Ou seja, já tem que ter invadido o sistema.

Foi só isso. Não há nenhuma vulnerabilidade no Wordpress que, se alguém vai ao Google e “informa um trecho do algoritmo”, vai descobrir seu CPF e número de cartão de crédito. Aliás, será que esse repórter sabe o que significa “algoritmo”? Aprendi quando era criança, quando minha mãe ouviu meu primeiro palavrão, que gente não devia usar palavras que a gente não sabe o que significa.

Você que usa Wordpress, não precisa se desesperar. Só não use senhas óbvias, não acredite em tudo o que você lê por aí e não entre em pânico.

Só lembrando: em Janeiro tem Oficina de Wordpress na Visie

(Publicado no meu Blog)

Uma dúvida comum no desenvolvimento com SQL Server é acerca dos campos String. Encontrei um excelente artigo falando sobre isso: Qual é a diferença entre o tipo de dados CHAR e o tipo de dados VARCHAR? E o NCHAR e o NVARCHAR?.

Primeiro vou explicar a diferença entre o CHAR e o VARCHAR:

* CHAR: Este tipo de dados sofre a ação da collation escolhida para o banco de dados em que foi criado (ou uma collation que pode ter sido especificada na criação da tabela) e armazena a mesma quantidade de caracteres que foram especificados na sua criação, preenchendo com espaços em branco casa haja necessidade. Por exemplo:

CREATE TABLE TB_STRING
(
CAMPO1 CHAR(10)
)

Se fizermos o seguinte INSERT:

INSERT TB_STRING('A')

O campo vai armazenar o valor ‘A’ e também vai armazenar mais nove espaços em branco depois. Por causa desta característica o tipo de dados CHAR é chamado de tipo de dados com tamanho fixo.

* VARCHAR: Este tipo de dados também sobre a ação da collation para o banco de dados em que foi criado (ou uma collation que pode ter sido especificada na criação da tabela) e armazena SOMENTE a quantidade de caracteres que foram especificados na sua criação . Por exemplo:

CREATE TABLE TB_STRING1
(
CAMPO1 VARCHAR(10)
)

Se fizermos o seguinte insert:

INSERT TB_STRING1('A')

O campo vai armazenar o valor ‘A’ SOMENTE, sem colocar espaços em branco depois. Por causa desta característica o tipo de dados VARCHAR é chamado de tipo de dados com tamanho variável.

Uma outra pergunta que sempre me fazem é: quando devo utilizar o CHAR ao invés do VARCHAR uma vez que o CHAR ocupa mais espaço ? A resposta é simples: o tipo CHAR deve ser utilizado quando sabemos de antemão que todos os dados inseridos em determinada coluna não são variáveis como, por exemplo, uma coluna que armazena um código de peça que sempre precisa ter 5 dígitos. Outro fator a ser considerado são as pesquisas feitas utilizando o operador =.

Já o VARCHAR deve ser utilizado quando não sabemos o que vamos armazenar. Um exemplo pode ser o nome do cliente ou razão social que sempre acaba variando.

Quanto ao desempenho é provável que os tipo de dados VARCHAR apresentem uma pequena diferença em relação ao tipo de dados CHAR, principalmente em operações que leiam muitos registros como a criação de índice. Porém esta diferença só é perceptível quando a quantidade de dados é grande e estamos fazendo uma medição correta.

Já os tipos de dados NCHAR e NVARCHAR são análogos aos tipos de dados CHAR e VARCHAR, respectivamente, porém com uma pequena diferença: os tipos de dados NCHAR e NVARCHAR não sofrem ação da collation e sempre gastam dois bytes para armazenar cada caractere.

Leia no artigo Protector – Segurança no seu XOOPS dicas de como aplicar medidas de segurança para o uso do XOOPS.