Se você não se deu bem com nenhum gerenciador de senhas disponível atualmente, saiba que uma nova opção está vindo aí: o Dropbox Passwords foi lançado recentemente para Android. Ou quase isso: embora você já possa baixar a ferramenta na Google Play Store, por ora, ela só funciona para quem tiver convite.
A explicação está no fato de Dropbox Passwords estar em fase beta fechada. Provavelmente, é por isso o Dropbox disponibilizou a novidade sem fazer alarde.
Mas, com base na descrição do aplicativo na Play Store e nas capturas de tela disponibilizadas ali, é possível perceber que a ferramenta é bastante simples na comparação com soluções como 1Password e LastPass.
Pelo o que já se sabe, o Dropbox Passwords gera senhas fortes para diversos tipos de serviços, permite sincronizá-las em vários dispositivos, suporta “criptografia de conhecimento zero” (apenas o usuário tem acesso aos dados armazenados no aplicativo) e permite preenchimento automático de campos de login.
Por outro lado, funções avançadas, como importação de senhas de navegadores e integração com autenticação em dois fatores são recursos ausentes.
Das duas, uma: ou o Dropbox quer mesmo que o seu gerenciador de senhas seja básico — talvez para atrair um grande número de usuários pela facilidade de uso — ou a ferramenta simplesmente está em fase muito inicial de desenvolvimento.
Como não há anúncio oficial sobre o Dropbox Passwords, ainda não é possível entender quais os planos para a novidade ou como é possível obter um convite para a fase beta, por exemplo. Mas vale a pena ficar de olho: vindo de onde vem, o novo gerenciador de senhas tem tudo para ser uma opção realmente interessante.
Com informações: Android Police.
Comentários da Comunidade
Participe da discussãoOs mais notáveis
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.
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.
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.
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”
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.
Eu tenho usado o 1Password e estou bastante satisfeito. Mas por tratar-se do Dropbox acho que eu daria uma chance
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
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
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.
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
Eu sei muito bem que atualização automática pode ser desativada, mas se a atualização desativa algo essencial, ela deve ser desativada por padrão, assim como até o Android 5.1 a atualização automática não acontecia se o app exigisse novas permissões; e segue a justificativa de que não é la que desativa o recurso, mas qualquer interrupção do processo. “Todos os recursos de acessibilidade necessários já vem instalados”, se esse fosse o caso, essa API sequer existiria, a própria Google tem app de acessibilidade que não vem instalado por padrão.
O usuário não tem que ser informado dos controles de segurança que não seja conviniente informar, se um controle interfere diretamente na interação dele, ele deve sim ser informado. Sistemas com UX mediocre por SI mal implementada não são mais seguros, só são mediocres.
Entendi, então na sua visão, desativar um aplicativo de terceiro que usa um recurso extremamente nocivo, não lhe deu mais segurança, simplesmente porque não te deu uma notificação de que ele será desativado? Ou seja, o fato de não existir essa notificação desejada por ti, significa que não tornou-se mais seguro?
E a existência da API não tem relação com o fato do sistema não oferecer as funções necessárias, a API existe para ampliar a funcionalidade, mais um equivoco seu.
E por fim, como eu disse, fabricantes fornecem possibilidade de adicionar no whitelist para que o mecanismo de segurança seja ignorado.
Seria interessante, você não inventar o que não foi dito, porque o que eu escrevi é bem diferente. Manter o que foi dito é essencial para entendimento. Vamos ao que eu deixei de comentário:
Não gastei anos da minha vida com desenvolvimento de software pra ficar discutindo com quem tem visão de UX não importa, siga com sistemas mediocres. #pas
Não gastei e gasto anos de minha vida atuando e estudando tanto em desenvolvimento como em S.I para ficar discutindo com alguém que não tem a capacidade de entender o quão danoso isso pode ser ao usuário. Siga com sistemas medíocres, colocando o usuário em risco e achando que oferecer segurança não tem a ver com experiência
#pas