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".
> Nothing is stored so there’s nothing to steal.
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.
r=1, p=1, N=2048, dkLen=32
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.
KeePass has been a huge influence.
Not everything can be handled by attaching LDAP.
Active Directory makes it easy to authorize/authenticate so surely that would be a good thing.
Logging into the Company Bankaccount with LDAP would be nice.
I've used it for a while, and haven't heard either way. The Android app has good Dropbox integration, which really streamlines mobile password use.
The fact that it is offline, open-source, and (on Windows) uses the standard Win crypto libraries gives it an advantage over Lastpass or 1Password.
Here's a thread 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. 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 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; it applies to KeePass v1.17, so should not be a concern anymore.
I will continue to use KeePass2.
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.
> 2. Nothing is stored so there’s nothing to steal
> 4. No need to sync data, as there’s nothing to sync!
If there's only one possible password for a given website, and every password is stateless, how do you change the password if it's compromised?
bytestring = hash(master_password + url_domain + random_salt + persona)
password = translate(
bytestring, alphanumeric +
storage[(url_domain, persona)] = (
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.
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.
Don't roll your own crypto, kids.
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".
1) SuperGenPass - http://www.supergenpass.com/
2) Vault - https://github.com/jcoglan/vault
3) Hashpass - https://www.stephanboyer.com/post/101/hashpass-a-stateless-p...
(Disclaimer: I made #3)
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.
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.
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.
Visionary being a Python script I think makes it less portable, harder to use for average users, and definitely not mobile-device friendly.
Source code & threat model:
It has an Android, Python and JS implementation.
doesn't have easy typing but is more popular