If you're using sudo correctly, you do not enter your root password. Frankly, the only time I can remember being prompted for a root password in years is when the system has failed to boot and offers entry to a recovery/maintenance shell.

If you're using LUKS correctly for your boot drive, you enter it only during startup before the system has booted.

If someone has access to your disk and has your LUKS key, the root password is merely a formality.

Yes, but it keeps an audit trail of who's account was compromised, etc.

IMHO "sudo" (or "doas") should be used from a different user, by switching to a different VT. Or at least only allowing certain commands for you day to day user.

And I agree that the typical sudoers config that allows opening terminals as root isn't a good idea.

What I prefer lately is using a yubikey neo to ssh access a root shell. You can configure sudo and authorized_keys to allow directly opening a root shell and you never enter any passwords anywhere except the pin to unlock the yubikey's openpgp applet. The yubikey will lock the key after six unsuccessful pin attemps and you can just yank the key out when it's not being used.

Now all I need is some sort of phone app that reaches out to me on a side-channel to pops up asking me to authorize each login (something like libpam-askmeonmyphone)--(I really like the way the Microsoft Account 2FA phone app works in this regard). If I could change one thing about the yubikey neo, it's that I'd require it to make me physically interact with it to decrypt anything (beyond entering the PIN).

That said, I like your use of yubikeys, even better than the phone that's the sort of stuff that should be triggered using a smartwatch.

The confusion with respect to these guidelines is because some BSD-inspired GNU/linux distributions confugure their sudo to use a "wheel" group.

> once your user account is compromised the attacker is root as well

... but only if they also know the root password.

Anyway, the long and short of it is that on GNU/Linux, wheel is only relevant on distributions that use wheel in their default sudo config.

[0] https://unix.stackexchange.com/questions/4460/why-is-debian-...

But my point was that, regardless of whether you use sudo or su, on GNU/Linux or on *BSD, if the account used to elevate priviledges is compromised, the next you elevate you priviledges you should expect the attacker to follow you.

This is what I meant by "the attacker is root as well": it's just a matter of waiting for the next time you use su or sudo.

(I disable credential caching with "Defaults timestamp_timeout=0" in /etc/sudoers.)

Still, unless one is sure that the sudo being invoked really is sudo, disabling the timeout won't be enough.

That gets to the philosophy of what sudo is used for in the first place. Back when sudo was experiencing a big upswing in popularity, it was a way to avoid having a root shell open at all. Forcing the user to type sudo before every command reminds them they're acting as root.

If you advocate for only using sudo as a different way to authenticate for a root shell that's cool and all (I often use it like that too), but you're going to run into a disagreement around the nature of sudo.

And I'm skeptical that having users type sudo a bunch of time when they add a PPA and install a program somehow results in greater awareness, but this is purely an opinion of mine.

The other big reason for using sudo is the ability to change policy wrt which users can be root without changing root password everytime, and that clearly is true.

I do not think that is accurate. As I remember it, sudo gained popularity because it provided better control over access to the "root password" for teams of administrative staff. sudo was lightyears easier and provided much more fine-grained control than figuring out how to design POXIX groups.

1) A mechanism to provide better control over access to root privileges where administrative access must be shared between multiple users.

2) An auditing mechanism to record both operations completed as the root user, as well as failed attempts to perform operations as root (usually authentication failures).

3) A way to remind the user that commands are running as root, as well as a way to avoid accidentally running commands as root, since you're never (without "sudo -i" or "sudo -s" or similar) at an actual root shell.

If you're using "sudo -i"/"sudo -s" all the time, you don't lose anything for #1, and losing #3 is mostly just an inconvenience (it's an extra layer of protection, but it's not even really foolproof even with sudo). Losing #2 (auditing) can be a big deal, though, because, if everything's happening at a root shell (rather than via the sudo command), you lose the audit log that traces what's being done at root. Gaps like that in audit logs should be an indicator that something bad might've happened, but you can't make that assumption if you're routinely doing it yourself, too.

Add that to not having a root password and you have a single (weaker) point of failure (wheel group).

Really though, that rescue disk sounds like a better idea every time I think about the situation.

Even without, IIRC, Ubuntu (one of the few systems that actually gets root passwords right by defaulting to it being randomly-generated garbage that nobody knows) will prompt for the credentials of a sudo-capable user even for single-user mode.

That's only going to get you the user's password, not the root password.

An attacker might still bring an evil-su in addition to an evil-sudo, though. And even if you're logging into that root user only in an another tty, it seems like an unnecessary risk to share the password with LUKS.

Is audio analysis of keyboard chatter a thing or are we leaking passwords when we verbally communicate them to a co-worker?

I don't think this is related, but I found this keylogging technique combining microphone, camera, accelerometer data to approximate finger/thumb positions for PIN numbers: http://www.cl.cam.ac.uk/~rja14/Papers/pinskimmer_spsm13.pdf

> it is fine to write down your passphrases and keep them in a safe place

That is essentially, of course, how password managers work!

There's no reason not to write a password down as long as it's securely stored. You probably need embarrassingly little physical security to store your password more safely than many dodgy website solutions!

I _still_ frequently get my _already set_ password emailed to me in plaintext either on sign-up, or when I click "forgotten". (The site is always treated to an angry email encouraging a thorough redesign - though not of course, a 'reply', which would give them even easier access to my password!)

> "Unless you have concerns about physical security, it is fine to write down your passphrases and keep them in a safe place away from your work desk."

https://www.schneier.com/blog/archives/2005/06/write_down_yo...

Have a (logical) salt for all of the passwords. Don't write down that salt.

So, if you found my piece of paper with passwords, you might see something like this:

Etrade - I1999IbmfsaaymIwIbmoi

Gmail - D9cjeawfocsIdkwhtfts4r

But my actual passwords are something like this:

Etrade - I1999ibmfsaaymIwibmoi804WMainStreet

Gmail - D9cjeawfocsIdkwhtfts4r804WMainStreet

804WMainStreet is tacked on to the end of all of them, but you wouldn't know that from looking at the sheet of paper. Only my spouse knows the salt, and it's easy for us to remember, e.g., maybe 804WMainStreet is the address of the first place we lived together. In theory, this is reducing randomness, which might make it easier to crack one knowing the others, but I'm not super concerned about that.

The two most important elements of security for regular consumers are: 1) Use different passwords for everything. 2) Use multi-factor auth when available.

Whatever you have to do to achieve that is better than not doing it.

*And I actually use initialism for these passwords so I don't have to pull out the piece of paper often, only when I forget. In this example, the Etrade password might be derived from "In 1999 I bought my first stock as a young man. I wish I bought more of it."

Ideally, you'd just set "In 1999 I bought my first stock as a young man. I wish I bought more of it." as your actual password :)

But that's probably less true these days. Since they should be hashing the password anyway, why not allow something huge, say up to 1000 characters.

() Unless you either turn that force into the energy required to brute-force the passphrase/keyfile or use it in a way that invokes xkcd #538.