8 ms·

Login_duress: A BSD authentication module for duress passwords

125 points by djsumdog 8y ago

comesee 8y ago
jcs is pretty good
celticninja 8y ago
Solving the rubber pipe solution
- saalweachter 8y ago
  Not really.
  - egwynn 8y ago
    My intuition makes me agree that it does address the rubber-hose scenario. Could you elaborate on why you think it doesn’t?
    - csydas 8y ago
      Because we've seen studies on what torture does to people and how most people respond to torture. Once a person breaks, they try their best to appease their torturer. An adversary rubber hosing isn't just going to stop when they login and dont get what they want. In some rather narrow cases it might help avoid random searches from a non-malicious threat. (e.g., border guard just proving a point for whatever reason) If there is a purpose to recover something from your machine, an invested adversary that is willing to rubber hose is going to keep going. And the numbers seem to show that most people will not have the will and calm to use their duress password when they've been tortured into logging in.
      - daveFNbuck 8y ago
        The whole point of login_duress is that you say "there's nothing you want on this machine" and give them the duress credential knowing that the thing they want will be deleted. Once it's deleted, you can't break and give it to them.
        egwynn 8y ago
        Yeah, I think this is where the meat is. csydas’s points have merit. Namely: 1. torturers will keep torturing until they get what they want, and 2. victims will eventually tell the torturer whatever the torturer wants to hear in order to stop the torturing. However, if you can employ your duress code, then you might be able to defeat the torturer (by preventing them from gaining access — they could still very well kill you) or by alerting the outside world about the duress scenario.
    - saalweachter 8y ago
      The rubber hose scenario is that someone is willing to hurt you to access the data you have on your device. You trick them into entering a password that either wipes the data, alerts someone to the attempt, or dumps them into a sandbox that appears normal but doesn't provide the access they want. What do you think happens next?
  - zbentley 8y ago
    Well, it improves on risk (to the data, not the user) in torture situations, but I wouldn't say it "solves" the rubber-hose problem. And it only helps when a copy of the data has not been made. Torture works (in situations in which it actually works, which are vanishingly few--in no way should this be taken as in favor of torture) by creating expectations of future suffering. Torture victims are made compliant over time, so it's more likely that a victim would have the wherewithal to enter a duress code early in the process than it is that they would not crack after prolonged torture.
    - ufmace 8y ago
      Somewhat different perspective - torture works great, at what it's actually for. It's actually for oppressing a population you have control over, not specifically getting information. The getting information part is just a moderately useful byproduct. The torturers purpose is to terrify you, and your friends and family, out of having anything to do with the anti-regime forces. Considering that, whether you are actually guilty of anything may not matter, and whether any information you cough up is true doesn't matter that much either. Getting actionable intelligence against actual organized anti-regime forces is just a bonus. If you're thinking that way, and the forces you're up against are too, then the only thing this really accomplishes is potentially protecting the information that reveals your actual comrades. And if you're actually in a situation where protecting information about your comrades and operations is more important than potentially avoiding torture, then you're braver than most of the people on the planet, and good luck - you'll need it.
Bootvis 8y ago
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_ 8y ago
  > 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.
  - TomMarius 8y ago
    They might be unable to decrypt your data, but they still have the device in hands
  - Bootvis 8y ago
    I was thinking of this scenario: https://xkcd.com/538/ https://xkcd.com/538/
    - sjmulder 8y ago
      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 8y ago
        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 8y ago
        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.
dTal 8y ago
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 8y ago
  > 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 8y ago
    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 8y ago
      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
      - eeZah7Ux 8y ago
        > entering a password started changing a system significantly When different passwords (for the same user) simply decrypt and access different parts of the filesystem it's not the case.
frou_dh 8y ago
I imagine the primary usecase will be disabling your anime wallpaper.
imaginenore 8y ago
This is probably close to useless for a PC, since they can copy your hard drive before attempting to enter any passwords. But we do need this in Android.
mysterydip 8y ago
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.
- tyingq 8y ago
  Not this, but either BSD's auth_userokay() or libpam functionality in Linux would give you access to the cleartext password, which you could compare to whatever hashed history you wanted.
- CodeWriter23 8y ago
  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.
- stevekemp 8y ago
  I wrote pam_pwnd to deny the use of passwords which have appeared in the have I been pwned database(s): https://github.com/skx/pam_pwnd/ https://github.com/skx/pam_pwnd/ That's not exactly the same thing as denying a previously-valid password, but it is along similar lines.
notaplumber 8y ago
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 8y ago
  PAM shared libraries can (and do) invoke sandboxed sub-processes to do things like authenticate passwords (setuid).
ficklepickle 8y ago
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.
danpalmer 8y ago
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.

125 points by djsumdog 8y ago

comesee 8y ago

jcs is pretty good

celticninja 8y ago

Solving the rubber pipe solution

saalweachter 8y ago
Not really.
- egwynn 8y ago
  My intuition makes me agree that it does address the rubber-hose scenario. Could you elaborate on why you think it doesn’t?
  - csydas 8y ago
    Because we've seen studies on what torture does to people and how most people respond to torture. Once a person breaks, they try their best to appease their torturer. An adversary rubber hosing isn't just going to stop when they login and dont get what they want. In some rather narrow cases it might help avoid random searches from a non-malicious threat. (e.g., border guard just proving a point for whatever reason) If there is a purpose to recover something from your machine, an invested adversary that is willing to rubber hose is going to keep going. And the numbers seem to show that most people will not have the will and calm to use their duress password when they've been tortured into logging in.
    - daveFNbuck 8y ago
      The whole point of login_duress is that you say "there's nothing you want on this machine" and give them the duress credential knowing that the thing they want will be deleted. Once it's deleted, you can't break and give it to them.
      - egwynn 8y ago
        Yeah, I think this is where the meat is. csydas’s points have merit. Namely: 1. torturers will keep torturing until they get what they want, and 2. victims will eventually tell the torturer whatever the torturer wants to hear in order to stop the torturing. However, if you can employ your duress code, then you might be able to defeat the torturer (by preventing them from gaining access — they could still very well kill you) or by alerting the outside world about the duress scenario.
  - saalweachter 8y ago
    The rubber hose scenario is that someone is willing to hurt you to access the data you have on your device. You trick them into entering a password that either wipes the data, alerts someone to the attempt, or dumps them into a sandbox that appears normal but doesn't provide the access they want. What do you think happens next?
- zbentley 8y ago
  Well, it improves on risk (to the data, not the user) in torture situations, but I wouldn't say it "solves" the rubber-hose problem. And it only helps when a copy of the data has not been made. Torture works (in situations in which it actually works, which are vanishingly few--in no way should this be taken as in favor of torture) by creating expectations of future suffering. Torture victims are made compliant over time, so it's more likely that a victim would have the wherewithal to enter a duress code early in the process than it is that they would not crack after prolonged torture.
  - ufmace 8y ago
    Somewhat different perspective - torture works great, at what it's actually for. It's actually for oppressing a population you have control over, not specifically getting information. The getting information part is just a moderately useful byproduct. The torturers purpose is to terrify you, and your friends and family, out of having anything to do with the anti-regime forces. Considering that, whether you are actually guilty of anything may not matter, and whether any information you cough up is true doesn't matter that much either. Getting actionable intelligence against actual organized anti-regime forces is just a bonus. If you're thinking that way, and the forces you're up against are too, then the only thing this really accomplishes is potentially protecting the information that reveals your actual comrades. And if you're actually in a situation where protecting information about your comrades and operations is more important than potentially avoiding torture, then you're braver than most of the people on the planet, and good luck - you'll need it.

Bootvis 8y ago

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_ 8y ago
> 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.
- TomMarius 8y ago
  They might be unable to decrypt your data, but they still have the device in hands
- Bootvis 8y ago
  I was thinking of this scenario: https://xkcd.com/538/ https://xkcd.com/538/
  - sjmulder 8y ago
    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 8y ago
      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 8y ago
        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.

dTal 8y ago

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 8y ago
> 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 8y ago
  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 8y ago
    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
    - eeZah7Ux 8y ago
      > entering a password started changing a system significantly When different passwords (for the same user) simply decrypt and access different parts of the filesystem it's not the case.

frou_dh 8y ago

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

imaginenore 8y ago

This is probably close to useless for a PC, since they can copy your hard drive before attempting to enter any passwords. But we do need this in Android.

mysterydip 8y ago

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.

tyingq 8y ago
Not this, but either BSD's auth_userokay() or libpam functionality in Linux would give you access to the cleartext password, which you could compare to whatever hashed history you wanted.
CodeWriter23 8y ago
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.
stevekemp 8y ago
I wrote pam_pwnd to deny the use of passwords which have appeared in the have I been pwned database(s): https://github.com/skx/pam_pwnd/ https://github.com/skx/pam_pwnd/ That's not exactly the same thing as denying a previously-valid password, but it is along similar lines.

notaplumber 8y ago

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 8y ago
PAM shared libraries can (and do) invoke sandboxed sub-processes to do things like authenticate passwords (setuid).

ficklepickle 8y ago

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.

danpalmer 8y ago

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.