On Thu, Feb 14, 2019 at 12:32 AM Rich Freeman <ri...@gentoo.org> wrote: > > > On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote: > > > > > >> My own solution is actually very simple. I have a "secret algorithm" > > >> that incorporates several secrets with a predictable way to generate a > > >> site-specific secret. The end result is a 100% predictable way to > > >> generate unique passwords for every site that are cryptographically > > >> secure from each other (you cannot derive > > >> one from the other) which can be generated by any device using the > > >> appropriate tools. > I just stumbled on lesspass which seems to be such a tool for > algorithmic password generation (lesspass.com).
Great tool. Good to know there are those that think alike. One important point though is that in my "version", the user has to completely know a secure algorithm (which is where all the security comes from), with a managed tool this is only feasible for technical users (or at least technical past a certain level). A version of lesspass that allows users to view and customize the secret-generation algorithm would be much more secure. Or another way to put it might be: if an attacker knows that you're using lesspass, then the only encryption they have to break is that on your master password, so your security is only as strong as your master password. On the other hand, if an attacker knows that I am using an algorithm-generating technique, they need to break both the master secret AND the algorithm, which could have vastly more entropy than the master secret itself. > > Some thoughts regarding this approach: > > 1. Remembering the right "site name" for every site might be tricky - > sites change names/URLs and you won't have any database to search. In my personal practice, not a problem. In practice you always remember the old site name for any common enough site. If you don't, you reset the password to the new site name. > 2. The solution does allow incremental counters for sites, but of > course that is basically state and it looks like they have a way to > sync this somewhere, but of course that means having a cloud sync > infrastructure and that info could get compromised (doesn't include > the passwords themselves). Also not an issue for me in practice. In practice you also remembr which sites forced you to change passwords, since they're pretty much the only ones in that class. > 3. Master password complexity probably matters more than for > something like Lastpass/KeepassX. With traditional password managers > you need the database plus you need to crack the master password (or > get it some other way). With a purely algorithmic approach you can > probably guess at all the parameters other than the master password, > so anybody can try to crack you without stealing any data at all, This is an issue for lesspass, because the only secret is the master password. This is not an issue for algorithmic approaches in general, because the algorithm is part of the secret. Every which way that you choose to encode the intermediary steps in my example above is also part of the secret, because none of those can be guessed from the resulting password. As an example, encoding "madum...@gmail.com" as the site-specific identifier would give a completely different password than "gmail:madumlao" or "madumlao@gmail" or "madumlao+gmail", etc. And that hasn't yet counted any peppering which influences intermediary hashes. That being said, any system that depends on a master password had better be goddamned secure. In fact, my email account - which is a resetting point for basically all services - is exempt from my password algorithm and uses some ridiculously long secret. Likewise, your keepass / lesspass secrets should probably be some insane paranoid level secret that themselves don't come from keepass / lesspass and their alternatives. > 4. I'm not sure how straightforward it would be to change > passwords/etc. If you have 100 sites, you'd have to remember what > password you used for what site, or change them all at once. Again, > the stateless approach has its downsides as passwords are not > stateless from the standpoint of the remote sites. Actually the generation approach is massively simpler since the passwords themselves don't matter. If you don't like your secret, are not sure which iteration a site is, are not sure if a site used an old or new secret, etc, you can trigger a password reset on most services and force it to use the current generated password. You can update any passwords on an as-needed basis to always use the current generated iteration. > If you do increment passwords, well, now you just introduced state > back in, and the "stateless" solution isn't really so. > > Password incrementing is an issue for any algorithmic solution - you > need to be able to remember which password version is in use on what > site. If you're talking about remembering the iteration counter for a particular site, well, yes you have to store state somewhere. But consider: 1 very strong secret + remember that these 3 or 4 sites are on iteration X is a LOT less headspace than 4+ independent strong secrets and I'm pretty sure most people have logins on more than 4 sites. If literally the only state you need to know about a site is the Nth iteration, I wouldn't mind cloud providers knowing that because they can't do anything about that number.
