#Keeweb rewrite how to#
#Keeweb rewrite for android#
#Keeweb rewrite software#
#Keeweb rewrite code#

Third party server holding the encrypted data. Quite polished browser integration (to the extent browsers allow it).

#Keeweb rewrite software#

Is essentially a service (with FLOSS client software and FLOSS server code). Let me try to make it a little bit more detailed. The linked article is very light on details to be called a comparison. For typed passphrases, I no longer use anything except Diceware - not only are they easier to remember and enter, they're also more 'expendable' and don't require any particular attachments to be formed since the generation process is robust and unbiased (unlike 'hashed' passages from books and song lyrics).įor English-speakers, I recommend the EFF's list linked at I think a combination of no more than a few Diceware passphrases combined with password manager-generated passwords for all other sites is a balanced option.

The process with real dice is quite fun to do and feels meaningful enough that it's adhered to and memorised. After all, a solid passphrase is required for the password database, so learn two (or three - quick local system login might also handy).

#Keeweb rewrite for android#

If it's something as dire as a fire where all devices including the phone are lost (by the way, for Android I favour Keepass2Android which comes with Dropbox syncing & fingerprint reader support), you would probably need to get replacement identity documents as well as a new phone & SIM card for the same number (it's probably quicker in the meantime to have the Google Account Recovery robot call another number you've previously listed to reset a 2FA/password).Īdditionally, I don't think using a Diceware passphrase is a bad idea so long as it's never reused. I don't know what Dropbox's account recovery procedure is (which does have a support ticket system available), but if you also back it up to Google Drive you can recover the Google account by an automated phone call to a specified number.Īccessible off-site backups are obviously good, but for various reasons it's unlikely everybody does this so I think the method above should be reasonable. The website looks clean, is user-friendly with up-to-date documentation, and a is plainly visible in the README on GitHub.Īs a result, I feel a bit better about the long-term prospects of KeePassXC over KeePass 2. In contrast, KeePassXC is hosted on GitHub, development is done out in the open, and it's trivial to see that in just the last year there were. Similarly, the website is ancient and doesn't seem to have kept up with the times I seem to recall it was only recently that it even got HTTPS support.

#Keeweb rewrite how to#

As a result I'm not really sure how to gauge the level of activity on the project itself.

#Keeweb rewrite code#

The seems to be an outdated SVN repo which was last updated in 2009, and I don't see any description of how to contribute code to the project anywhere. KeePass 2 seems to still be hosted on Sourceforge, and I'm not even sure where to get a copy of the latest (non-release) version of the source. But which is just right for the use case.I'm strongly considering it just based on the community surrounding each project. The coolest feature is the keypass ssh-agent plugin (currently only for keepass standard), which would let you ssh around the world with the same certs that your infrastructure uses internally.Īlternatively, by simply connecting to vault as the main back end, we would have a quite reduced schema. Through interaction with the api endpoint, the user could even create and invalidate secrets. The best integration of those two worlds would be a plugin which allows building a subtree of the vault stored secrets (and they basically only do have those 5 fields from above). So this means any value can theoretically be mapped, but this would probably not be sensible and not what vault excels at.