I think it's more a password manager that doesn't manage passwords.
You can't set an expiry date on a password. You can't change a password if it's compromised. You don't know when a master password was created so you can change it. If you change your master password you have to change every password you care about. You can't introduce new entropy. You have to manually specify a keyword scheme (and presumably store it yourself). You can't store metadata in case the website decides it's changed from usernames to email addresses and you've forgotten which one you used for what. You can't change the master password independently of the individual passwords.
In actual password management, this program makes you specify, store and organize it all yourself. And without significantly more security than a traditional password manager like Keepass.
And it can't accommodate websites having weird password requirements. Some websites require symbols and some have maximum number of characters. Fixing this would probably require special characters in the keyword which would force you to remember the website's original password requirements on top of the keyword itself.
Very good point! Since some websites still require PIN codes (passwords made of digits), you would have to restrict yourself to something like 8 digit long password, which is not very secure, even with a slow hash (scrypt iteration).
Nothing is stored, but it's public knowledge. In a traditional password store, there are two levels of security: limited access to the encrypted passwords, and encryption itself. With their approach, there is only one level: encryption.
The counterpoint would be this:
> There are thousands of iterations of Scrypt, making brute-forcing infeasible.
But this is trivial to do with a conventional password store.
As you said, password expiration is in contradiction with the last point:
> No need to sync data, as there’s nothing to sync! You can use this script or our API (coming soon) from anywhere in the world, and from any device, to generate your passwords.
I've used this kind of thing (supergenpass) for years, but in the end the inflexibility got me. A word to the wise: Just use KeePass2. It's a fantastic piece of software, works with Chrome/Firefox (with extensions), has KeePass2Android, a fantastic Android app, and is completely free. Just do yourself a favor.
Been a huge fan of KeePass for years and recommend it to anyone that listens.
I created EnterPass (https://enterpass.co) based on the flexibility, simplicity and security of KeePass.
It's for companies to manage passwords across teams and want to keep the passwords stored inside their own networks... not on the cloud. Oh, and you don't need to remember a master password to use it as it uses Active Directory for permissions.
I don't quite understand the need. We used KeePass on the network where I worked previously. The kdb file was simply stored on the network. We had a few of those for various level of access. You did have to remember those few master passwords for for the files you had access to, but it gave another level of flexibility by not being tied to AD.
I can see why you are being downvoted, but this is a huge problem so many organizations face that i'm getting mad that there's no "just use x" solution when you need Keepass for organizations, with sharing, access groups etc.
Agreed, hence the reason I built my own but as for LDAP, it's used for access to a gazillion things in the network already, e.g. file shares, applications, internet access and so on that surely using it to authorise access to one more resource, passwords in this case, makes sense.
Active Directory makes it easy to authorize/authenticate so surely that would be a good thing.
Oh sorry, i didn't mean to say that attaching it is wrong, i meant that you can't attach it to every piece of Software/Web-App which would indeed be nice.
Logging into the Company Bankaccount with LDAP would be nice.
This reply was sufficiently aggravating to make me go do some research.
Here's a thread[0] from last year bringing up some issues with KeePass2 code. It also links to an audit by some group that appears to be involved in information security for the French government[1]. It's in French. The HN comment asserts the audit found KeePass2 2.10 portable to be safe; I don't comprehend French so I don't know what the audit says.
The documentation[2] specifies that the default KDF uses 6000 rounds of AES, although that is configurable, so presumably 'hahaha...extremely fast cracking speeds' could be improved to 'fast cracking speeds' or even 'moderate to slow cracking speeds'.
KeePass has had one published vulnerability[3]; it applies to KeePass v1.17, so should not be a concern anymore.
The number of rounds used in the key derivation function can be configured per keepass file in the "database settings". I increased it until it took a second or two on my slowest device (i.e. phone), which turned out to be 6 million rounds.
If the keepass docs are up to date, the default for the desktop application is only 6000 rounds which I feel is too low.
I've noticed that the Keepass2Android app uses a 500K default instead.
The advantage is that it's safer than password managers that store your passwords or require you to send your password over the internet, and it's more flexible than managers that do not store any information.
The problem is that you need to copy your database file to each device you use , that can be specially frustrating when I need to use android, for instance.
This strikes me as less secure then a password manager that stores passwords. Here, if someone gets my master password all is lost. With stored passwords, they'd have to get both my master password and the encrypted passwords.
It also lacks what you might call 'forward secrecy'. If someone gets access to my master password and an old 1password backup, then they get all the passwords in the backup.
But with this, if someone gets access to my master password, they get access to recent passwords, and when I create new passwords they get access to those too. If I'm not aware that my master password has been compromised (why should I be?) then I'd be merrily creating new passwords that are compromised at the moment of their creation.
> Here, if someone gets my master password all is lost.
Not true. They'd need to know your keywords, which don't necessarily have to be "github" or "facebook" -- e.g., you could choose a consistent pattern, yielding "git##hub" and "face##book".
One suggestion for improvement for the OP: make this a browser extension. Probably more convenient than switching to a terminal whenever you want to log into something.
These types of deterministic password generators usually have an issue with inflexibility - you can't change the generated password for a site without modifying the input parameters.
I believe a good approach to this problem would be having some sort of online Bloom filter API where you could submit a hash of your input parameters and then query to see if the password has been "burnt". You'd be able to mark a generated password as "discarded", at which point the input params would be hashed using a different algorithm and added to the Bloom filter. Next time you use the frontend, the front end could perform the next iteration of hashing if the result was found in the Bloom filter.
I have one of my own design where this problem is solved by just having a "version" field in the hashed data. Bump it and the password changes, and you still have the ability to retrieve old passwords. I have been waiting for one of the good ones to incorporate this idea so I don't have to finish mine. ;)
Edit: and I might as well mention my other feature that I haven't seen elsewhere, which is that the hashed data isn't used as the password directly, but rather is input to a transformation function which can take into consideration different password rules for different sites. This way if a site has a dumb rule like no exclamation points or an 8 character limit, I can still use my generator to manage the passwords, just with a lame final transform that limits the password space in the appropriate way.
One Shall Pass which I use exclusively has a parameter which specifies the number of generations to run its algorithm. So you use your same input and same passphrase and just change the generation.
In terms of security, this doesn't improve anything (all security hinges on the master password). In terms of flexibility, this is a lot worse than a secure password manager.
I've seen many implementations of this exact thing, the basic ones are just sha1 or sha2(master + website domain) which generates a unique "password" for each site. This is just another implementation of the same idea. I've seen a few releases of simple scripts that do this for you as well, some work as bookmarklets, browser extensions, or single-page app websites.
Visionary being a Python script I think makes it less portable, harder to use for average users, and definitely not mobile-device friendly.
Can anyone comment as to how this differs from something like http://passwordmaker.org? I've used that for quite a while, but it seems to have little support these days and I would consider moving on.
You can't set an expiry date on a password. You can't change a password if it's compromised. You don't know when a master password was created so you can change it. If you change your master password you have to change every password you care about. You can't introduce new entropy. You have to manually specify a keyword scheme (and presumably store it yourself). You can't store metadata in case the website decides it's changed from usernames to email addresses and you've forgotten which one you used for what. You can't change the master password independently of the individual passwords.
In actual password management, this program makes you specify, store and organize it all yourself. And without significantly more security than a traditional password manager like Keepass.
It seems a bit cocky to call it "Visionary".