Hacker News Reader

I'm struggling to understand any situation where you should ever be typing either your LUKS password or your root password into a fully operating/running system.

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.

You are entirely correct and it is too bad I did not delete my comment in time. Here I am with an intense dislike of bogus criticism on HN and yet perpetuating some. Sleep before you post...

What I found problematic (unless I'm missing something) was the suggestion that your day-to-day user should be in the wheel group: if that's the case, once your user is compromised the attacker can edit .bashrc to change $PATH and use a patched sudo to take over the machine.

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.

sudo'ing as your day-to-day user is dangerous for another reason, too: the default 15 minute password timeout lets subprocesses in your shell use your sudo credentials, even if you didn't intend them to. e.g. sudo command, then later ./some-installer.sh - you didn't want to give some-installer.sh root, but it opportunistically uses 'sudo' and succeeds.

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

Sure, it always bothered me that guides show whole lists of commands prefixed by sudo, instead of teaching people to disable the timeout and use "sudo -i" or "sudo -s" to get their stuff done. See also the fact that OSX ships with tty_tickets disabled.

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

it always bothered me that guides show whole lists of commands prefixed by sudo, instead of teaching people to disable the timeout and use "sudo -i" or "sudo -s" to get their stuff done

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.

> 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.

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.

Sudo provides:

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.

Well, yeah. But that's not why sudo became popular.

Sure, although I never found that reason to hold much ground given that in reality most distros ship with accounts that can open a shell (instead of having a list of allowed commands) and have the timeout not set to zero, so any security benefit that would come from not using "sudo -s" is pretty much voided.

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.

When you have multiple commands to run, chances are that only some of them require root privilege. Prefixing only those with `sudo` instead of executing all of them in a root shell allows you to reduce damage, should the "normal" commands are typed wrong or have bugs.

You don't need wheel to modify your terminal environment, $PATH or .bashrc. If your user account is compromised, your user account is compromised. Anything else is lipstick.

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).

You misread my post, what I meant was that your day-to-day account is vulnerable, since you run your applications with it. If that's the account belonging to wheel, once your user account is compromised the attacker is root as well. One should use a different account, hopefully harder to compromise since is used only for sudo.

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.

Basically, this is a GNU vs BSD misunderstanding. On BSD, only wheel members can use su to become root after entering the root password. On GNU/linux anyone can su to root by entering the root password regardless of whether they belong to wheel or not.[0]

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-...

Right, I kept using "wheel" to mantain the terminology in the github page, but clearly this created confusion.

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.

If you have unrestricted sudo, which is how most single-user systems are set up, your password is effectively the root password.

> If you have unrestricted sudo [...] your password is effectively the root password.

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

With root privilege you can erase all of the audit logs. A malicious attack probably would do so if he/she cares about that.

You can't erase remote logs, or logs written to a write-only logging device (the one's I've seen seem essentially to be a serial port/usb device that emulates a line printer).

True, but that seems tangential to the question of whether using the same password for both the root account and LUKS encryption is bad advice.

Sudo is more often than not a security risk. If a program is not made to run as root it is usually because it would give too much power to a user (ie sudo mount is supid).

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

Frankly, I find it suspect that they even suggest having a root password. The only situation where this is useful is when sudo is somehow broken (e.g. a typo in /etc/sudoers). This happens rarely enough that I'm OK with a more heavyweight process (like booting Knoppix) to fix it.

It's the annoying times when your system forces you in to single user mode for repairs, and you have to enter something... or else boot up a rescue disk (the proper solution) to fix it, that make having a root password at all a sometimes good idea.

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

Depending on the breakage (e.g. if your initrd got borked), you'll probably need the rescue disk anyway in order to have access to the necessary tools to activate RAID arrays, decrypt disks, activate LVM VGs, etc.

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.

>Trick the user into running a program that does 'alias sudo=evil-sudo' >> ~/.bashrc

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

Good point. I've toned down my comment because that root password would be getting typed in less often.

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.

You actually tend to never use the root password on a modern workstation -- just sudo. The situations where you have to use a root password are usually if something has gone wrong and you have to log in via tty.

What do you mean by microphone?

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

Audio analysis of keyboard chatter is a thing that had a proof of concept years ago. I have no idea how often it is done, but it is certainly plenty possible.

Maybe prepare a pullrequest for this? ;)

Not to mention this gem:

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

I don't see any problem with that. Physical security is much easier to manage than digital security.

The age-old "don't write your password down!" mantra is not meaningful without clarification.

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!)

You left out the beginning and ending of that sentence:

> "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."

Good enough for Bruce Schneier:

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

Why not? Write them all on a piece of paper and lock it in a safe. Probably much safer than a password manager.

Absolutely. I use a password manager for everything except a handful of ultra-critical sites, mostly things involving money or attack vectors to get access to my email. For those sites I don't trust to store in LastPass, I write the passwords down on paper. But I also do something I haven't seen others recommend:

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."

> *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 :)

Can't really argue with that. I guess got this in habit of using initialisms, because a lot of sites had limits of 32 characters for passwords.

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.

You can break into a safe with sufficient physical force. You can't break into a LUKS-encrypted hard drive with that physical force ().

() 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.