First of all, this looks like an awesome and very well-thought-out implementation, and I'm sure it'll work well for some people!
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.
Great summary! I've been using Master Password for a few months now and I'm generally happy with it. However, the points you mention pretty much force me to have a KeePass file for "those other passwords".
I have used this mechanism manually with a simple algorithm and a secret key + site name for a while... And all of the things you mention are exactly on point :)
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.
Curious, have you used pass on Windows or Android? I'm thinking about getting a YubiKey Neo and switching from KeePass to pass since then I can use a second factor as my GPG key.
I haven't tried pass on Windows or Android, but I did write an (over-complicated, but it was partly for fun and I wanted to play with clojure/clojurescript) webserver exposing pass from a VPS:
A few times I've used `pass | nc -l $SOME_PORT` and then navigated to my hostname:$SOME_PORT with my mobile browser (over some secure network of course).
It's not the best solution but it works for the rare occasion I need to authenticate an app.
It is important to note that there is a security flaw in this scheme that makes it strictly less secure than using a password manager with randomly generated passwords. All an adversary needs in order to generate all of your passwords is your master password. Let's walk through the steps of how an adversary can brute force your master password.
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:
> I wonder why it hasn't received wider attention since being released a year or so ago?
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.
Nice! The interface looks very nicely done. I like that you thought about syncing too. Except personally I don't like storing things on Dropbox but I guess it's just metadata too.
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.
I also had the same idea a while back except that I didn't have perspiration likes you guys: congrats to you and masterpasswordapp.com for going all the way!
That's exactly the depressing part I was talking about. It's a fantastic project, which is now open-source, but there doesn't seem to be anyone who would take over and support it longer term. Even though I believe there's a viable business there as well (As an end-user in a small company, we'd be happy to pay a monthly subscription for it, equivalent to or even higher than what we'd pay other solutions out there, e.g. lastpass).
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.
Does EFF or other non-profit organizations act as security nets for open source products and ensure that the software they endorse remains available to everybody?
Curious as to how PasswordMaker either uses weak crypto or "suffers from critical flaws". Master Password seems to be more flexible with features like password counter and a customizable password policy (this is especially cool if it is customizable per domain). Unfortunately for me iOS-only is a deal breaker. PasswordMaker has clients that run on everything. The two I use most are the "PasswordMaker Pro" Chrome extension and the PasswordMaker X Android app.
Hey, thanks for linking to my PasswordMaker app! :) I saw this linked on /r/programming earlier and mentioned it there.
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.
Yeah, SuperGenPass has great integration too. You can run it almost anywhere, though you have to have some faith (there were proof of concepts against the earlier bookmarklet version, though I believe they've been mitigated by using an iframe approach now, but you're still running crypto in the browser–I probably wouldn't use it for anything genuinely sensitive).
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'm using only mobile version which is a standalone page. I memorized the icon generated for my master password so I can spot if I made a mistake whilst typing.
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.
> 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.
Still don't get it. Knowing that I use SGP gives attacker nothing. On each guess of master password attacker has to generate pass (quick, using hash) and then GO to website and try to login. And this is very slow compared to hash generation using bcrypt, SHA1 or even md5.
That's assuming every website you use with one of these passwords is secure. In practice sites get hacked, fail to enforce HTTPS, databases get leaked, etc.
> In practice sites get hacked, fail to enforce HTTPS, databases get leaked, etc.
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.
This is a pretty neat concept. I'm not sure if this is what its doing but it seems like it.
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.
Master Password works very differently from 1Password, KeePass, LastPass, etc:
"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."
LastPass is definitely different, as it stores data on a server.
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.
Ok, I get it - it doesn't retrieve anything. It basically hashes you a password using what is public and a secret (your password). I need to see if it's possible to change your password on a per site basis - it seems that would require changing globally (since you'll need to update the secret)
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).
> 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)
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..
Of course that introduces a vault and presumably a need to sync if you want to access that password from multiple computers or mobile devices.
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.
Great idea, but a total geek product. In terms of actual market success, that is, getting security to average people this is never going to work. Not only is there all kinds of language on the site that regular folk aren't interested in (text encodings, hashes, etc.), the very idea of having to remember a "password counter" is far too difficult for anyone. I've got hundreds of passwords (in a password app), and once even a quarter of those are incremented past 1 in the counter it's just a massive guessing game at that point.
Great idea! And kudos for releasing it as free software.
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.
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
For low-security situations it looks good enough, but be aware that generating a password from full name + a memorable passphrase + site name + a counter is still pretty brute-forceable; the counter is presumably small (and hence adds little entropy), and American full names just add three fairly well-constrained words.
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?
What if I need to change the password for a particular website (for example because it has been compromised and all its users were encouraged to change their password)?
I believe that this product has a "version" number for each site. So, the first password you create for twitter.com has a version of 0. If/when those accounts get compromised, you create a new password for twitter.com with a version of 1. The downside is that now you have to keep version numbers for each site somewhere, or change all of your passwords for everything. :(
Yes, the website is misleading when it states that "Master Password is based on a stateless algorithm which frees it from the reliance on storage of secrets", which is clearly not true. When you rely on people's brain for storage, not only it's not stateless, but you've just chosen quite an unreliable form of storage.
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.
I don't know if it is a good idea or not,but you could change the web url just a little so that the password will be different.
For example twitter.com could be twotter.com.
You know it's still twitter of course,but you'd have a new password.
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.
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.