Obviously, 1.0 is just the start for PAVE. We feel that it has enough features to be useful to a broad range of customers, but obviously we cannot cover every possible workflow with the initial release.
Windows server support
Technically both PAVE and the key server already execute under Windows, but tossing people an EXE and telling them to be happy with it tends to be frowned upon. Proper MSI packages and service definitions will be provided with the first release of PAVE server for Windows. An MSSQL database adapter might be provided later.
Mobile OS support
Mobile clients are probably the most obvious (and annoying) omission. Yet the complexity of getting them right on the first try prevents them from being candidates for the initial release. Over the next few months we’ll work on and release clients for the usual suspects (iOS and Android; Windows Phone might also be supported depending on demand), for the paid versions first. The free version will see them later (due to of the additional effort of adopting the paid version for a different storage backend.)
This is mainly intended to better secure they key server’s keys against password theft. The regular server will also see 2FA support, but it will likely only be used for the administrative functionality, and not for submitting passwords.
Currently planned is implementing TOTP, as used by Google Authenticator and others.
(TOTP client support inside PAVE – so it can be used to authenticate against other 2FA enabled services – is being evaluated, but at this point not sure to see implementation. I’d like to see feedback on this one first.)
Many services allow changing passwords via API calls, so users can skip clicking through the UI. An on-password-change hook will be added to PAVE so users can (semi-)automatically renew passwords from inside PAVE. This will be scriptable so customers can implement their own for their internal infrastructure, or to implement password guidelines, and so on.
This one I’m a bit iffy on. All the competition has it… and it’s their single biggest attack surface, because browser plugins are hard to secure (not just against true attacks, but also against things like phishing attacks, which work independently of actual plugin security). We invested considerable effort into streamlining our UI to maximize productivity without needing one, but it still might be useful.
For now I’m leaning towards a solution that uses our PaveLink functionality to call out to PAVE without actually transferring any sensitive data sans user interaction. Phishing is still a hard problem. This will take a long time.
Can’t mention scripting without a proper command-line client. Planned are two client binaries, one REPL based one to manage passwords from inside a terminal (likely going to work like my old yspave proof-of-concept, but with Go/libsodium rather than Python/scrypt), and another for backend management, for handling users, groups, and the rest.
Apart from satisfying my inner nerd, this feature will make automated provisioning of new users, or whole new PAVE installations a lot faster and smoother.
Additional key server authentication backends
The key server API is deliberately designed to be trivial enough to allow customers to write their own backends if needed, but a few more standard backends will likely materialize over the coming months, and will be added as necessary
PAVE is not as fast and robust as it could be – there’s always one more improvement to do. Synchronization performance will be explored in the near future; for now we use exceedingly dumb sync algorithms (always sync all passwords, even if they haven’t changed in years), as we focus on other areas.
The key server will also see some more love to improve security; making it less of a single point of failure. We still recommend against using it unless you have no other option.
Related to the key server headaches, it would be nice if we had more secure storage options for our private keys. Few hardware tokens support ed25519 natively already, but devices like YubiKey thankfully allow storing arbitrary binary data, which we will likely utilize to implement HSM support until proper ed25519 support materializes.
A generic framework will be implemented shortly, and used to provide two simple importers: Encrypted PAVE dumps (to upgrade from Free PAVE to Team PAVE and to move data between Team installations), as well as a generic CSV importer.
More importers will be added as needed, to allow easier migration for new customers.
(Insert your feature here)
As you might have noticed from the lack of hard dates, the road map is far from finalized. We’re open for suggestions and criticism: if you think something important is missing, please contact us!