| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Porém, desde o dia do lançamento do MBNet que a Phibenet, um grupo que agrega pessoas de várias áreas, Ahem... :)
"Prepare to be seduced by my Psycho-Power!"
- M. Bison, Street Fighter Alpha 3 |
| | | | | Quanto a mim as únicas falhas de segurança ser ão: (assumindo que embora não sejam versões recentes o apache e modssl foram patchados) - nome do utilizador dedusível do nome verdadeiro. E não venha a SIBS dizer que não é problema de segurança pois ela própria diz que é, quando diz, no talão de adesão ao mbnet:
"Evite utilizacoes abusivas memorizando a identificacao mbnet e o codigo secreto
por razoes de seguranca destrua o talao. Ora, duvido que não considerassem o username relevante se nos dizem para memorizá-lo e destruir um talão que *apenas* contém esse username. - Erro diferente informando se o username existe ou se é a password que está errada. Entretanto corrigiram o problema, o que indica que também o consideravam como problema de segurança.
Uma, err..., feature que me deixa divido é a de ser possível fazer DoS aos utilizadores. Como dizem na entrevista, a conta é suspensas se o utilizador errar muitas vezes a password (não sei quantas, claro). Isto é chato ao utilizador, pois só quando vai precisar de usar o mbnet é que vai descobrir que foi suspenso. Mas aumenta um pouco a segurança pois impede um brute force à conta. Mas, visto que a maioria dos utilizadores voltará a escolher o mesmo código (códigos de 4 dígitos são quase impossíveis de memorizar, imagine-se então códigos de 6 dígitos...), sendo então apenas uma questão de tempo e paciência... De resto, não teve piada mudarem o CA agora que a tinha instalada.... Chatos... E também, não posso opinar sobre o serviço àparte a segurança, pois ainda não tive o... err... tempo... para o experimentar, mas parece muito interessante, ainda mais que assim não necessito de arranjar um Visa/Mastercard/etc normal (os bancos são chatos)...
hugs
Strange |
| | | | | | | Não não e não. A grande falha de segurança é o certificado foleiro. E ninguém fala dela! Passo a explicar: O certificado do site é assinado digitalmente pela Multicert. Isto deveria validar o certificado, mas infelizmente, o certificado da Multicert não está assinado por ninguém. Peguem no mozilla, vão ao site e vejam o certificado na página de informação sobre segurança do site. Assim, nada me impede de gerar um certificado qualquer que diga que é da Multicert, usar esse para assinar um certificado para o site, e criar o mvnet.pt e esperar que algum incauto me presenteie com o código. Ou, pior ainda, cracar um servidor DNS de um qualquer ISP, e desviar o tráfego. Nada me garante a identidade de quem está do outro lado! Ainda por cima, os browsers só verificam um nível da árvore de confiança dos certificados. Isto obriga a que o emissor do certificado do site seja já conhecido pelo browser. Teria que ser a Verisign, a thawte, ou um dos outros que já estão incluídos com os browsers...
--
If at first you don't succeed, skydiving is not for you |
| | | | Esta pérola seria divertida se não fosse deprimente: (...)o Certificado, por exemplo, é emitido por uma entidade que não é reconhecida pelo browser e como tal automaticamente o browser alerta o utilizador. Não é um aspecto de segurança, é um warning que o browser faz a quem emitiu. Podemos ver isto de duas maneiras : como favorável ou desfavorável.(...) Manuel Lopes da Cunha Para quem não tenha a noção de quanto isto é deprimente, este homem é director do departamento de sistemas de pagamento. Decide tudo sobre os sistemas informáticos que lidam com o meu dinheiro. E não tem noção do que é uma árvore de confiança de certificados digitais!!! Incompetência nestes lugares paga-se caro, e o Sr Manuel Lopes da Cunha devia ser sumariamente demitido. Em palavras muitos simples: É possível duplicar o site da SIBS, exactamente igual, exactamente com os mesmos warnings, exactamente com o mesmo aspecto. Só que em vez de fazer pagamentos, rouba dinheiro... Eu não consigo ver isto favoravelmente, por muito que me esforce.
--
If at first you don't succeed, skydiving is not for you |
| | | por Anonimo Cobarde em 02-10-01 22:57 GMT (#11)
|
| Quer dizer portanto que preferes confiar na escolha de certificados que veem no teu browser do que na escolha de certificados em que tiveste uma parte activa na sua colocacao no teu keyring privado.
Rrrrrriiiight....
|
| | | | Ok, a diferença e esta: 1. todos os certificados que tens no browser podes tira los. Obvio. Mas se eles estao la e pq sao empresas ideoneas e que tem provas dadas no campo do PKI. 2. Tu podes expressar confiança em qualquer certificado. Verdadeiro tb. 3. O que esta em causa nao e isso... Mas sim toda a hierarquia e funcionamento da confiança. 4. Eu posso criar um certificado a dizer Pagamento Seguro, criar uma pagina inventar uma treta, dizer que sou a empresa "Securitas Internet" e que sou de confiança...MAS! posso nao ser... 5. E isso que esta em causa... pq segundo o teu raciocinio, todos nos entao tinhamos CA´s em casa e davamos (pq nao?) certificados... Achas que o disses faz sentido? SE a resposta for sim, entao faz o seguinte, rasga o teu Passaporte e faz um casa... E depois tenta usa-lo...
New Wave "May The Peace Be Green" |
| | | | | É incrível, e tu e mais essas tantas pessoas que andam por aí a dizer mal não percebem que não se consegue reproduzir um certificado igual. Fingerprint, já ouviste falar? Podes por um site igualzinho a correr, hackando o DNS. Mas não consegues por um certificado igual. E qdo o browser for a esse site, vai-te dizer que o certificado mudou. Percebeste agora? E não é dificil publicitar a fingerprint do certificado, por exemplo numa carta enviada ao cliente. Por favor, parem de dizer mal do que não sabem. Fica-vos mal e não faz sentido.
|
| | | | E tu achas que o comum utilizador sabe isso do fingerprint?! Alias nao existe nenhuma verificaçao a nivel de Finger print(se nao estou em erro, se estiver corrigam-me) de acesso a um site por exemplo o MBnet. Ou seja para o utilizador desde que tenha o mesmo nome, entao e seguro, ele nao se preocupa com o Fingerprint, ate pq nao sabe o que e isso. Por isso os Certificados Tem uma cadeia de confiança...
New Wave "May The Peace Be Green" |
| | | | | Bom, então voltamos outra vez há questão que já tinha dito há uns tempos - isto não é uma questão de segurança. Tu admites então que o site é seguro para o utilizador mais técnico. O site não é seguro para parolos? Tou 100% de acordo. O problema claro está, é fazer com que o utilizador comum aprenda algo de criptografia. E isso é, a meu ver, inevitável para que se consiga implementar uma solução segura para todos. E isto não só ao nível de SSL como de PGP, por exemplo. Quanto à verificação por fingerprint, é possível, basta examinares o certificado no teu browser e procuras lá pelo thumbprint ou fingerprint. A ser bem feito, deviam-te mandar para casa o fingerprint do Multicert root CA, tu ias à página do MBnet, vias o certificado, ias ao certification path, confirmavas o fingerprint da Multicert e a partir daí já podias instalar o certificado do MBnet. O problema agora é que o MBnet mudou de certificado, pois passou a usar o Multicert (com uma chave de 2048 bits) em vez do PILOTO Multicert (com uma chave de 1024 bits), e esse novo certificado ainda não se encontra na página da multicert.
|
| | | | "Quanto à verificação por fingerprint, é possível, basta examinares o certificado no teu browser e procuras lá pelo thumbprint ou fingerprint. A ser bem feito, deviam-te mandar para casa o fingerprint do Multicert root CA, tu ias à página do MBnet, vias o certificado, ias ao certification path, confirmavas o fingerprint da Multicert e a partir daí já podias instalar o certificado do MBnet" Para um sistema que se quer "Straigth Forward", começa a ficar complexo dessa maneira nao achas? Eu sei que se pode ver as propriedads do certificado, em que esta o fingerprint. No entanto tenho tb a certeza que a maioria dos utilizadores comuns nao sabem tao pouco ir a opçoes de segurança do IE. (Broweser mais comum) Quando falava de verificaçao, referia me a um processo automatico de leitura do conteudo de certificado, com um file em asp por exemplo isso e possivel... Nao estou a ver a Multicert a mandar postais para casa com o finerprint...
New Wave "May The Peace Be Green" |
| | | | Não me parece que "Straigth Forward" e criptografia sejam compatíveis, pelo menos no ponto de vista da autenticação.
|
| | | | Why wonder pq sera que a pagina de abertura do mbnet esta diferente??? Nao era o site tao bom e explicito?! Nao eram os gajos da phibernet uns hackers sem nada para fazer a procura de reconhecimento e outros tantos disparates? Enfim... Isto e uma comedia...
New Wave "May The Peace Be Green" |
| | | | | Não percebes que, se todos os elementos de segurança forem enviados pelo mesmo canal, esse canal torna-se um single-point-of-failure? A Mbnet envia-me o certificado da Multicert pelo mesmo canal do site que está a tentar autenticar. Se o canal for comprometido, o certificado multicert também o é. Estás a assumir que o browser dá avisos quando o fingerprint do certificado muda, mas isso não é garantido. Não está escrito em nenhum standard, e estás apenas a assumir que o comportamento da maioria dos browsers é o comportamento de todos. É falacioso. Ainda por cima, este aviso só acontece se o browser já tiver estado no site, e o utilizador já tenha instalado o primeiro certificado. Se for um browser "virgem", não há aviso nenhum... O melhor, a sério, é ires ler um bocado sobre PKI, e fundamentos de criptografia. Não vais conseguir aqui um curso rápido...
--
If at first you don't succeed, skydiving is not for you |
| | | | | Mas eu nunca falei em enviar todos os elementos de segurança pelo mesmo canal. O correcto devia ser como descrevi no outro post, receberes em casa uma carta com o fingerprint do Multicert, ias à página do MBnet, vias o certificado e ias ao certification path confirmar a autenticidade do certificado Multicert. A partir daí, já tinhas a confiança no MBnet... Outra maneira: telefonas para e pedes o fingerprint do certificado deles. Outra maneira: vais à página da Multicert e confirmas a fingerprint (SHA1 ou MD5) do certificado deles. É claro que também podem hackar a página, ou o DNS. É claro que também podem desviar a linha telefónica, ou o teu correio. Não há coisas 100% seguras. Há apenas vários níveis de segurança. E a haver algum pormenor de segurança descurado no MBnet, de certeza que não é o certificado. Quanto à questão dos browsers... o browser notifica (obviamente) quando o certificado muda, pois tu ao teres um certificado falso não o tens autenticado pela Multicert. Também não sei o comportamento de todos os browsers que existem. Se for um browser virgem, é a primeira vez que a pessoa vai ao site e deve fazer as coisas de inicio, como já tinha dito...
|
| | | | | | Já estou farto disto... Mas pronto... Falas em criar um certificado que diga ser multicert e em usá-lo para assinar um certificado para um site mvnet.pt e esperar um incauto... Esqueces-te que o incauto pode ter já expresso a sua confiança no CA da Multicert (por onde anda a nova?) e estranhar o erro. E, principalmente, esqueces-te que podes fazer exactamente a mesma coisa com um certificado válido, seja da verisign, multicert ou outra coisa qualquer, e não aparecer nenhum erro ao utilizador! Se pensas saber algo sobre man in the middle numa sessão ssl, deverias saber que não interessa a root CA ou esta estar acreditada pelo browser para efectuar o ataque...
hugs
Strange |
| | | | Esqueces-te que o incauto pode ter já expresso a sua confiança no CA da Multicert (por onde anda a nova?) e estranhar o erro. Repara na tua frase: "O incauto pode já ter expresso...". Pode não é suficiente. O site tem que ser intrinsecamente seguro, e não contar com o facto de os utilizadores poderem estranhar qq coisa. As probabilidades aqui jogam contra ti...
--
If at first you don't succeed, skydiving is not for you |
| | | | | "e não contar com o facto de os utilizadores poderem estranhar qq coisa" Bem, era para voltar a repetir aqui todo o meu comentário anterior, mas não vale a pena... Tu próprio dizes que não podem contar com o utilizador estranhar qualquer coisa, ora bem, se o certificado fosse assinado pela VeriSign, por exemplo, e alguem fizesse um ataque man-in-the-middle, "não se poderia contar com o facto de os utilizadores poderem estranhar qq coisa". Ou até podias por um certificado bastante válido para um site mvnet.pt ou coisa parecida, e aí, outra vez, não se poderia "não se poderia contar com o facto de os utilizadores poderem estranhar qq coisa". (Até porque a única coisa a estranhar seria o nome, já que népias aviso de certificado inválido...)
hugs
Strange |
| | | | PORRA! Ate que enfim alguem que percebe que o certificado que tem la e fateloso a brava! Ja agora tenta convecer o Anonimo Cobarde e restante companhia do mesmo que começo a desesperar com tamanha falta de visao.
New Wave "May The Peace Be Green" |
| | | | | De novo os certificados Parece-me que nesta discussão (como na anterior) tem existido uma grande confusão sobre a natureza do objecto "certificado", nomeadamente no que diz respeito à forma como os certificados intervêm numa relação comercial, confundindo-a com a de outros objectos criptográficos. Isso faz com que não exista uma ideia clara sobre o significado das consequências de certas manipulações tecnológicas dos certificados que têm vindo a ser aqui referidas.
Por exemplo, a referência de "ataques de homem-no-meio" a certificados é completamente despropositada; este tipo de ataques aplicam-se a chaves (ou a items que elas determinam) e a natureza do certificado faz com que algo que tecnologicamente se assemelha a um ataque de homem-no-meio é criptograficamente fútil.
Como já referi um certificado comporta-se como uma apólice de seguro. Se A estabelece uma relação contratual com B, se a validade do contrato assenta (como em todos os contratos) na identificação das partes contratantes, se a identidade de B é assegurada por uma terceira parte C, e se existe quebra de contrato por parte de B (porque eventualmente um intruso assumiu o papel de B) então A pode accionar C por danos.
Posto isto, só é verdadeiro certificado aquele documento (com o formato tecnológico apropriado, emitido por uma entidade reconhecida, etc.) que define claramente qual a sua cobertura em caso de danos. Algo que diz que não se responsabiliza por nada, não é certificado: é "dinheiro de Monopólio".
Gerar um certificado em nome de outro é completamente fútil principalmente se esse outro tem facilidade em repudiar a sua titularidade (por evidente falha de verificação na assinatura digital do mesmo, por exemplo, ou por uma variedade de outras técnicas). De facto o falso emissor está a assumir responsabilidades legais que não tem capacidade de controlar: está a usar a tecnologia para se "auto-vigarizar".
Do mesmo modo a autosatisfação de muitos intervenientes a propósito de "certificados que são aceites em 99% dos browsers" é completamente despropositada. Um browser bem configurado NÃO DEVE ACEITAR os pseudo-certificados; um browser bem configurado, que protege os direitos de quem o usa, só deve aceitar os certificados que têm cobertura em caso de danos. Um browser que aceita tudo é como um sistema com as portas todas abertas (ou serão janelas?). jmv
|
| | | | | De facto o falso emissor está a assumir responsabilidades legais que não tem capacidade de controlar: está a usar a tecnologia para se "auto-vigarizar". Eu diria que o falso emissor está-se nas tintas para as responsabilidades legais. Se conseguir concretizar o seu objectivo - roubar - sem que tenha sido revelada a sua identidade. Sendo assim, quem fica com o problema nas mãos não é o dito falso emissor. Um browser bem configurado NÃO DEVE ACEITAR os pseudo-certificados; um browser bem configurado, que protege os direitos de quem o usa... Estamos a falar de um produto dirigido ao grande público. Uma pequena percentagem sabe o que é um browser (e menos ainda sabem configurá-lo), o resto sabe que o computador que tem em casa dá para andar na Internet porque é Pentium. E são esses os alvos à espera de serem vigarizados. O que é que se pode fazer por eles? Essa é que é a pergunta.
Airegin |
| | | | | Eu diria que o falso emissor está-se nas tintas para as responsabilidades legais. Se conseguir concretizar o seu objectivo - roubar - sem que tenha sido revelada a sua identidade. Sendo assim, quem fica com o problema nas mãos não é o dito falso emissor. Não é verdade. O emissor original, porque pode facilmente repudiar o certificado, fica livre de qualquer responsabilidade. Quanto ao falso emissor existem dois tipos de responsabilidade: criminal e civil. A responsabilidade criminal coloca-se porque ele usa uma falsa identidade para obter proveitos ilegitimos (o caso do site falso que aceita encomendas). A responsabilidade civil (danos) coloca-se porque é assumida quando emite o certificado; se isso puder ser verificado (nomeadamente se se gabar desse facto em discussões como esta) o lesado pode aciona-lo por danos. Obviamente que tal pressupõe uma falsificação minimamente inteligente. Se a falsificação for tão grosseira que ele possa alegar que uma pessos minimamente informada não aceitaria tal certificado, então infelizmente os custos recaem sobe o utilizador. Estamos a falar de um produto dirigido ao grande público. ... Essa é que é a pergunta. ... e a resposta é informação. Do mesmo modo que quem usa seguros tem (ou procura ter) consciência das implicações financeiras e legais, quem usa certificados deve fazer o mesmo. jmv
|
| | | | Acho que quem nao pesca puto da materia es tu.
New Wave "May The Peace Be Green" |
| | | | Meus caros, vamos ter calma. Uma coisa é inquestionável, a SIBS meteu a cabeça na areia. Quem seguiu a entrevista ao 2010, pôde ver o melão do "Eng." da SIBS. Quem já passou por Psicologia com eu, estava perante um belo elemento de estudo. Que reações. Mas ele tentou estudar a lição, garanto. Mas o verdadeiro Eng. estava sereno como um cão de fila. "Ele vai cair", pessou o Bordalo".
|
| | | mbnet (Pontos:2, Interessante) |
| por Anonimo Cobarde em 02-10-01 20:34 GMT (#6)
|
| | Penso que tudo isto contribuiu, quanto mais não seja, para discutir a segurança do mbnet, o que só ajuda a melhorar a qualidade do serviço. Há que reconhecer o alerta dos gajos da phibernet neste aspecto. De qualquer maneira, fiquei com a impressão que algumas pessoas levam-se a sério demais. Na minha opnião a mbnet deve continuar com o certificado da multicert. O facto de vir pré-instalado com o browser não é motivo para confiar mais ou menos num certificado. Depois, não fiquei convencido com a solução sugerida para o problema de negação de serviço. Me parece muito menos confiável. Eis trecho do texto retirado de phibernet.org: Mas a instalação deste tipo de sistemas origina a possibilidade de ataques de negação de serviço. Como evitar isto? A nossa sugestão é a seguinte. Na página de autenticação do serviço, deverá existir uma imagem representando 6 caracteres. Esta imagem é deverá ser gerada aleatoriamente cada vez que alguém aceda à página de autenticação, e deverão ser utilizados vários tipos de fonte de letra, vários tamanhos, diferentes alinhamentos verticais e horizontais, bem como diferentes espaçamentos entre os caracteres. A ideia é impossibilitar qualquer reconhecimento automático de carateres (OCR) a esta imagem, evitando desta forma qualquer tipo de ataque automático (scripting). Deverá existir uma terceira input box na página de autenticação, e instruções para o utilizador escrever nesta terceira caixa os números ou palavras que lê na imagem acima descrita. O algoritmo de autenticação deverá ser o seguinte: caso o valor na terceira input box seja igual ao gerado na imagem, prosseguir com a autenticação do username e password; caso contrário, retornar NOK e não contar a tentativa de autenticação como uma tentativa falhada, de maneira a evitar ataques de negação de serviço.
|
| | | | | | A nossa sugestão é a seguinte. Na página de autenticação do serviço, deverá existir uma imagem representando 6 caracteres. Esta imagem é deverá ser gerada aleatoriamente cada vez que alguém aceda à página de autenticação, e deverão ser utilizados vários tipos de fonte de letra, vários tamanhos, diferentes alinhamentos verticais e horizontais, bem como diferentes espaçamentos entre os caracteres. A ideia é impossibilitar qualquer reconhecimento automático de carateres (OCR) a esta imagem, evitando desta forma qualquer tipo de ataque automático (scripting). Deverá existir uma terceira input box na página de autenticação, e instruções para o utilizador escrever nesta terceira caixa os números ou palavras que lê na imagem acima descrita. O algoritmo de autenticação deverá ser o seguinte: caso o valor na terceira input box seja igual ao gerado na imagem, prosseguir com a autenticação do username e password; caso contrário, retornar NOK e não contar a tentativa de autenticação como uma tentativa falhada, de maneira a evitar ataques de negação de serviço. Sugestão interessante, mas falta-lhe uma pequena dose de realidade. Há OCRs capazes de reconhecer escrita manual --- e se até a minha letra, que pouca gente consegue ler, é reconhecida por um Newton antigo, não me parece que se consiga gerar imagens que um ser humano consiga separar em caracteres, mas um computador não. Nem mesmo tentando imitar uma escrita manual, o que me parece que seria monumentalmente difícil (especialmente tendo em conta que o objectivo é impedir que a mesma seja reconhecida por um computador, mas continue a ser legível por um ser humano). Como se isso não bastasse, e citando o texto do artigo: "... apenas com a conjugação dos dois elementos [username e password] se poderia aceder ao sistema e que à terceira tentativa inválida o processo seria bloqueado ..." Três tentativas ? Isso faz-se perfeitamente à mão. Se me apetecer chatear alguém que use o MBNet, basta-me saber a sua identificação, usem eles imagens de caracteres aleatórios ou não. Posto isto, sugiro uma solução que a mim me parece um pouco mais sensata: em vez de suspender o utilizador, suspenda-se o uso da conta durante (por exemplo) meia hora. Assim desencoraja-se quem quiser tentar adivinhar a password, ao mesmo tempo que se torna um pouco mais difícil impedir permanentemente o acesso do utilizador legítimo. Não é perfeito ? Claro que não, mas não me parece que haja solução "perfeita" para este problema.
|
| | | | A solucao quase perfeita e' simples...
basta que o username tambem seja secreto!!!
com uma ligeira mudanca na geracao de usernames, passando a gerar os numeros de forma aleatoria e nao sequencial resolvia o problema do username secreto
se nao souberem do username, nao podem bloquear a conta
( podem tentar bloquear todas da serie, mas nao conseguem repetir isso muitas vezes, acabariam por ser apanhados)
cabe ao utilizador decorar o username e o codigo e nao os relevar, sabendo que se revela o 1º pode ter a conta bloqueada (e haver uma opcao na altura de desbloquear para mudar o username) e revela a 2º, perde $$
basta que quer o username quer o codigo tenham como echo os *s ja' temos uma optima solucao para o problema
nao concordo com o desbloquear passados 30 minutos, pois com algum tempo poderia-se tentar uma boa lista de codigos (combinacoes do # do bi, # telefones, datas varias, matriculas, etc)
sabendo uma data de dados e/ou conhecendo mesmo a pessoa pode-se "advinhar" certos codigos com tempo... nem que demorasse 3 meses, o premio e' alto
basta pensarem quantas pessoas conhecem que usam o pin do telemovel == pin do MB, # = ano que casou, # = meio # de telefone, etc para tornar esta hipotese como perigosa
bloqueando a conta, avisa o dono que alguem tentou entrar com um username que em principio seria secreto... 1 vez poderia ser erro normal, mas varias era um *grande* aviso que alguem esta' a tentar entrar
em relacao ao resto, o site tinha uns problemas nao acho que o site estivesse assim tao inseguro (tambem, 100% seguro so' desligado da eletricidade, da rede e dentro de um cofre no fundo do oceano 8)
na minha opiniao o certificado deveria estar em muitos locais apenas para verificacao de que temos o correcto
por exemplo, nos sites de venda, obrigariam a uma verificacao simples, envio por email do certificado, CDs da clix, iol, netsapo, oni, netc, etc e o que fazer caso nao seja igual
desta forma as pessoas sabiam que tinham o certificado certo e limitaria bastante o problema dos certificados
Higuita |
| | | | "O facto de vir pré-instalado com o browser não é motivo para confiar mais ou menos num certificado." Permita me discordar. O que estas pura e simplesmente a dizer e porque nao ha de a policia confiar num BI feito em casa? Isso e quebrar a regra mais elementar do PKI, a cadeia de confiança. Se querem implemetar Certificados Digitais entao que o façam bem, ou nao o façam! Qualquer pessoa faz um certificado igual, e tb pode dizer que e fiavel. Nao seria grave se nao fosse um meio de pagamento supostamente seguro.
New Wave "May The Peace Be Green" |
| | | | Bom primero que tudo: Nao insultei ninguem, se nao asabes dialogar perdes toda a razao. E realmente tb nao deves saber o que e uma analogia... Enfim 1. Amiguinho, tento na lingua. 2. Nem preciso de te dar resposta pq tu es um "pintas" com mania que sabe, de facto penso que devias alterar a nick para algo do genero "Sabichao cobarde". 3. Eu admito que tenho muito que aprender, mas de uma coisa poder ter a certeza "amiguinho" percebo bem mais que tu que certificados. Mas enfim, para mim "dialogos" com cobardes anonimos acabaram. Get a life meu frustadito da net armado em hacker.
New Wave "May The Peace Be Green" |
| | | | De qualquer maneira, fiquei com a impressão que algumas pessoas levam-se a sério demais. Na minha opnião a mbnet deve continuar com o certificado da multicert. O facto de vir pré-instalado com o browser não é motivo para confiar mais ou menos num certificado. Acho válido que a Multicert se queira promover como CA. Concerteza que eu confio na Multicert, já que é uma empresa portuguesa, com capital suficiente para assumir os riscos contratuais inerentes à certificação. O erro aqui é técnico. O certificado Multicert que me chega às mãos, no site mbnet, vem pelo mesmo canal que os dados que eu quero autenticados. Se o canal for comprometido, vai-se tudo. Habitualmente, os certificados são enviados por outra via. Se enviar o certificado for demasiado incómodo, então envie-se a impressão digital do certificado, para que eu possa confirmar que realmente o certificado está correcto. No entanto, estes procedimentos de verificação de certificados são, nitidamente, demasiado complexos para o cidadão comum. 98% das pessoas não se incomodariam a verificar a impressão digital do certificado, e poderiam cair no ataque que eu descrevi acima. Assim sendo, a forma mais pragmática e segura é: - Negociar com a Netscape e a Microsoft a inclusão do certificado multicert no browser.
- Entretanto, usar certificados de CAs cujos certificados já estão incluídos no browser,
--
If at first you don't succeed, skydiving is not for you |
| | | | Eu aderi a' tres dia ao MBNet, e para alem do mozilla se ter queixado do certificado akilo tudo funcinou bem, e obviu q os meus dados nao estao mto seguros, podem ser vitimas de ataques bruteforce - login com algumas iniciais e uns numeros e uma password composta de 6 numeros nao exitem assim tantas possibilidades:
Password 9A6 = 9^6 = 531441 Para o login quem ja tem o login sabe como e constituido: 3 Caracters do 1º nome e 2 do segundo e mais tres numeros, se a pessoa se chama Jose Romao o login sera JOSROXXX onde xxx sao tres numeros 9A3 = 9^3 = 729. Por brute force nao demora mto tempo a se conseguir apanhar isto. Em relacao ao servico para o pagamento na amazom foi so gerrar um numero de cartao de credito virtual, o valor e introduxido em euros, e meter os dados no formulario da amazon. Funcionou impecalvelmente. Pelo menos o servico nao e tao mau como a seguranca.
--------
_LR_ |
| | | | | | Ups, ya tens razao onde e q eu tinha a cabeca. :(
--------
_LR_ |
| | | | e' que se alguem nao conhecia o servico, agora toda a gente o conhece ;) e' tipo publicidade da benetton...
|
| |
|
