
Login_duress: A BSD authentication module for duress passwords - djsumdog
https://github.com/jcs/login_duress
======
notaplumber
For those who haven't heard of it, BSD authentication originated from BSDi
(early commercial BSD variant) and is pretty much exclusively used by OpenBSD
today.

[https://en.wikipedia.org/wiki/BSD_Authentication](https://en.wikipedia.org/wiki/BSD_Authentication)

[https://man.openbsd.org/authenticate.3](https://man.openbsd.org/authenticate.3)

It does have some benefits, with its process-based model, with various login_*
helper utilities (in contrast to PAMs shared libraries). This allows some cool
things like "sandboxing" with pledge(2), which it appears many are.. including
login_duress.

~~~
loeg
PAM shared libraries can (and do) invoke sandboxed sub-processes to do things
like authenticate passwords (setuid).

------
dTal
A natural extension of this idea is the concept of _multiple_ duress passwords
that do different things - i.e., the concept of a password as a command, an
unstoppable last chance to make changes to your system. If this becomes
popular I imagine authorities will start making images of devices before
demanding login, so they can check that the act of logging in hasn't
substantially changed the system.

~~~
codetrotter
> I imagine authorities will start making images of devices before demanding
> login, so they can check that the act of logging in hasn't substantially
> changed the system.

I think that’s standard procedure already.

Also, note that destructing or concealing evidence that is relevant to a court
case or legal investigation is a criminal offense in many jurisdictions. For
sure you will face charges just for trying even if you are not successful
(e.g. because they’ve imaged the system).

~~~
LeifCarrotson
How does having an image of the encrypted drive allow them to determine
whether the system has 'significantly' changed? Just generating a login in the
event log should make the image completely different.

~~~
kkarakk
i think the idea is that their(govt/shady entity - what's the difference?)
forensic scientists would be able to tell whether the very act of entering a
password started changing a system significantly which would count as refusing
to comply

~~~
ethagnawl
> changing a system significantly

I'm rehashing your parent's comment, but: Unless the command wiped the entire
disk or the entity gained access to the unencrypted versions of the disk
before/after the duress command, an outsider wouldn't be able to tell if a log
had been updated or if an entire partition had been wiped.

~~~
yorwba
Disk encryption prevents revealing the plaintext of files on disk, but you can
still observe their ciphertext changing when the file changes. If the duress
command causes different files to be modified compared to a normal login, then
that can be detected by comparing to the original disk image, even though the
actual modifications performed are hidden by the encryption.

On the other hand, it's possible to delete an encrypted partition by only
overwriting the encryption key, which might be a small-enough change to go
undetected.

~~~
zbentley
There's a little bit of subtlety here, but in general GP was correct in that
it can be made hard for authorities two tell exactly _what_ changed.

Disk encryption, unlike other forms, does not have a terribly high avalanche
factor when small changes are made--because it's expensive to write lots of
things to disk.

However, it is possible to make a small change (as small as, say, writing the
audit log file on a real successful login) that renders data completely
inaccessible. Consider an encrypted disk on which you can tell the _magnitude_
of changes on the filesystem, but not _which_ data has changed. Let's say you
have a lot (many gigabytes) of sensitive data on that disk. If a successful
login triggers the encrypted filesystem to decrypt the contents of the disk
using an encryption key (of, say, a 4kb length) that is _stored only on that
disk_ , then a duress code could simply destroy (or corrupt by randomizing a
few bytes) that key, rendering the contents of the disk inaccessible, without
writing more than a very small amount of data.

This fundamentally trades off deniability for data security: the disk would
still contain all of the encrypted data and could be brute-forced, but that
would be the case anyway if an image had been taken previously.

Of course, situations in which that deniability would be legally well-received
are, as others here have pointed out, vanishingly rare.

~~~
tedunangst
Where does one find such disk encryption software?

~~~
jakobegger
APFS, the new macOS file system, works like this.

If you have an encrypted volume, you can use the command 'diskutil apfs
eraseVolume' to make data inaccessible instantly by deleting the encryption
key. (Note that the disk passphrase is not the same as the encryption key, so
even if you use a weak password for your disk, you can't brute force the key)

------
mysterydip
Could something like this be used on headless servers to trigger an alarm that
old passwords have been compromised? The typical "root login failed x times"
has too much noise to be valuable in my experience for anything internet-
facing, but looking for specific passwords tried might be useful.

~~~
CodeWriter23
Yes. Put the hash of the old password in the /etc/duress file with a script
that pipes to sendmail you@youremail.com. Add one line per old PW you want to
monitor and vary the message sent via sendmail to ID which password.

------
frou_dh
I imagine the primary usecase will be disabling your anime wallpaper.

------
Bootvis
What about the scenario where the adversary pokes around in the system and
finds you have it installed?

Might the following script make sense:

\- Delete/change what you don’t want to share

\- Change the regular password to the duress password

\- Remove login_duress

Any flaws with this approach or improvements?

~~~
gbrown_
> What about the scenario where the adversary pokes around in the system and
> finds you have it installed?

The whole point of this is that the adversary _doesn 't_ have access.

~~~
Bootvis
I was thinking of this scenario:

[https://xkcd.com/538/](https://xkcd.com/538/)

~~~
sjmulder
This is the whole point of such a feature. Pipe wrench guy demands password,
you give the duress password. Re. parent comments, I suppose you could have
the script delete all traces of login_duress (and itself).

~~~
Bootvis
Might be good to mention that in the readme.md then? Or make it an option in
login_duress itself? I don’t understand the downvotes on my original comment.

~~~
daveFNbuck
Your original comment is easy to misunderstand. Until reading the rest of the
thread I thought you were suggesting that an adversary who hacked into your
system could use login_duress against you.

~~~
Bootvis
I see thanks, too late to edit.

------
danpalmer
It would be great to see a variant of this come to smart phones. Having a
passcode that logs into a reasonable looking OS install, i.e. same wallpaper
as the login screen, default apps only, no payment cards added to the device,
no email configured, no passwords saved, basic web history. Would be good for
crossing borders.

1Password already has the ability to wipe for travel, would be good to see
more of that.

------
ficklepickle
I'd love something that works like this, but with the disk encryption password
screen.

Specifically, plymouth provides the splash screen on boot with many common
Linux distros. If I enter the decoy password, take some action, like
displaying a fake error screen.

I toyed around with making a plymouth theme to this end, but didn't get far.
It would be nice to have a theme that offered plausible deniability wrt FDE.

------
celticninja
Solving the rubber pipe solution

------
comesee
jcs is pretty good

