Master Password
ssl.masterpasswordapp.com
ssl.masterpasswordapp.com
That said, I actually made something very similar to this a while back. Now I use pass instead: http://www.passwordstore.org/
The downsides I didn't think about, or didn't think would be as annoying as they were, until I started running into them in actual use:
- The big one: change your master password? You now have to change all of your passwords for every service you use.
- Weird restrictions on password length or allowed characters? Okay, the app gives you options to generate a password with the required parameters, perfect! When you actually use this you realize that that set of parameters is a state that must be stored somewhere. Possibly your brain ("okay, when I log into gmail, I select 'phrase', but logging into Bank of America I have to use 'long'... or was it 'medium'?). This does not scale.
- Need to change a password for a specific service? Again--this has a "site counter", that works... except now there's more state, and you need to remember to use "2" with "gmail" and "5" with "hn" and...
Of course, you could (and, didn't download to try, but it's possible the app does?) store those restrictions/site counters somewhere, but now you've lost the main benefit of doing this in the first place (stateless, nothing to sync). In the end, I decided that gpg encryption is secure enough for me.
My solution has been to have 3 different techniques:
- a very sofisticated master password + algorithm for very critical things - a secondary, less sofisticated for less important things - a dummy password that i use for silly stuff
I keep an up to date list of applications of the second tier. The first tier is easy enough to remember since it's the critical apps.
I also go with 2fa when I can.
https://github.com/johnswanson/pass-server
I shut down the Linode it was on a while back and haven't gotten around to putting it back up yet, but it worked pretty well for me.
It's not the best solution but it works for the rare occasion I need to authenticate an app.
First, they will need access to a hash of one of the passwords you have generated. Say you use this application for every site you visit, and you have somewhere between 20-30 accounts. If only one of these companies suffers from a password leak, then the adversary will have enough information necessary to brute force your master password and generate your password for all other sites. This means that the sketchy site you created an account on to buy a phone case can result in an adversary gaining your well-protected bank password.
Once they have a password hash, they can brute force your master password in the regular way. All other inputs to password generation function are easily obtainable through minimal social engineering or guessing (your name, the site name, number of re-generations). I will note here that they did use scrypt, which makes brute-forcing more difficult (but not impossible). So, if you use a weak master password, not only is your password for the vulnerable site brute forceable, but all other sites you use in the present and the future will be compromised.
This scheme is not more secure than existing password management schemes (provided the password manager uses a good hashing algorithm for the master password like PBKDF2). It is strictly less secure because the security of all your passwords relies on the minimum security of all sites you use. It is also less secure because after a leak, an adversary can generate future passwords.
This tool should be used with caution and with these facts in mind.
"Master Password is a stateless password generator. It doesn't store, collect or transmit any secrets. It makes them ubiquitously available, on-demand, depends on nothing but your private master password, and is fully open source."
I wonder why it hasn't received wider attention since being released a year or so ago? The only real mention I found in a cursory search (outside of app store reviews) was here:
"Are you using the same password everywhere? If so, change it, starting with your email account. Use a tool like MasterPassword or write it down."
I've seen a few people start developing this general kind of password system for their personal use, but they usually end up giving up after running into a few problems that make them realize that there are some annoying issues involved. That's what happened when I started doing one a few years ago, when I was trying to make something a bit more convenient than the classic encrypted text file full of passwords that I was using.
I took a similar approach, using a master password, something that should be per site (domain name), and a password version number as input to a key derivation function to get the password for the site.
That's where the first problem showed up. Where should I store the password version number? I didn't want to have to memorize what version password I was on for every site, so I'd need to keep it in a file somewhere, which I'd need to share between all my computers. (This was before I had any mobile internet devices, so I was only concerned with desktops).
And then I realized I needed storage for more than just the password version number, because I remembered all those idiotic password restrictions that so many sites like to use. Things would be a lot nicer if sites would just at least come up with a common format that they all accept in addition to whatever else they accept, such as 32 to 64 characters in [a-z0-9]. Then everyone using a password manager or password generator could use that format, and we'd all be happy.
But they didn't, so that means I'd need to store and sync some kind of formatting information for sites that cannot accept whatever my default generator format is. So, add that to the file that is storing the version numbers for each site that is past version 0.
And then I realized another issue. I have passwords I want to store that were imposed from outside. For instance I have a password share for the key to an encrypted database at work, made via Shamir secret sharing. I want my password management system to hold it for me, but not to generate it.
This could be dealt with. I could have had the password management system generate a password, and use that to encrypt my Shamir shared secret. Then I'd have to store that encrypted file somewhere that syncs to all my machines. It might make the most sense to build support for this into the password manager, providing a general "store a secret string" function, where it handles encrypting it and then stores it in the same place it is storing password version numbers and site-specific password formatting templates.
At that point, 1Password showed up in a MacHeist bundle, I gave it a try, and very shortly afterwards abandoned my password generator/manager development.
Master Password says it has password versions, password format templates to deal with idiotic sites, and storing imported password in the app encrypted using a generated password. What I did not see (I may have missed it) is an explanation of how this works if I have more than one device.
Quite simply, you can't. There is no syncing mechanism so whatever you store is local to that device only.
https://cassidy.nicinabox.com https://github.com/nicinabox/cassidy
I haven't heard of vault, so I looked into it. It looks like it uses CryptoJS with 8 iterations on PBKDF2.
I wrote hash0[1], which is the same sort of master password + salt + site but syncs encrypted metadata with server of your choice.
I found that while working on hash0, that SJCL's[2] PBKDF2 is faster than CryptoJS's implementation, which means I can perform more iterations faster and get the same result. I switched from CryptoJS to SJCL, and have hash0 do 100,000 iterations instead of vault's 8.
[1]: https://github.com/dannysu/hash0
[2]: http://crypto.stanford.edu/sjcl/I didn't go past proof-of-concept: https://github.com/ixio/e64-bcrypt
However, I can't help but feel a bit depressed by the state of even some of the most common projects, like GPG[0].
Another one that I truly fell in love with its simplicity and beauty -- Mitro[1] -- seems to be dying a slow death[2].
I know it shouldn't reflect on this project, and can only wish for its long-term success.
[0] https://news.ycombinator.com/item?id=9003791 [1] https://www.mitro.co [2] https://github.com/mitro-co/mitro/issues/123
Sadly, the service might shut down before the end of 2015 because of time/money problems [3].
[0] https://twitter.com/MitroCo/status/494891941352730624
[1] https://twitter.com/TwitterEng/status/494895829556002816
It's fair to tell me "then why don't you contribute / do something instead of complaining?", but as much as I'd like to, it's got lots of moving parts and needs significant time and lots of different skills, or some form of backing to pay for those. Even if it can be turned into a solid business, it will still require resources to support - not just the technology, but marketing etc. So far, I haven't seen anybody picking this up, but I really hope someone will. It will be a great loss to see it die.
There is an official C, Java, iOS, Android and Mac implementation. You can run an official app on most any platform.
There have been contributions and third-party solutions for JavaScript, Windows and Android.
I'm not sure how the password counter and "customizable password policy" (I'm assuming this refers to the password templating feature?) make Master Password more flexible, though. PasswordMaker offers plenty of configuration options you can tweak when you want to change the password for a site; I've begun creating multiple profiles as sites varying in their password requirements. I use the Chrome extension you linked to, as well, which auto-selects the profile based on the URL I'm browsing.
[SuperGenPass]: https://chriszarate.github.io/supergenpass/
Other 'problem' is that it uses a fast hash function. There was a fork going round that used bcrypt I think, I'm not sure what happened to that.
I also use salted master password for each site, so I'm feeling safe at this.
Regarding "quick hash" or "slow bcrypt" - it doesn't matter here. Bcrypt complexity is to prevent obtaining real password from it's hash. Here we're dealing with real passwords but not hashes.
It does matter. If a website knows that you use SuperGenPass, they can conceivably guess your master password if it's weak as a direct result of SuperGenPass using a fast hash function to generate the site-specific password.
In a scheme like this, the "real password" is the output of a hash function (albeit munged a little bit), so choice of hash function is important. I'm not a cryptographer, but really a key-derivation function seems like it would be a lot more appropriate here than a simple hash like MD5.
Exactly. The threat here is that a single SuperGenPass-generated site-specific is leaked somehow (if you use it for a lot of sites, one of them is bound to be storing a password in plaintext, or not using https, or whatever–or, for all I know, the OP is such an important target maybe someone specifically sets up a website to capture a sample site-specific password). Then, using that site-specific password, a determined attacker might be able to recover your master password and then be able to login to all the other websites you use SuperGenPass with. That's the danger of using a 'fast' hash function to generate your site-specific password.
It seems your master password is like a seed for the encryption or something so that's why it can always be the same. If thats pretty much what it is its pretty smart and simple.
I also like the option for the account clues.
"Master Password is a stateless password generator. It doesn't store, collect or transmit any secrets. It makes them ubiquitously available, on-demand, depends on nothing but your private master password, and is fully open source."
KeePass and 1Password, as I understand, use your master key to decrypt a file (local or in a cloud provider like Dropbox) that contains your password(s).
Master Password may be different than this - I don't understand how you can retrieve passwords without storing them, but I'm sure it'll become clear by researching it. I do want to be clear that 1Password isn't a central repository like LastPass, however.
(edit: I think I understand MP better, see below)
> The site's password counter (default: 0): This is an integer that can be incremented when the user needs a new password for the site.
So it looks like you can generate new passwords anytime you want on a per site basis.
Several of the design goals for this app were to eliminate the need for sync, as you're able to fairly easily replicate the initial seeds/salts for password generation (your full name, your master password, and the site base domain).
I'm not really seeing any pros using this solution...
Con 1: You can't use any password you want (for whatever reason, be it stupid password security requirements, your boss gave you a password to use, you're not allowed to change something, the list goes on) Con 2: They focus on not requiring sync, and concessions were made for this (a bunch of defaults, as well as con 1 from above) when they really actually do require sync. The password counter and password type (strong, weak, etc) both need to be synced to actually derive a password.
If we're going to have to sync these to reliably store our passwords, then why not just go with an actual password manager without any of these arbitrary limitations?
I've been using 1Password and its been working out great for me. (Arguments may be made about its closed source, but KeepassX functions in a similar manner).
It does cover that:
My boss gave me this password to use...
Master Password's generated passwords only work if
you use the password generated for you. You cannot
use a password somebody else gave you.
Only - you can: Master Password implements a hybrid
solution, allowing you to save custom passwords in the
app. They are AES encrypted with your master key, but
like all vault-based password managers, are not immune
to loss if you ever lose your phone and backups..
Downsides:
- single point of developer failure (although open source, and specification-based)
- lack of browser integration
https://github.com/chriszarate/supergenpass/wiki/FAQ
which credits my site
http://angel.net/~nic/passwd.current.html
as "the original bookmarklet password generator". It adds some useful features, but loses the simplicity and transparency and real statelessness of a self-contained HTML/JavaScript form - and is less convenient for most uses than a bookmarklet.
But I don't see how "nothing to intercept" is a security feature. That means an attacker can start brute forcing just knowing the victims name instead of having to obtain the encrypted files first.
Quote:
The master key is a 64-byte secret key generated by performing expensive key derivation using the user's master password salted by their full name. It represents the user's global secret.
The purpose of this process is to deter any attempts at brute-forcing a user's master password from a known site password. The key derivation is done using the scrypt algorithm, which guarantees that the process sufficiently time- and resource-consuming to make brute-forcing an infeasible attack.
The key derivation is salted by the user's full name to prevent the generation of rainbow tables on the algorithm. This salt is not secret, and the user's full name is chosen because it is an input of sufficiently high entropy while being (hopefully) impossible to forget by the user
But, can you auto fill / paste the password? The UX for a phone is painful usually - downloading it so we shall see
Also, isn't the counter a bit of state? Is the idea that the user has to remember it, or does the app remember it for him?
There's also the issue of the master password being compromised, which would requires users to change all their passwords on all their websites.
I'm surprised these "stateless" password managers keep being made. Either the creators really didn't notice the huge drawbacks, or they did but still want to get their software out.
Show HN is meant for projects one has created themselves. This is not my project and I didn't read that guideline last night when I submitted. It's an interesting project that I stumbled upon last night and started using. I thought I'd "show (it to) HN".
Happy for a mod to edit the title. My sincerest apologies to the author and the HN community for my haste and any misunderstanding.