Dropbox Passwords: novo gerenciador de senhas entra em teste

Originally published at: https://tecnoblog.net/344320/dropbox-passwords-gerenciador-senhas-android-beta/

Em fase beta fechada, Dropbox Passwords surgiu recentemente na Google Play Store, sem fazer barulho

1 Curtida

Uso LastPass há anos e não tenho do que reclamar - ok, backup não é muito fácil no Chrome, mas a gente dá um jeito.

√Č bom ver que mais empresas est√£o interessadas em password managers, ainda mais de uma gigante como a Dropbox, mas eles precisam agilizar esse 2FA pra ontem, ou poucos ir√£o usar.

3 Curtidas

Uso o LastPass por falta de opção gratuita mesmo. O app ruim… Tu configura pra não ficar pedindo senha toda hora e ele ignora, toda vez que reinicia o telefone tu tem que manualmente abrir ele pra aparecer na area de notificação (já que a maioria dos apps pra android não suportam preenchimento automático) e quando tem que pesquisar a senha no ato do preenchimento é um caos. Fora que sempre tem que ficar reativando o serviço de acessibilidade, mas isso é erro do Android desde… Desde sempre e nunca corrigido.

3 Curtidas

De gratuito eu uso o Bitwarden, a maioria (se não todos) dos problemas que você mencionou nunca tive problema com ele. Tem todos os recursos do Lastpass e acho que o Bitwarden funciona bem melhor, principalmente o app pra Android. Outra coisa dahora é que ele é open source tbm.

4 Curtidas

Eu uso a vers√£o paga do Bitwarden, achei ele mais completo que o 1Password e custa 1/3 do valor.

O que deixa muito a desejar √© a interface, que digamos, ainda √© meio que ‚Äúespartana‚ÄĚ :sweat_smile:

Fora isso o App é o que de longe melhor me atendeu, mas estou bem curioso do que vai sair daquele projeto open sourse da Apple, também pra gerenciamento de senhas fortes.

2 Curtidas

Eu tenho usado o 1Password e estou bastante satisfeito. Mas por tratar-se do Dropbox acho que eu daria uma chance :slight_smile:

Enpass amigo, não é gratuito, mas tu paga 4 reais por ano. A ferramenta não armazena em servidores próprios (o que já aumenta em muito a segurança), ao invés disso ela permite que você escolha sua própria cloud, dando suporte ao Google Drive, OneDrive, Dropbox entre outros. Ele armazena o arquivo criptografado em sua conta de armazenamento online e faz a sincronização através deste arquivo.

Completo, com extens√£o para todos os navegadores, aplicativo para Android e IOS, software para Linux, Windows e Mac.

Eu o achei procurando uma alternativa ao LastPass e me surpreendi pela qualidade.

Vou testar esse app. Estou com o mesmo problema do Sckill e o Lastpass… app feio e mal feito

Bitwarden user here too :raising_hand_man:t2:

1 Curtida

Uso o Bitwarden achei ele mais fácil de usar do que os outros. Apesar de sua interface simples ele é mais descomplicado e direito ao ponto.

Na verdade, desde o Android 9 os gerenciadores de senha não precisam da acessibilidade, existe o recurso nativo e dedicado. São pouquíssimos os apps que não funcionam, nestes casos, só abrir o gerenciador e copiar a senha.

Eu tenho muita vontade de assinar o premium do Bitwarden no futuro, principalmente pra aposentar o Authy hahahaah

1 Curtida

Eu citei exatamente que a maioria dos apps NÃO suporta a API de preenchimento automático (a Google não exige suporte) e por isso o serviço de acessibilidade é indispensável.

Fora que sempre tem que ficar reativando o serviço de acessibilidade, mas isso é erro do Android desde… Desde sempre e nunca corrigido.

Voc√™ disse que √© um erro do sistema e que n√£o foi corrigido at√© hoje e eu te disse que o recurso dedicado e nativo j√° existe, portanto a necessidade de acessibilidade n√£o √© um erro do Android. Agora se voc√™ estiver falando que ter que ficar reativando o servi√ßo de acessibilidade que √© o erro, isso tamb√©m n√£o √© um erro. O sistema desativa a cada atualiza√ß√£o do aplicativo que o usa, por quest√Ķes de seguran√ßa. O recurso de acessibilidade √© muito perigoso e cria uma brecha muito grande, desta forma, a cada atualiza√ß√£o do App, o S.O o desativa por quest√Ķes de seguran√ßa, evitando que um app use a acessibilidade sem conhecimento do usu√°rio.

O app n√£o precisa ser atualizado pra ser desativado, se ele travar ou algo encerrar ele em plano de fundo j√° √© o suficiente. Tudo que √© falha de projeto no Android algu√©m coloca esse discurso de que √© uma ‚Äúfeature‚ÄĚ de seguran√ßa, s√≥ esqueceu que √© um recurso de ACESSIBILIDADE, nesse caso usado pra burlar o descaso da Google em impor suas APIs, mas vai explicar pra quem usa pra conseguir usar o dispositivo (ou seja, quem precisa de acessibilidade) que o telefone fica desativando a ferramenta que permite ele usar aparelho por ‚Äúseguran√ßa‚ÄĚ. Apps com acesso de administrador do dispositivo pode literalmente apagar todos os dados, desativar a senha‚Ķ E n√£o exigem reativa√ß√£o depois de atualiza√ß√£o.

Da uma lida na documentação do que é possível fazer com o recurso de acessibilidade e aí tu me responde se realmente é bacana ele permanecer ativado ad eternum.

Não é justificar falha de projeto, é que usuário adora reclamar de qualquer recurso que ofereça um mínimo de segurança.

Reclama de 2FA, reclama de política de senha, reclama de ter que dar permissão, reclama de recursos perigosos como o de acessibilidade sendo desativados de tempo em tempo.

Mas quando d√° a merda, culpa o sistema.

Meu querido, pra justificativa de segurança ser valida, o mínimo que se espera é que haja um aviso antes de atualizar e que não atualize automaticamente, mas não só isso não existe como não é atualização que desativa o serviço, e sim qualquer interrupção forçada do processo. Se você pensa como segurança como algo acima da experiencia de usuário, que se justifica em si mesma, tá pensando errado; tanto que tá pensando em segurança justificando a falta de acessibilidade.

Repito, veja o que é possível fazer com o recurso de acessibilidade e depois volte para conversarmos.

Lembrando que isso acontece apenas com aplica√ß√Ķes de terceiros, o que n√£o incapacita a acessibilidade para quem realmente precisa, pois a leitura de tela, melhorias de visibilidade, melhorias de audi√ß√£o, entre outros, s√£o nativos do sistema.

A acessibilidade √© cortada de tempos em tempos apenas para aplica√ß√Ķes externas, pois estes aplicativos ganham a capacidade de ler e detectar todo o conte√ļdo de sua tela, tornando-se o recurso mais utilizado pelos atacantes, se desativando de tempos em tempos, j√° √© usado justamente por que o usu√°rio o fornece para qualquer aplicativo que pede, imagina se n√£o fosse desativado.

Além disso, se você estudar um pouquinho de S.I, verá que o usuário não tem que ser informado de todos os controles de segurança aplicados.

Por fim, a atualiza√ß√£o autom√°tica pode ser desativada, passando a avisar que existem atualiza√ß√Ķes para acontecer, mais um ponto que voc√™ desconhece e est√° criticando.

Ao invés de ficar reclamando que a acessibilidade é desligada, sendo que está sendo usada de forma indevida. Cobre os desenvolvedores de seus aplicativos preferidos que usem o atributo autofill_hint que melhora o funcionamento do auto preenchimento e torna desnecessário o uso do recurso de acessibilidade.

Se fossemos apontar uma falha de projeto, a falha est√° em n√£o for√ßar que os campos de entrada de dados estejam devidamente implementados ou mesmo munidos do atributo ali citado, para tornar o recurso de auto preenchimento utiliz√°vel para todas as aplica√ß√Ķes.

Essa sim √© uma das falhas, n√£o o de desligar de tempos em tempos, aplica√ß√Ķes terceiras do servi√ßo de acessibilidade.

E um ponto interessante na discussão, dependendo da fabricante, uma aplicação de terceiros pode ser colocado na Whitelist para que não tenha mais o recurso desativado, como o caso do Samsung Knox que permite tal ação.

E por fim, respondendo a um coment√°rio bem prec√°rio seu, seguran√ßa faz parte da experi√™ncia do usu√°rio, pois quando voc√™ tem suas informa√ß√Ķes comprometidas, voc√™ tem uma m√° experi√™ncia e consequentemente, tamb√©m ir√° reclamar do sistema, plataforma ou o que mais for.

Portanto n√£o existe essa hist√≥ria de permitir uma vulnerabilidade s√≥ porque o usu√°rio acha chato ter que dar nova permiss√£o para o recurso utilizado. Permiss√Ķes nunca deveriam ser ad eternum, ainda mais quando s√£o de alto risco :wink: