muitas aplicações sao vulneraveis a ataques de exaustao de recursos e ataques "ddos".
para isso precisa-se de, entre outras coisas, de um balanceador de carga bem configurado com maxconn, rajada, etc. monitoração e umas regras marotas de iptables/nginx/etc. eh divertido de brincar com isso quando vc tem tempo livre, pode ficar retornando erros aleatorios quando o cara ta forcando a barra. 2013/9/16 Solli Honorio <[email protected]> > > > Em 16 de setembro de 2013 00:53, Eduardo Verissimo > <[email protected]>escreveu: > > Depende, Solli. >> >> Eu penso em um caso típico: um site para quem quer ter casos fora do >> casamento. Ao colocar e-mail e senha, tudo o que esse site pode dizer é que >> a combinação e-mail/senha não existe no banco de dados. Afirmar que o >> e-mail existe seria sim uma falha de segurança, com implicações >> possivelmente terríveis para o usuário. >> >> > Sim, para algum aplicação sim. Então neste caso ela não deveria ter o > email como chave primaria do sistema dela. Você até pode argumentar em > fazer a validação do email em 2 etapas, mas isto vai depender muito da > aplicação e portanto não considero uma falha de segurança. > > >> >> Em 15 de setembro de 2013 23:15, Solli Honorio <[email protected]>escreveu: >> >> >>> >>> Em 15 de setembro de 2013 21:28, Leonardo Ruoso >>> <[email protected]>escreveu: >>> >>> Deve haver alguma aplicação onde o benefício de guardar o valor do md5 >>>> de uma string como BINARY/BYTEA em oposição ao próprio valor da string e >>>> deixar o índice BTREE fazer seu trabalho compensará → provavelmente é a >>>> mesma aplicação que vai notar benefício real em adotar largura fixa em >>>> detrimento de XML para intercâmbio de dados. Felizmente eu ainda não tive >>>> de colocar minhas mãos em nenhuma delas. Infelizmente eu já tive de lidar >>>> com CNAB e com chaves artificiais onde cabiam chaves naturais suficientes >>>> na minha vida… >>>> >>>> Acabamos de modelar aqui um sistema, em que algumas tabelas contém >>>> milhões de registros… >>>> >>>> Adivinha qual vai ser a chave das regiões brasileiras (hierarquia desde >>>> país até setor censitário passando por região, uf, meso, micro, municipio, >>>> distrito e subdistrito)? >>>> >>>> >>>> br.se.sp.regiao-metropolitana-de-sao-paulo.sao-paulo.sao-paulo.moema-indianapolis.moema.av-indianapolis-2000-2200 >>>> >>>> Servidor com 32 cores e 64GB de RAM? >>>> >>>> R$ 10 mil reais por ano >>>> >>>> Custo de manutenção de sistemas? >>>> >>>> Incalculável! >>>> >>>> Galera: >>>> >>>> Chave natural é tudo de bom! >>>> Chave composto é lindo e funciona! >>>> >>>> Não se esqueça que dizer para os usuários que um email já está >>>> cadastrado permite atacar sua base de usuários :) >>>> >>>> >>> Acho esta afirmação parcialmente verdadeira. Conhecer que existe um >>> email na tua base é inevitável quando vc a está utilizando como uma chave >>> para o sistema, e nem preciso ser um hacker para isto. >>> >>> Qualquer um pode saber quais são os emails que estão cadastrado no >>> Amazon.com e no Twitter, por exemplo, mas isto não é considerado uma falha >>> de segurança da Amazon. >>> >>> >>>> >>>> >>>> Em 15 de setembro de 2013 17:17, Lucas Mateus < >>>> [email protected]> escreveu: >>>> >>>> >>>>> É disso que to falando, usar o MD5 mesmo (binário) e não md5 >>>>> em hexadecimal, e acho sim muito comum emails com mais de 16 bytes. >>>>> >>>>> E se executar a query já passado o email com o md5, sem >>>>> precisar usar a função do BD é ainda melhor, ja que o BD faz o hex por >>>>> conta própria. >>>>> >>>>> >>>>> mysql> show create table users_2; >>>>> >>>>> +---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>>>> | Table | Create Table >>>>> >>>>> | >>>>> >>>>> +---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>>>> | users_2 | CREATE TABLE `users_2` ( >>>>> `email` varchar(60) default NULL, >>>>> `email_md5` binary(16) default NULL, >>>>> KEY `idx_email` (`email`), >>>>> KEY `idx_email_md5` (`email_md5`) >>>>> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 | >>>>> >>>>> +---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>>>> 1 row in set (0.00 sec) >>>>> >>>>> >>>>> mysql> select email from users_2 where email = '[email protected] >>>>> '; >>>>> +------------------------+ >>>>> | email | >>>>> +------------------------+ >>>>> | [email protected] | >>>>> +------------------------+ >>>>> 1 row in set (0.21 sec) >>>>> >>>>> mysql> select email from users_2 where email_md5 = unhex(md5(' >>>>> [email protected]')); >>>>> +------------------------+ >>>>> | email | >>>>> +------------------------+ >>>>> | [email protected] | >>>>> +------------------------+ >>>>> 1 row in set (0.00 sec) >>>>> >>>>> >>>>> Em 15/09/2013, às 16:44, Eden Cardim <[email protected]> escreveu: >>>>> >>>>> >>>>>> "Lucas" == Lucas Mateus <[email protected]> >>>>> writes: >>>>> > >>>>> > Lucas> Show Eden, mas seu teste não tem absolutamente nada a >>>>> > Lucas> ver com o que eu disse =) >>>>> > >>>>> > A única diferença do que você mostrou é que no meu caso, o campo >>>>> > email_md5 não existe porque não precisa, o índice resolve. E eu >>>>> > coloquei valores md5 no campo email pra ter alguma aleatoriedade no >>>>> > teste. >>>>> > >>>>> > -- >>>>> > Eden Cardim -- Insolide Soluções de TI Ltda. >>>>> > +55 11 9644 8225 >>>>> > http://insoli.de >>>>> > =begin disclaimer >>>>> > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> > SaoPaulo-pm mailing list: [email protected] >>>>> > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >>>>> > =end disclaimer >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: [email protected] >>>>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >>>>> =end disclaimer >>>>> >>>> >>>> >>>> >>>> -- >>>> Leonardo Ruoso >>>> Journalist, Perl developer and business consultant >>>> Media, UFC/2006; Telecom, IFCE/1998 >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: [email protected] >>>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >>>> =end disclaimer >>>> >>>> >>> >>> >>> -- >>> "o animal satisfeito dorme". - Guimarães Rosa >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: [email protected] >>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: [email protected] >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> =end disclaimer >> >> > > > -- > "o animal satisfeito dorme". - Guimarães Rosa > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > > -- Tiago B. Peczenyj Linux User #405772 http://about.me/peczenyj
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
