Almeida Camargo Advogados
Faça do Almeida Camargo a sua home page  

Menu
Home
Institucional
Estudos Jurídicos
Código do Consumidor
Cooperativismo e Terceiro Setor
Ciber Crimes
Direito da Sociedade da Informação
Econômico e Concorrêncial
Energia Usina Antiga do Itapeva
Eventos
Informática e os Tribunais
Inf. e Melhoria do Poder Judiciário
Nota Fiscal Eletrônica
Notícias
OAB
Opinião e Notícia
Pareceres
Second Life
SPED-Sist. Público de Escrit. Digital
Tributário
Links Úteis
Fale Conosco

Empresas
Centro de Estudos Jurídicos

Bd4u

Veja Introdução

Enquete
 
Você acredita que a adoção de maiores controles do Fisco através da NF-e poderia evitar situações de sonegação Fiscal?
Dê sua opinião ou envie mensagem:
suaopiniao@almeidacamargo.com.br
  Sim
  Não
 

Login
  Login: 
  Senha:    
Previsão do tempo para região Sudeste
 
::. Cyber Crimes .::
Versão para impressão Imprimir  -   Enviar por e-mail Enviar  -  Altera o tamanho da letra A- A+
Critpoanalise e WPF.

Sobre o que mais eu falaria neste blog não é?

Windows Presentation Foundation:

Se você tem acompanhado meu blog, observado as minhas experiências e palestras, você sabe o que é WPF e do que ele é capaz. O que provavelmente você não sabe, a não ser que tenha tentado alguma coisa mais pesada é o feeling real de desenvolver em WPF: Atualmente é quase impraticável (exceto em projetos exclusivamente multimídia) usa-lo comercialmente.
Sim, ele é maravilhoso, possui milhares de efeitos, estilos e tudo mais porém falta produtividade. Sim, produtividade. Como ele não possui componentes programáveis (como Grids, validadores, controle de abas e etc), você precisa cria-los todos na mão. Analisando a Web já encontrei algumas empresas que desenvolveram controles do tipo para suas aplicações WPF. Estes dois fatos me fazem ter a seguinte leitura:
Como o framework 3.0 já foi lançado e a Extensão de VStudio ainda está em CTP (e os Expression em Beta 2), as API's e fundamentos do WPF já estão prontos, porém a maneira de se desenvolver ainda não. O que faltaria? Justamente a questão dos controles para auxiliar o seu desenvolvimento.
É muito fácil impressionar o mundo com WPF mostrando seus efeitos e cambalhotas, mas vamos manter em observação a questão da produtividade para o desenvolvimento de software comercial...

Em paralelo as questões do WPF, que tenho meditado muito mais do que estudado, vale a pena dar uma conferida no Flex que é o concorrente de mercado. Ainda não usei, mas estaria o Flex mais maduro (provável que sim, pois já está no mercado há alguns anos)? O fato do Flex se consolidar através de outras tecnologias (Flash) já espalhadas pelo mercado é um fator importante para o sucesso?

Gostamos de Microsoft, mas vamos manter os olhos abertos para o que acontece nessa revolução digital da UX (User eXperience).

 



Criptoanálise

Após receber o feedback dos leitores do blog, levantei as questões mais levantadas a respeito de criptografia. Com o objetivo de retirar as dúvidas escreverei alguns posts

Criptografias e Senhas: Eu definiria Criptografia como o processo de tornar um texto legível em um texto ilegível para quem não tenha o conhecimento de um segredo em especial, que tornará o texto confuso em texto claro novamente. Baseado neste pensamento podemos pensar: Quando você cria um programa você precisa de saber a senha do seu usuário? Ou você precisa apenas comparar se a senha que ele informou quando tentou acessar o sistema é a mesma senha que foi cadastrada quando ele criou o usuário? O processo de Hash pode ser definido levianamente como uma "criptografia sem volta", ou seja, é o processo de embaralhar o texto original de uma maneira que não seja possível, nem através de um segredo, a compreensão do mesmo. Isto é possível porque assim como a Criptografia, o processo de Hash são iterações matemáticas feitas sobre um conjunto de bits. Ora, se é um processo matemático, eu tenho como reverter o processo e possuir o texto original? Sim. Mas para isso primeiro você precisaria de descobrir qual foi o sal usado (se um foi usado) no processo Hash para ter acesso as incógnitas da equação. Após isso, seria necessário efetuar as mesmas operações matemáticas feitas para o processo de Hash na ordem inversa. O problema disso é que como a matemática é um meio de via única o tempo para calcular a equação de um algoritmo de Hash é muito menor do que o tempo para calcula-la em ordem contrária. Sendo assim, o grande desafio do Hash é não só tornar o texto completamente ilegível, sem padrão de reconhecimento e todas as outras questões da Criptografia convencional, mas usar operações matemáticas que tornem o tempo necessário para realizar a operação inversa impossível de acontecer. Como pudemos ver  neste post , existem muitas variações matemáticas impossíveis de se calcular em tempo hábil até mesmo computacionalmente. Dado estes fatores, a maneira mais segura de se guardar uma senha é quando não é possível recupera-la nem mesmo sabendo-se o sal do Hash. A pergunta que provável paira sobre sua cabeça neste momento é "se eu não sei qual a senha do usuário, como vou saber se ele digitou a senha correta?". O passo-a-passo é o seguinte:

Armazenar a Senha:

1 - Usuário insere sua senha.
2 - Software gera um sal. O "Sal" ou "salt" nada mais é do que um texto aleatório. Para isso pode ser usado um PRNG (Algoritmo de Geração de Números Pseudo-Randômicos).
3 - Transforma-se o texto original em bytes para misturar com os bytes do Sal.
4 - Software usa um algoritmo de Hash sobre o array de bytes (texto + sal) e grava as informações no banco.

Validação de Usuário e Senha:

1 - Usuário insere sua senha.
2 - Novamente devemos gerar o nosso Sal com um PRNG. É importante que o salt gerado neste momento seja exatamente o mesmo usado na outra vez (Como os PRNGS necessitam de uma semente, isso não se torna problema).
3 - Tranformar-se o texto informado em bytes para misturar com os bytes do sal.
3 - Software compara o texto resultante da operação de Hash sobre o texto informado como senha, com o texto Hasheado gravado no banco de dados. Caso os dois textos sejam iguais, a senha digitada foi a mesma senha informada anteriormente.


Claro que mesmo sendo impossível realizar a operação contrária, ataques de força bruta ainda são possíveis de se realizar se o invasor possuir o sal. Bastará que ele tente todas as combinações possíveis de texto do tamanho que a sua senha poderá variar (por exemplo, é comum as senhas possuírem entre 6 e 8 dígitos) e compare todos os resultados do Hash com o resultado Hasheado da senha original até que o valor venha a conferir. Portanto mesmo em Hash, é importante guardar a chave e o sal.
O grande complicado do ataque de força bruta em um texto que passou por um Hash é que se alterarmos apenas uma letra do texto original, o resultado será completamente diferente. Então em nenhuma hipótese conseguimos saber se estamos próximos ou longe de quebrarmos o Hash por força bruta..

Código de Hash (sem sal) em .net:

            Byte[] byteArray_dados = new UnicodeEncoding().GetBytes(dados);
            MD5 md5 = new MD5CryptoServiceProvider();
            byte[] dados_Hasheados = md5.ComputeHash(byteArray_dados);
            return BitConverter.ToString(dados_Hasheados);


A outra pergunta que fica é: Se o Hash é virtualmente impossível de ser recuperado, porque não usamos somente Hash em nossas aplicações? Pelo simples fato de que existem informações que nós precisaremos recuperar, como emails, logins e etc. Nestes casos, só a Criptografia nos ajudará...

Data: 21/05/2007

Fonte: jackflashspot


Inéditas


  Veja mais notícias

Estudos e Pesquisas

  Veja mais notícias
"O essencial não é fazer muita coisa no menor prazo;
é fazer muita coisa aprazível ou útil."
Machado de Assis 
Copyright Fox Informática                                                       Home | Institucional | Fale Conosco | Profissionais | Artigos | China | Links