From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DBCF1138334 for ; Wed, 13 Feb 2019 16:31:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73347E094F; Wed, 13 Feb 2019 16:31:45 +0000 (UTC) Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EF38FE0932 for ; Wed, 13 Feb 2019 16:31:44 +0000 (UTC) Received: by mail-pf1-f194.google.com with SMTP id q1so1373689pfi.5 for ; Wed, 13 Feb 2019 08:31:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qgXZGXAWu5Z57VShp+s8Ly0WjWGxq+EACVvnZc4ufCs=; b=eHvTC64R0GNfjrqLTjrwwPRZ6VjxSIEDlaeh2zSkEID5YBICtJtpkn+WCNYGA6D/no p3UwBO78+OyMwNBJ7RYNa1iRB5Q8L5eia9SA9zl+UJ6RoIM0r6atdJMExBPwc+3vcziF CGjs8r7sitHJ1bZd1t5K8gfWGh3NhBpER3FIh3B5EXt/Oo19Rz3qNwq3ae8KrcdmbvqF 3XlTi3LO4iXiq2AtrUdKTJTFOqjao6YORzEN8IHw5ogg8RreU0RcBL2LIPTi0AexZA/Z Ci1e5UyTvwsQl64ymkfPkQu4T6w05klqf1scSzkmRR5zRwsA3awdArIaVtZJDFFufhK1 HQlw== X-Gm-Message-State: AHQUAubxw8DrzEVzUFKevjGrXzsp3ZmAOLWgpxzOFkpXnTlVWs6W8M55 KWRwjXtJLnIRSVyO/FccBqExqfl+3rq9ytFoc6Wrrw== X-Google-Smtp-Source: AHgI3IYDBvq1V5yeFIBeg5q/H4tsZUuJxtSYL4E39QcXz8nQ9nBdj8wvCkOqWylb+1sACB10nZfyLDkA4771oIs1vL8= X-Received: by 2002:a63:e84c:: with SMTP id a12mr1180542pgk.241.1550075503225; Wed, 13 Feb 2019 08:31:43 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <8d027455-f210-c399-f5a7-bfb05692cc5f@gmail.com> <4T37M4RU.7P6POHFW.VWXHN7BS@VBETV3G5.Q4J4WRJ3.XBFRTPM4> <20190205211653.57d0b0dc@digimed.co.uk> In-Reply-To: From: Rich Freeman Date: Wed, 13 Feb 2019 11:31:31 -0500 Message-ID: Subject: Re: [gentoo-user] Re: Coming up with a password that is very strong. To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: f865bb8a-4fb8-44f1-beff-b384cb5d5a2d X-Archives-Hash: 51684ddfedb55d0a883fe20779bb8ab9 On Fri, Feb 8, 2019 at 9:26 AM Kai Peter wrote: > > On 2019-02-05 22:17, Neil Bothwick 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. > > > > The was a tool in portage this did this. I tried it but it did not work > > in the real world because you couldn't set a rule for generated > > passwords > > that matched the requirements of all sites, for example some require a > > non-alphanumeric character while other sites only allow alphanumerics. > > > > I can remember what the tools was called, although I'm pretty sure it > > was written in Python. I'd be interested to know how you get around the > > conflicting restrictions as this seems a good way to do things. > > By using an existing tool you have to live with its restrictions always. > But who says that it could not be done? At least Mark's solution will > (maybe) not work for everybody (yet), but he did think about an issue > and found a way/solution which sounds really reasonable. > I just stumbled on lesspass which seems to be such a tool for algorithmic password generation (lesspass.com). 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. 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). 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, assuming they think you're using the algorithm. It sounds like the hashing system they're using is considered secure, but it is obviously only as good as the master password. 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. The big upside to stateless is that if you never increment passwords then as long as you remember your master password you always have access to your password everywhere, with nothing to back up. 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. -- Rich