Fórum Ubuntu Linux - PT
Área para Iniciantes => Iniciantes => Tópico iniciado por: paulobelo em 21 de Janeiro de 2015, 19:26
-
Falha de segurança?
Todos sabem que para deixar uma pasta oculta basta por um ponto antes do nome da pasta.
Uma das pastas que por padrão é oculta é a pasta ".cache" que fica no seu diretório home.
Dentro dessa pasta como era de esperar ficam arquivos que o sistema, não sei por que critério, julga que serão reutilizados frequentemente e por isso não vão para a pasta .temp onde seriam eliminados quando o computador fosse desligado.
No caso que me preocupa ocorreu que dentro dessa pasta .cache o sistema criou diversas outras pastas, .fr-9NiKur, .fr-e8A4Of, .fr-fG5w3J e assim por diante.
Em várias dessas subpastas eu encontrei um arquivo ,uma planilha que eu tinha aberto há pelo menos duas semanas.
O problema é que essa planilha, vamos chamar de A.xls estava num arquivo zipado com senha.
Eu utilizava a planilha para guardar senhas, dados de login etc. de bancos, sites de compras, do fórum do Ubuntu, de sites públicos, etc...
Para vocês terem um ideia uma das senhas que eu guardava nessa planilha era a minha senha do Tesouro Direto onde eu tenho aplicações expressivas.
Durante mais de 15 dias essa senha e várias outras ficou a disposição de qualquer pessoa que lesse o conteúdo da minha pasta .cache pois o arquivo A.xls não foi apagado.
Portanto segundo eu entendi toda vez que você abre uma arquivo que está compactado num arquivo tipo zip, ou tar , 7z, .rar protegido por senha ele pode ficar exposto por vários dias no seu cache.
Então eu pergunto, qual a utilidade da senha se o arquivo aberto vai para o cache e não é apagado?
A coisa piora quando sabemos que muitos usuários novos nem sabem da existência dessas pastas ocultas e não são advertidos desse risco.
Há alguma maneira do sistema deletar automaticamente essas subpastas criadas?
-
Bom... não sei te dizer se isso é uma falha, mas por hora eu te aconcelho a usar isto para guardar suas senhas:
https://apps.ubuntu.com/cat/applications/keepassx/
-
Bom... não sei te dizer se isso é uma falha, mas por hora eu te aconcelho a usar isto para guardar suas senhas:
https://apps.ubuntu.com/cat/applications/keepassx/
1Obrigado pela sugestão.
Eu utilizo o Keepass mas ainda estou migrando, não inclui todas as minhas senhas.
Mas o amigo há de convir que isso não resolve o problema porque os arquivos compactados não servem só para guardar senhas.
Além de fotos e filmes xxx pode haver documentos, planilhas e outras arquivos que vc desejar manter privativos.
-
Bom... não sei te dizer se isso é uma falha, mas por hora eu te aconcelho a usar isto para guardar suas senhas:
https://apps.ubuntu.com/cat/applications/keepassx/
1Obrigado pela sugestão.
Eu utilizo o Keepass mas ainda estou migrando, não inclui todas as minhas senhas.
Mas o amigo há de convir que isso não resolve o problema porque os arquivos compactados não servem só para guardar senhas.
Além de fotos e filmes xxx pode haver documentos, planilhas e outras arquivos que vc desejar manter privativos.
Pois é, eu entendo. Se você tem arquivos muito importantes no compuador o ideal mesmo é fazer uma instalação do ubuntu com pasta /home criptografada, e sempre que for deixar o computador sozinho bloquear a tela para que ele pessa a senha depois. E/ou criar um perfil de usuário padrão no seu ubuntu que tenha restrição de acesso aos arquivos da sua conta de administrador caso outras pessoas usem o mesmo pc. Também não esqueça de fazer um backup na nuvem, claro, com um zip criptografado.
-
Falha de segurança?
Do sistema? Não.
Então eu pergunto, qual a utilidade da senha se o arquivo aberto vai para o cache e não é apagado?
Dependendo de como criou esse zip, é extremamente fácil de descobrir a senha, e o conteúdo nunca esteve realmente protegido. Se uma coisa é boa o suficiente, ou não, depende do fim.
Há alguma maneira do sistema deletar automaticamente essas subpastas criadas?
Até dá, se você souber qual é o programa que está criando o cache talvez tenha como desabilitá-lo, no pior caso também é possível criar um cronjob que apague o diretório a cada x minutos. Pro seu uso, o melhor é algo como o já sugerido keepass.
-
Salve a planilha em odt com senha e veja se ocorre o "problema".
-
Talvez eu tenha me expressado mal.
Ou talvez a minha duvida seja "filosófica".
Porque um arquivo compactado tem uma senha ou melhor, porque a pessoa que criou o programa de compactação incluiu uma ferramenta de senha?
Para manter sigiloso o conteúdo do arquivo na hora de armazenar ou transferir, certo?
No segundo caso acho que a ferramenta cumpre o seu objetivo mas no primeiro caso se o conteúdo é extraído 1 vez ele vai para o cache do Ubuntu e fica totalmente desprotegido a partir daí e sem que os usuários, ou pelo menos a maioria deles, sequer desconfie.
Não creio que salvar o arquivo como odt ajude neste caso .
Quanto à segurança do arquivo zip sei que nada é 100% seguro, a senha desse arquivo tem 10 caracteres, maiúsculas, minusculas, números e símbolos escolhidos aleatoriamente.
Acho que com um pouco de sorte resistiria bem a um ataque hacker usando a tática força bruta
Dezenas de anos ou mais já que são centenas de trilhões de combinações possíveis.
Mas no cache está completamente sem proteção.
Como eu faço para usar o cronjob de tal maneira que só delete as subpastas fr-...... da pasta .cache?
-
Deve ser um bug do ubuntu ou do fileroller do Gnome. O melhor a fazer nesse caso é ir no Launchpad e reportar. :-\
-
Quanto à segurança do arquivo zip sei que nada é 100% seguro, a senha desse arquivo tem 10 caracteres, maiúsculas, minusculas, números e símbolos escolhidos aleatoriamente.
Acho que com um pouco de sorte resistiria bem a um ataque hacker usando a tática força bruta
Dezenas de anos ou mais já que são centenas de trilhões de combinações possíveis.
Voce não intendeu, um zip padrão usa um método de criptografia que ha anos já foi mostrado que é falho. Tanto faz o tamanho da senha, e até onde sei - no linux - pra criar um zip com um bom método de criptografia só usando o p7zip.
-
Acho que vcs não entenderam a minha preocupação.
Eu não estou preocupado com a qualidade da criptografia do arquivo zip porque o meu problema é bem pior que isso.
Que me adianta uma criptografia de 1024 ou 4096 bits nesse caso?
O meu problema não é o arquivo zipado ser vulnerável, que a criptografia seja quebrada, não é isso.
O problema é que a informação que eu queria proteger vai para o cache do Ubuntu e lá fica sem criptografia nenhuma.
Entenderam?
-
Não tem relação nenhuma com quantidade de bit, e o meu ponto é que mesmo que não fosse pro cache, o que você colocou no zip nunca esteve protegido, você só achava que estava. Dependendo do que você estiver fazendo isso pode ser o suficiente, e nesse caso o cache não deve fazer diferença, agora se não acha razoável, não salvar em cache não vai resolver nada, você tem que usar outra ferramentas.
-
Não, eu não acho razoável.
E volto a reafirmar que o meu problema não é nem nunca foi o nível de qualidade da criptografia do arquivo zipado.
Usar o p7zip como você sugeriu não faria a menor diferença neste caso a não ser que o arquivo descriptografado e lido não fosse para o cache.
E sobre o número de caracteres da senha, é claro que faz diferença, é uma questão de análise combinatória, matemática.
O que eu gostaria é que um arquivo protegido por senha dentro de um arquivo compactado, seja qual for, p7zip. zip, rar, sei lá não fosse para o cache do Ubuntu.
Ou uma forma de apagar automaticamente as subpastas a que eu me referi no primeiro post e que são criadas pelo sistema para armazenar os arquivos extraídos do arquivo compactado.
Se o que eu quero fazer não pode ser feito, paciência, vou procurar outra alternativa para guardar documentos diversos com senha sem que seja obrigado a deletar as subpastas manualmente toda vez que eu abro um arquivo sigiloso protegido por senha.
De qualquer maneira, obrigado a todos pelas informações e sugestões.
-
E sobre o número de caracteres da senha, é claro que faz diferença, é uma questão de análise combinatória, matemática.
Depende do algorítimo, se o algorítimo for uma M pode ter uma senha de um caralhazilhão de caracteres que mesmo assim não servirá de nada.
Mesmo que eu anote minhas senhas em um pedaço de papel não terei problemas se ninguém mais o ver. Por isso eu sugeri uma instalão do ubuntu com /home criptografada, é só cuidar pra nenhum pentelho fuçar no seu computador e está tudo certo.
De qualquer maneira, se isso for um bug creio que o launchpad é o local mais correto para reportar.
-
Vou explicar de outra forma pra ver se assim fica claro: você tá colocando um cadeado na porta da frente, mas tá escondendo a chave na caixinha de correio, e todo mundo sabe e tem acesso a ela; não importa se agora você viu que a porta dos fundos só está encostada, trancá-la não vai mudar nada, se alguém quiser entrar vai conseguir facilmente. Zip normal com senha ou sem senha te fornecem o mesmo nível de segurança, com o p7zip dá pra criar um com AES (e de quebra, como não vai estar usando o compactador de arquivos padrão, ele não vai gerar esse cache), mas pelo seu uso o melhor é algo como keepass pra senhas e uma partição criptografada pro resto.
-
Consegui achar mais informação sobre isso.
O bug é do programa File Roller.
E ocorre quando o programa "fecha repentinamente" ou quando o micro é "desligado repentinamente".
Nesse caso os arquivos não são delatados automaticamente.
Isso acontece porque o File Roller armazena temporariamente os arquivos abertos numa pasta criada por ele "~/.cache/.fr-******" quando deveria
armazenar os arquivos em "/tmp"
Vejam a descrição do bug (em inglês);
https://bugs.launchpad.net/file-roller/+bug/883628
https://bugzilla.gnome.org/show_bug.cgi?id=541616
https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/245716
https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/883628
Vou usar um outro programa para abrir os arquivos zipados (o Xarchiver), desligar o micro pela tomada hehe e dar um feed back.
-
Fiz o teste e realmente com o Xarchiver não aconteceu nenhum problema.
O arquivo é armazenado em /tmp e deletado quando o programa Xarchiver é fechado.
Quando o computador é desligado de modo repentino, tipo falta de energia, o arquivo é deletado do mesmo jeito, acho que na reinicialização.
Vou dar o tópico como resolvido embora o bug no File Roller persista.
Obrigado pela atenção.
-
O arquivo é armazenado em /tmp e deletado quando o programa Xarchiver é fechado.
Evidentemente o que você relata é um bug e dos feios, aliás, muito difícil de descobrir e, por isso, altamente perigoso, pois uma quebra de segurança só é perigosa quando ninguém sabe dela, pois quando se fica sabendo acaba o risco.
De toda forma, analise detidamente o uso e comportamento também do Xarchiver, pois certa feita tive uma experiência similar no ambiente Windows com um programa de criptografia excelente, o Blowfish Advanced CS, o qual ao descriptografar um arquivo igualmente usava a pasta tmp, porém quando se invertia a ordem de fechamento do programa o arquivo permanecia descriptografado na pasta temporária, isto é, não era eliminado, também descobri isso por acaso.
-
Bug não, pra ler algo compactado/criptografado só descompactando/descriptografando, mas como qualquer usuário tem acesso ao /tmp, dependendo do que for pode ser mais prudente não abrir.
-
Amigos coloquei aqui porque não sei em que parte do fórum colocar (talvez em dicas e truques).
Espero contar com a tolerancia dos moderadores, hehe.
Eu criei um arquivo zipado (pw.zip) protegido por senha.
Dentro do arquivo zipado há um arquivo de texto (teste) com uma frase.
Quem se dispor a quebrar a criptografia do arquivo, usando programas como o RarCrack! por exemplo deve apenas me dizer qual é a frase que está no arquivo texto.
O link para quem quiser baixar o arquivo e tentar descobrir a senha é este:
https://www.sendspace.com/file/w2tufi
Se alguém conseguir quebrar a senha, por favor compartilhe conosco o programa utilizado, o tempo gasto e as configurações do computador/computadores utilizado.
-
Qual o propósito? Você sabe que abrir, ou não, esse arquivo não prova nada, né? Mas também não precisa acreditar na minha palavra, na Wikipédia (http://en.wikipedia.org/wiki/Zip_%28file_format%29#Encryption) tem um parágrafo sobre o assunto, e você pode ler os artigos acadêmicos lá dos anos ~2000 quando a falha foi encontrada.
-
O propósito é adquirir e compartilhar conhecimento, só isso.
Discordo de você sobre não provar nada, pode provar que o número de caracteres da senha faz diferença e muito.
Se esse arquivo tivesse um senha de 4 caracteres um programa que usa a tática de força bruta acharia a senha em relativamente pouco tempo. Como a senha que eu escolhi tem muitos caracteres, números, símbolos e letras maiúsculas e minúsculas é muito improvável que alguém consiga quebrar a criptografia, muitíssimo improvável, eu diria.
Eu entendo que vc quer alertar as pessoas quando salienta as deficiências de criptografia no zip.
Mas o ótimo é inimigo do bom, não devemos nos tornar paranóicos e para a maioria das pessoas uma boa senha é suficiente em 99% das necessidade delas.
E as vezes, o perigo maior está em falhas de programas como no caso que eu citei ou na forma do usuário trabalhar com seus arquivos sigilosos.
Mas é claro que se vc for um Daniel Dantas, um agente secreto, um terrorista é melhor usar uma criptografia mais robusta, hehe.
Eu sei que vc entende muito mais de programação que eu , Irtigor, mas nem por isso sou obrigado a concordar contigo em tudo.
A propósito, fiquei muito interessado na sua sugestão de usar um cronjob para deletar as subpastas em intervalos de tempo. Eu não sabia que existia essa ferramenta.
-
Como já disse, nesse caso tanto faz o tamanho da senha, o algorítimo é falho e portanto não é sempre necessário tentar toda e qualquer combinação, a página da Wikipédia sobre o zip fornece um link pra página que fala do ataque usado (http://en.wikipedia.org/wiki/Known-plaintext_attack). Se pedir uma senha (independe dela ser necessária ou não), já o suficiente pra você: ótimo, caso contrário você vai pelo menos usar o p7zip pra criar/alterar esses zips com senhas.
-
[...] a página da Wikipédia sobre o zip fornece um link pra página que fala do ataque usado.
Salvo engano e sem ter ido mais a fundo na questão, fiquei com a impressão que essa questão relativa aos arquivos zip está superada.
Aconteceu no passado, nos formatos antigos, porém o problema parece que não persiste atualmente, além do que claramente o texto indicado diz que não ocorre o problema nos arquivos zip que usam encriptação AES.
Repito, não verifiquei mais detidamente o estado atual do assunto e nem mesmo sei detalhes da versão usada para Debian/Ubuntu, porém acho pouco provável que essa fragilidade ainda exista nos zipes atuais.
-
O problema não existe se o plicativo implementar encriptação com AES, como definido no formato em ~2003, coisa que - até onde eu sei - só o p7zip provavelmente faz no Linux.
-
Pela última vez.
O problema que eu reportei não tem nada a ver com criptografia nem com algorítmico de criptografia.
Trata-se de um bug do Fille Roller e afeta qualquer arquivo compactado, de qualquer tipo, zip, rar, 7z, não faz diferença a técnica de criptografia utilizada.
Se vcs quiserem discutir a segurança de arquivos zip com senha, abram outro tópico, por favor.
-
Retificando o que eu disse em #4, o /irtigor/ tem plena razão, o uso de password na encriptação de arquivos zip continua insegura, imaginava que isso tivesse sido corrigido, mas na realidade não foi, continua o mesmo problema.
O texto abaixo é do próprio manual do zip (man), portanto não mais resta dúvida:
--password password
Use password to encrypt zipfile entries (if any). THIS IS INSE‐
CURE! Many multi-user operating systems provide ways for any
user to see the current command line of any other user; even on
stand-alone systems there is always the threat of over-the-
shoulder peeking. Storing the plaintext password as part of a
command line in an automated script is even worse. Whenever
possible, use the non-echoing, interactive prompt to enter pass‐
words. (And where security is truly important, use strong
encryption such as Pretty Good Privacy instead of the relatively
weak standard encryption provided by zipfile utilities.)
-
O problema que eu reportei não tem nada a ver com criptografia nem com algorítmico de criptografia.
Trata-se de um bug do Fille Roller e afeta qualquer arquivo compactado, de qualquer tipo, zip, rar, 7z, não faz diferença a técnica de criptografia utilizada.
Veja, /paulobelo /, as questões são interligadas.
Você tem razão ao dizer que há um bug na implementação do "Fille Roller", de fato há essa lamentável falha, porém o /irtigor/ também tem razão ao dizer que mesmo que não houvesse essa falha, o seu arquivo de senhas ainda estaria inseguro em razão do método falho de password para encriptação dos arquivos zip.
-
Inseguro em que termos?
Os dados do seu CC estão seguros nos sites em que vc faz compra?
O site do seu banco é seguro?
As suas fotos e contatos estão seguros no FaceBook?
Este site é seguro?
O site da NSA está a salvo dos hackers chineses?
A criptografia dos arquivos zip é satisfatória para mim, estou confortável com a segurança que me proporcionam.
Vc e outros podem não estar, ok.
A preocupação de vcs é mais que válida mas o problema do Fille Roller não tem absolutamente nada a ver com criptografia, nada.
-
A criptografia dos arquivos zip é satisfatória para mim, estou confortável com a segurança que me proporcionam.
O seu raciocínio está correto, a segurança é relativa àquilo que se pretende dela, **não precisa sempre** ser absoluta, pode sim ser relativa, desde que sopesado o custo-benefício, isto é, avaliado o risco e o prejuízo potencial.
Note que no próprio texto do manual do zip é dito: "And where security is truly important, [...]", ou seja, eles próprios fazem o alerta, porém admitem o uso, ressalvando que naqueles casos onde a segurança é verdadeiramente importante (ou o risco maior), então é melhor recorrer a outros métodos, o que implica em dizer que onde o risco for menor é possível usar um método mais "fraco", que é o padrão do zip.
-
A preocupação de vcs é mais que válida mas o problema do Fille Roller não tem absolutamente nada a ver com criptografia, nada.
Vou tentar explicar mais uma vez, se não intender, paciência. Você argumentou que como o cache não é apagado, o zip só passa uma falsa sensação de segurança, porque alguém pode ser experto o bastante pra achar o diretório, com o arquivo sem senha. Eu estou afirmando que nesse caso isso tanto faz, porque mesmo que o cache não fosse salvo, esse formato tem outros problemas, tudo que você vai conseguir é uma falsa sensação de segurança, e também já deixei a intender que isso pode ser tudo o que precisa, e ai não teria problema em continuar sem mudança alguma.
---
Obs: juntei os tópicos.
-
Pelo que me parece, acheio que paulobelo e irtigor querem dizer é que segurança é algo relativo. Porém estão dizendo isso de modo diferentes e parece que um não intende o outro rs, mas no final das contas os dois querem dizer a mesma coisa.
A questão é semelhante ao caso da criptografia wep para wireless, teoricamente é muito fácil invadir uma rede que usa esse tipo de senha, mas ai eu te pergunto: dos vizinhos que você tem e provavelmente conhece um pouco, quantos deles você acredita que são capazes de utilizar os softwares necessários para fazer uma quebra de senha? A maioria só sabe trocar o papel de parede e rolar a página do facebook para baixo. Então nesse caso podemos dizer que uma rede wireless com senha web é "segura". Mas agora se eu sou dono de uma agência finânceira bem no meio do centro de uma grande cidade, e eu faço várias transações de centenas de milhares todos os dias usando um notebook no meu escritório, é bem óbvio que precisarei de uma criptografia melhor, e o tal wep não será mais seguro.
-
A diferença é que ele acha que removendo o cache ele vai estar mais seguro, e eu discordo. Alguém disposto a procurar, e achar o cache, pode facilmente ver (tá até na Wikipédia) que esse formato tem falhas que podem ser exploradas pra conseguir o que está dentro.
-
Essa polêmica não está levando a nada de produtivo para ninguém e eu francamente não entendo essa sua insistência em repetir sempre a mesma coisa.
O ponto que eu quis levantar não é aquilo que vc insiste em repetir ad aeternum.
Vejamos:
1-Eu crio um arquivo compactado protegido por senha usando a encriptação do zip. 2.0.
2 Você faz a mesma coisa utilizando uma encriptação AES 256.
Qual dos dois está mais seguro?
Nenhum dos dois se visualizarmos o arquivo utilizando o File Roller.
O ponto a ser discutido aqui é se esse é um bug que pode ser qualificado como um risco de segurança e se for, se é risco pequeno, grande, ou enorme.
-
Essa polêmica não está levando a nada de produtivo para ninguém e eu francamente não entendo essa sua insistência em repetir sempre a mesma coisa.
Porque as suas respostas seguintes me levavam a acreditar que você não tinha intendo da primeira vez.
O ponto que eu quis levantar não é aquilo que vc insiste em repetir ad aeternum.
Vejamos:
1-Eu crio um arquivo compactado protegido por senha usando a encriptação do zip. 2.0.
2 Você faz a mesma coisa utilizando uma encriptação AES 256.
Qual dos dois está mais seguro?
O segundo é mais seguro por definição. Eu não rodo o Ubuntu pra testar, e não é claro se o file roller é capaz de abrir o 2 (ele tem o p7zip como dependência pra abrir arquivos 7z, falta confirmar que esse port do 7zip implementa AES, e em caso positivo, se o file-roller intende esses zips criptografados com AES).
Assumindo que ambos podem ser descompactados/compactados, se os arquivos ficam permanentemente então há um problema. Talvez, se suportar o 2, ele seja chamado de "risco de segurança".