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. > > 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. Sure, assuming you don't regularly change your passwords everywhere. I'm not sure that this is as important with manager-generated passwords, but it is a consideration. > Likewise, > your keepass / lesspass secrets should probably be some insane > paranoid level secret that themselves don't come from keepass / > lesspass and their alternatives. 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. > > > 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. My password manager has a huge number of accounts in it. Granted, some of those are more disposable than others, but keep in mind that everything from the local burger chain to your bank has a password these days. Either that, or it supports something even worse like Facebook authentication. I'm all for SSO, but not ones locked into a single provider, and especially not Facebook. > > 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 Sure, but I'm mostly comparing altorithmic password managers to database-based ones. In neither case are you remembering hundreds of passwords. > > 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. > It still means having a need to sync state, that was my main point. If it were truly stateless you wouldn't need any kind of cloud sync at all, and I think most would agree that would be an objective benefit. However, here we still have the need to maintain a cloud account, have devices that sync to it, and a need to keep that data backed up less that cloud provider shut down without warning. I think we're mostly on the same page though. -- Rich
