Jeffrey Walton <noloa...@gmail.com> wrote on 20/03/2024 at 19:16:16+0100:
> On Wed, Mar 20, 2024 at 1:45 PM Pierre-Elliott Bécue <p...@debian.org> wrote: >> >> >> 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). > > So now you are arguing someone jumps on a Zoom call, and then displays > their passwords to the camera. If we are going to use far-fetched > examples, then write the password down with invisible ink. Recover it > when needed using the special pen provided with the junior spy kit. It's not far-fetched, it's actually something that's occurring from time to time. And that's easily preventable. >> Same goes for company. > > Companies generally have physical security on their assets. No one is > going to wander in the server room unsupervised. No one is going to > wander the cubicles lifting mouse pads and looking through drawers > without raising suspicion. > > If someone is allowed to do those things, then the company's controls > are not going to be very helpful, and the company has bigger problems. Companies regularly receive external personel, and it's quite easy to have someone trespassing either a bit "oops sorry wrong office". >> > 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. > > I think you are throwing the baby out with the bathwater. Taking a big > problem (the network attacker) and reducing it to a smaller problem > (securing recovery codes) reduces risk. While one could just easily tackling the first issue without creating a second one with a… password manager? I think you're spending a lot of energy to recommend a dangerous solution because… who knows? instead of agreeing to recommend a sensible and easy to deploy solution. > I read about account compromises all the time. The creative ones use > SIM swaps to circumvent 2FA. I can't remember an instance of an > account compromise because a thief stole a wallet or safe. Yeah, using SMS/calls for MFA is not the best option. It's still one, though. But the whole is still offtopic regarding password security mechanisms (ie, don't flying write your password on a paper). >> >> 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. > > Huh? This is discussed in detail in Peter Gutmann's Engineering > Security, <https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf>, > Chapter 7. In particular, pages 565-567 discussed the Selfish Security > Model. And because it's discussed in an irrelevant pdf means it's what one asks in this thread? Do you want to also bring in security practices from the 80's? >> 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. > > Agreed. You have to have a security model and model the threats. I > don't see much of that going on in this thread. You don't need a threat model to understand why writing a password on a paper is generally a bad practice. But since you invest this much energy on defending a bad practice, I'll let you keep the trend alone. -- PEB
signature.asc
Description: PGP signature
