Sobre o tutorial

[Tarantula 0]

Python + MySQL, Tutorial

 

 

A maneira como você chamou o método "execute", passando um SQL e concatenando os parâmetros por texto, permite que sejam feitos inúmeros SQL injections, é importante avisar pra não usar essa forma de chamada em alguma aplicação web da vida.

[ScornInPC 1]

Ja que ja "descavaram" o tumulo xD

 

Assim, não é uma critica ok? =)

 

bem, eu gostava muito de python, até que eu me formei, e arrumei um emprego com PHP, dai naturalmente acabei largando mão de python.

 

Ao invés de o pessoal criticar e reaviver umas coisas antigas, por que não postam um outro tutorial "Melhorando a segurança", melhorando a performance, sei la, continuar o post sabe? não precisa ser em outro post, pode ser neste mesmo, mas continuando o tutorial, fazer disso um post referencia?

 

Bem, fica ai minha dica para as futuras criticas ok? e não levem pelo lado errado certo? =) valeu.

[Tarantula 0]

Então você acha que não se deve alertar as pessoas que forem ler o tutorial para não usarem um fonte com métodos vulneráveis na web ?

[ScornInPC 1]

Tarantula, pedi pra não levar isso pelo lado errado.

E não disse pra não alertar sobre isso, pedi para criar um artigo sobre isso, como não deixar seu código vulnerável.

[Tarantula 0]

Então por que usou a palavra "ao invés" ?

 

"Ao invés de o pessoal criticar" (...)

 

Eu não levei para o lado errado, fiz apenas uma crítica ao tutorial, pois realmente você usou um método que abre brechas para SQL Injections, acho que é dever alertar aos usuários quanto a isto; nem todo mundo tem tempo para fazer um tutorial inteiro explicando o porquê das coisas. Se eu tivesse feito um tutorial e alguém tivesse feito uma crítica fundamentada, eu teria ficado contente.

[ScornInPC 1]

Ok valeu ;)

[eibon 2]

Tarantula...Critica extremamente inoportuna.Em momento algum vi dados 'vindos dinamicamente' além do fato do tutorial ser introdutório e o foco do mesmo não ser esse.

---

Scorn...excelente tutorial,parabens!

Minha critica:

Hashs MD5 sempre tem 32 caracteres...troque a definição do campo senha de:

senha varchar(32)

Para:

senha char(32)

Também recomendo usarem 'algoritmos de HASH' mais novos.

[ScornInPC 1]

Muito legal elbon, eu na verdade na época não sabia a difereça entre car e varchar, mas sim, muito boa, agora sobre hashs mais novos, poderia dar uma dica de algum ai? eu ainda uso MD5, e até conheço um site que quebra =/

[eibon 2]

Vai depender do que você quer.

Se é relativa segurança e menor processamento,x.

Se é segurança e maior processamento y.

Leia sobre e conheça alguns hashs em: http://en.wikipedia.org/wiki/Cryptographic_hash_function.

 

Ps: eu particularmente acho sha256 até que uma boa.

Ps²: quando disse mais novos...quis dizer de certa forma 'melhores'/mais 'potentes' (espero que novamente não me interpretem mal).

 

Edit: vi agora...hashs MD5 não podem ser quebradas...o mecanismo desse site faz é outra coisa.

[Tarantula 0]

Eibon, como já falei nos 2 posts anteriores, ele está usando uma forma que não é recomendada para passar parâmetros ao SQL, ele está utilizando concatenação de string, se alguém for usar algo como:

"SELECT * FROM TABLE WHERE FIELD=" + parametro, ele terá sérias vulnerabilidades; mas como você acha isso inoportuno, deixemos as pessoas criarem cada vez mais acessos aos DBs utilizando formas que permitem sérias vulnerabilidades.

 

E apenas corrigindo o que você falou sobre o MD5, ele não tem sempre 32 caracteres, esta é a representação hexadecimal dele, ele na verdade tem 16 caracteres, ou 128 bits, uma forma mais eficiente de armazenar o MD5 em banco é utilizando o "digest" ao invés do "hexdigest", veja no código abaixo a diferença de tamanho:

 

>>> len(a.digest())
16
>>> len(a.hexdigest())
32

Em relação a quebra do MD5, existe uma vulnerabilidade em que se pode gerar colisões, toda função hash tem colisões, não existe um hash perfeito, a questão é que no MD5 pode-se gerar uma colisão de maneira fácil. Existem hoje formas pra tentar gerar essas colisões e tentar descobrir qual a string (geralmente menor que 10 caracteres) que este hash representa, a forma mais usada é utilizando rainbow tables, que funcionam como dicionários e geralmente são tabelas de mais de 1GB dependendo do tamanho da string que você quer quebrar.

 

Outro aspecto em relação ao código do ScornInPC, é que ele usa;

 

md5.update("123456")
dbCursor.execute("insert into usuarios (nome, senha) values ('usuario1', '" + md5.hexdigest() + "')")
md5.update("abcdef")
dbCursor.execute("insert into usuarios (nome, senha) values ('usuario2', '" + md5.hexdigest() + "')")
md5.update("123abc")
dbCursor.execute("insert into usuarios (nome, senha) values ('usuario3', '" + md5.hexdigest() + "')")

Este trecho do fonte gerará o hash correto apenas da senha "123456", mas das outras senhas ele não vai gerar o hash correto, isso se dá pelo fato de que o objeto "md5" funciona como um acumulador, se você vai dando "update" nele, ele vai acumulando para gerar um hash de um texto maior, no caso, a chamada para "md5.update("abcdef")", gerará o hash da string "123456abcdef", ao invés da string "abcdef", o correto seria chamar algo como isto para cada senha, criando um acumulador novo a cada vez:

 

digest = md5.new("123456").digest()

[eibon 2]

Eibon, como já falei nos 2 posts anteriores, ele está usando uma forma que não é recomendada para passar parâmetros ao SQL, ele está utilizando concatenação de string, se alguém for usar algo como:

"SELECT * FROM TABLE WHERE FIELD=" + parametro, ele terá sérias vulnerabilidades; mas como você acha isso inoportuno, deixemos as pessoas criarem cada vez mais acessos aos DBs utilizando formas que permitem sérias vulnerabilidades.

Como já falei no POST acima...o tutorial é introdutório e não tem foco na segurança.Ele quis ensinar você a interagir com uma base de dados MYSQL,e o tutorial cumpriu bem seu papel.

 

E apenas corrigindo o que você falou sobre o MD5, ele não tem sempre 32 caracteres, esta é a representação hexadecimal dele, ele na verdade tem 16 caracteres, ou 128 bits, uma forma mais eficiente de armazenar o MD5 em banco é utilizando o "digest" ao invés do "hexdigest", veja no código abaixo a diferença de tamanho:

Enganou-se.Veja(esquema tosco [se quiser explico novamente e melhor]):

ocp h = 4bits

2*(ocp h) = 8bits = 1byte

ocp c = 8bits = 1byte

 

#h: Valor Hexadecimal

#c: Caracter

#ocp: Espaço ocupado na memória

#8bits = 1byte

#exemplos:

#dec->0|hex->00;dec->255;hex->FF; 0-9 - A-F [0 a 16(hexa)]

#-Valor Hexadecimal: F[4bits] + F[4bits] = FF[1byte]

#-Representação em String: 'F'[1byte] + 'F'[1byte] = 'FF'[2bytes]

Um caracter representando um valor hexadecimal vai ocupar o dobro de memória que o mesmo.A len no caso seria a quantidade de bytes que aquela string ocupa...chegamos a conclusão então...

E diga-me um tipo do seu banco de dados que grave um valor em HEX e não sua representação em outro tipo.

 

Em relação a quebra do MD5, existe uma vulnerabilidade em que se pode gerar colisões, toda função hash tem colisões, não existe um hash perfeito, a questão é que no MD5 pode-se gerar uma colisão de maneira fácil. Existem hoje formas pra tentar gerar essas colisões e tentar descobrir qual a string (geralmente menor que 10 caracteres) que este hash representa, a forma mais usada é utilizando rainbow tables, que funcionam como dicionários e geralmente são tabelas de mais de 1GB dependendo do tamanho da string que você quer quebrar.

Colisões e comparações de HASHS já prédefinidas se diferem bastante de 'quebras'(se quiser eu explico =]).

 

gerará o hash da string "123456abcdef", ao invés da string "abcdef", o correto seria chamar algo como isto para cada senha, criando um acumulador novo a cada vez:

Incorreto?Quem disse que esse não era o objetivo dele?

[ScornInPC 1]

Poxa, desculpe a sinceridade, mas um tópico que ja teve 3.767 visitas, deveria tomar continuidade no ideal do mesmo, "SER INTRODUTÓRIOOOOO".

Tenho certeza que este tópico ja ajudou muita gente no pontapé inicial. Ao invez de ficarmos sujando o post, poderiamos continuar a melhora-lo, não =)

 

Se você digitar python mysql no google, quase cai direto neste post, vamos usar isso à nosso favor, o que acham? =)

[Tarantula 0]

Certo então, segundo o Eibon, um material introdutório não precisa ser seguro: "Como já falei no POST acima...o tutorial é introdutório e não tem foco na segurança."

 

E também, segundo ele, um hash MD5 tem SEMPRE 32 caracteres: "Hashs MD5 sempre tem 32 caracteres", apesar dele ter 128 bits, vai ver os caracteres dele tem 8 bytes cada.

 

Ahh ! E e o ScornInPC estava gerando as seguintes senhas:

 

123456

123456abcdef

123456abcdef123abc

 

Só para ficar claro aqui pra quem visite então =)

[eibon 2]

Se ele não inseriu nenhum dado dinamicamente...como pode ser inseguro?

E se você entende o sistema hexadecimal...sabe que minha explicação está correta e você está doido pra aparecer.

md5.digest() te retorna o valor hexadecimal da hash gerada.

md5.hexdigest() o valor hexadecimal da hash gerada representado como string.

É tão dificil assim de entender?

 

Ps: se não leu minha explicação...leia.

[ScornInPC 1]

elbon, muito legal da sua parte passar o código para python 3, show de bola, ao menos seu tempo de post foi pra ajudar, e que ajuda hem =)

 

Valeu por melhorar (ou atualizar neh auehauhe) meu post, só a acrescentar, acredito que vá ajudar mais ainda ;0

 

 

Valeu =)

[~TiuTalk~ 7]

11º mandamento: Todo MD5 terá 32 caracteres.

12º mandamento: Todo SHA1 terá 40 caracteres.

 

Não há o que discutir... Está nas tabulas sagradas da programação.

[Tarantula 0]

Eibon, você me paga quanto se eu criar um hash MD5 de uma string, gravar em um arquivo em 16 caracteres (que você podera comprovar) e depois ler esse arquivo com 16 caracteres novamente para checar se é o mesmo hash da string ?

Não adianta ficar teimando cara, vamos ver isso na prática, o que tu acha ?

[eibon 2]

Cara...desde quando dois valores hexadecimais são um caracter?

Tá falando sem saber...e ainda acha que tá certo.

 

Edit: trecho do site onde ele me mostrou o tipo BINARY do MySql para guardar tais valores em hex:

Yes. Often a hash digest is stored as the ASCII representation of hex digits, for example MD5 of the word 'hash' is:

Pelo amor de deus...se você acha que ainda ta certo depois de uma dessas...tá dificil viu.

[Mário Monteiro 179]

os últimos posts foram excluídos/editados por fugirem do foco do tópico

[Tarantula 0]

Eibon, não dá pra conversar se você apaga os posts né cara ? Bom, como você disse, que todos bons programadores para quem mandou o tópico falaram que concordam contigo, então talvez devesse ler o site abaixo, que armazena em 16 bytes o que você recomentou para armazenar em 32 bytes, já que são 32 caracteres haha (espero que não apague este post também):

 

http://stackoverflow.com/questions/504268/...ry-for-hash-ids

 

Often a hash digest is stored as the ASCII representation of hex digits, for example MD5 of the word 'hash' is:

 

0800fc577294c34e0b28ad2839435945

 

This is a 32-character ASCII string.

 

But MD5 really produces a 128-bit binary hash value. This should require only 16 bytes to be stored as binary values instead of hex digits. So you can gain some space efficiency by using binary strings.

 

CREATE TABLE test.foobar (

id BINARY(16) NOT NULL PRIMARY KEY

);

 

INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));