Jeffrey Walton <noloa...@gmail.com> wrote on 20/03/2024 at 18:30:34+0100:
> On Wed, Mar 20, 2024 at 12:51 PM Pierre-Elliott Bécue <p...@debian.org> wrote: >> >> Jeffrey Walton <noloa...@gmail.com> wrote on 20/03/2024 at 17:19:46+0100: >> >> > On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue <p...@debian.org> >> > wrote: >> >> >> >> John Hasler <j...@sugarbit.com> wrote on 20/03/2024 at 16:58:01+0100: >> >> >> >> > Pierre-Elliott Bécue writes: >> >> >> A phrase you will easily remember but that would be hardcore to guess >> >> >> through social engineering is perfect. >> >> > >> >> > Better is a random string that you write down. When people try to >> >> > generate phrases that meet those requirements they usually fail. >> >> >> >> Writing down a password is a bad idea. >> > >> > I don't think that's true anymore. The threat being mitigated is the >> > network attacker. The network attacker cannot (yet) reach through a >> > monitor and read a sticky note. >> >> Mitigating a specific threat by adding a new one is not a proper way to >> handle a threat when one can avoid both. > > What does your threat model look like? My home sees plenty different people coming in. Some I trust, some I trust less. Also videocalls is a nice way to get a paper password recorded (and yes it happens). Same goes for company. > Are spouses who go through a purse or wallet to retrieve a company > password a threat in your model? If that's the case, then you have > compensating controls to mitigate the threat, like physical security > on the office workspace. > >> > It is also why its Ok for a system to generate a list of recovery >> > codes, and have the user print them and store them in a safe place. >> > The other option are those cursed security questions, which have been >> > insecure for about 20 years now (but developers have their arms >> > wrapped around). >> >> A recovery code is generally designed to troubleshot 2FA issues, not as >> a replacement for the first layer of security that a password is. > > I believe recovery codes to regain access to an account due to a lost > or forgotten password predates 2FA. Most businesses I've worked with > use a Self-Service scheme, like recovery codes, to avoid the Help Desk > call. Some use the cursed security questions. Yes, but in that case there's another point, which is a contact mail address. And even this way it's problematic. > I am aware some European banks use Temporary Access Numbers (TANs) as > a form of 2FA. (I've never seen them used in the US). Each month a > [new] TAN is included with the printed and mailed account statement. > The "postal channel" is considered reasonably secure. Again, the > threat being mitigated is the network attacker, not a nosy spouse. Again, trying to mitigate one threat by creating a full range of other threats is the receipe for disaster. >> And therefore if it were to circuvent this first layer, then no, it's >> not ok to print them, except if you indeed have a safe. >> >> But in general it's a better approach to avoid having to resort to >> printed password on a paper. > > Humans are human. We have to understand their psychology and > limitations. Part of that is realizing a user cannot possibly remember > all the passwords required in the internet age. A big part of the > problem is what is known as the "Selfish Security Model for Password > Authentication." Each website wants a user to have an account and > manage a password. It is an impossible feat for folks to accomplish, > and that's why problems like password reuse across security domains > happens. Noone asks someone to remember more than two or three passwords. The rest belongs to a password manager. And people can do whatether they want, it doesn't make it anything other than a bad practice if it is one because 80% of a population does it. -- PEB
signature.asc
Description: PGP signature
