On Thu, Feb 14, 2019 at 3:18 AM Rich Freeman <ri...@gentoo.org> wrote: > > On Wed, Feb 13, 2019 at 12:12 PM Mark David Dumlao <madum...@gmail.com> wrote: > > > > On Thu, Feb 14, 2019 at 12:32 AM Rich Freeman <ri...@gentoo.org> wrote: > > > 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. > > Maybe. Here is the problem with this: > > If you just give the user a choice of one of several secure algorithms > to use, then basically all you're doing is adding a few more bits of > entropy to the mix. You also have to deal with vulnerabilities in any > algorithm your software uses, and not just the one you picked. > > If you instead let the user code their own algorithm, then while this > increases complexity, it also makes it easy for users to shoot > themselves in the feet with an insecure algorithm. > > I think it would make more sense for users to focus on more robust > master keys than to rely on security by obscurity with an algorithm > that doesn't benefit from peer review.
Changing (or rather customizing) algorithms is not security by obscurity. While it may be true that at the end of the day you're adding bits of entropy, the fact is the freeform nature of design implies the number of bits of entropy you are adding could very easily exceed any humane password. And on second point, you can completely automate simply running lesspass, whereas to automate cracking an unknown algorithm you would have to automate writing arbitrary programs, which is in theory reducible to the halting problem. TLDR: you probably can't. > While any master password should be secure, the algorithmic approaches > suffer more, IMO. With something like Keepass or Lastpass you need > both the database and the master password to do an attack. Now, with > lastpass anybody with the master password can obtain the database from > the cloud, but they're going to throttle attacks or lock the account > after so many failures, and you have nothing to crack offline. > Lastpass would be vulnerable to intruders stealing the database of > course, which then reduces the difficulty of an attack to the same as > something like Lesspass. That's technically correct, which is why I would suggest a custom-designed algorithm as opposed to something like lesspass. With lesspass all the security directly goes to your secret, so the pressure to make the secret ridiculous is huge. With your own algorithm, the algorithm itself adds entropy between your secret and the generated password. Consider: - to crack a lesspass secret, you can bruteforce the lesspass secret and check if they produce a valid output. On any success, you're 99.99x% certain to have cracked the original lesspass secret, which will instantly work on other sites. - to crack an arbitrary algorithm, it is insufficient to bruteforce an input secret because by itsef it does not produce an output secret. You would also have to bruteforce different transformation algorithms that map from the input secret to the output secret. Even if you end up producing a valid password, you cannot guarantee that thje guessed algorithm works on other accounts, because it might simply be a collision, which is indistinguishable from the algorithm being wrong due to missing some site-specific rules. > > > > > > 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. > > The problem with "as-needed" is that you have to remember which > accounts use which master password. That sounds simple until you have > 100 different accounts. The point of an approach like this is to reduce the number of secrets, ideally, to only a handful, in practice only to one. Thus you don't need to remember which account uses which master password because just like keepass there is just one. I have over 100 different accounts (software testing) and I can say it's very simple, at least no different than using something like keepass. In the algorithmic approach, you don't have to change your master password per iteration. Your algorithm can take iterations into account to use the same secret to generate an Nth iteration. For instance, using iteration numbers as part of a site-specific ID.
