145 karma · joined September 16, 2013
Or?
The aim of email encryption is in a large part to prevent government-level parties from reading the emails. It doesn't really make sense to then go back to a system controlled by the very same parties.
OpenPGPs web-of-trust model seems more appropriate.
But both approaches share a significant number of problems, so...
- Subjects can't be encrypted.
- Encrypted mailing lists are complicated. Do you reencrypt in the middle?
What software do you use? The mailing list manager you use right now probably doesn't support it.
- Enigmail still doesn't support storing e-mails decrypted*. As a consequence, full-text search doesn't work.
- There's also S/MIME.
- Theres no software to manage public/private keys enterprise-wide.
- Legitimate server-side email retention requirements for enterprises
- Many people are quite alright with "most other people won't be able my email; maybe governments can".
- Most emails quite simply aren't that important.
- How do you deal with lost keys?
- Webmailers
- Often, as a sender at a company, you can not afford to inconvenience contacts.
- No easy way to synchronize keyrings.
- Server side spam filtering not possible
- Out-of-office auto-forwarding
- The other side uses gmail.
- Your mother keeps asking why you aren't on Whatsapp.
- The "metadata" (who mail whom? when? how long are the emails?) is quite telling.
Please solve all of these.Sorry for the unreadable list. Thank pg for the shitty markup format.
Also, because Bash is a particularly horrible language. I have a lot of experience writing bash scripts, and I hate bash.
Though direct remote code execution is probably much, much more likely than authentication bypass.
@Partitions: Seperating /home and / prevents normal users from filling up /. (And if you put both on LVM, you can grow them as needed.) Yes, I've only had this on some of the servers I've run.
@Impractical: it's one additional command for something I do quite often[4], and I still don't see the benefit (reminder: I fully agree with never using "PermitRootLogin yes").
[3] Granted, it does provide some context seperation in the sense that if you want to perform an administrative task, you have to explicitly use sudo. But it doesn't increase security, and it offers no advantage over "direct root access + normal user account".
[4] Not just scp, but also things like "less /var/log/messages" or "git clone root@host:/etc".
And again: what does "PermitRootLogin no" gain you over "without-password"? Why restrict it for no additional benefit?
I said "impractical", not "impossible". Of course I can use sudo. But it's more work. I require root access a lot. It adds up quickly.[2]
And I hate typing passwords/passphrases. In fact, many of my passwords I can't remember. I've got an SSH agent for that, which reduces passphrase entry to yes/no (tab-space/space, actually).[1]
Also, I prefer my normal user account not to be a sudoer at all.
Besides, please consider that disallowing root access actually only gets you protection against root password guessing anyway. The "stolen key + passphrase" scenario in a sibling subthread is so absurd I felt the urge to bang my head against my desk. Sudo won't help you there either.
[1] Now please don't suggest "passwordless sudo".
[2] And there is another inelegance: /home is usually on a different partition than /, so your way will involve an additional copy. If /home is even large enough to fit that file.
Getting by /without/ direct SSH root access is often impractical (think about scp), and without-password is a secure way to have it.
Also, the more people know about "without-password", the less people will set PermitRootLogin to "yes".
Of course multicopter flight times, especially with payloads, are problematic.
If the company requires more than what can be done in a 40-hour work week, it should hire more employees.
Giving an example is a perfectly valid way to make a point. Circumstantial doesn't mean wrong.
a) We (my country and the US) are allies.
b) I may be less not ok with spying on high-ranking politicians. But any spying on companies and normal citizens is right out.
People that aren't US citizens still get no protection at all.
That's why (for PGP) you, as an assurer, generally don't upload the signature yourself but send it to the e-mail address the assuree claims to own. The proof that they own that account is that they are able to receive the mail with the signature. They can then publish it themselves.
a) You'd just write your take next to the link, instead of hiding it behind. Your example is far-fetched.
b) This is obviously meant for ads. (And the examples on their landing page make that perfectly clear.)
Quote: "You can essentially advertise on any website for free!"
There is never any advantage for the users who click on the links.
There are a couple of different ways that are significantly better than brute force (as in: works against real cars in seconds to a few minutes). (Though since key length is only 48 bit, even brute forcing might be practical.)
This might interest you:
https://www.usenix.org/system/files/conference/usenixsecurit...