Live data from Hacker News

PAM Duress – Alternate passwords for panic situations

github.com

71–80 of 358 posts

Re: PAM Duress – Alternate passwords for panic situations

#71
post #31

The "guy with the gun" narrative comes up a lot, so this seems to counter that? I love the concept. It seems like something that would work well in a movie but fail miserably in real life.

This is really good, I've had a gun pointed at my head more than enough times with all my bitcoins wiped, finally a solution to my every day problem.

Re: PAM Duress – Alternate passwords for panic situations

#72
post #69

The Hello World example shows echoing to stdout from the duress script. Seems like a bad idea. I don't want to get beaten or shot when some rm -rf fails with an I/O error, alerting the attacker to what's going on. It seems like it would be more sensible for the module to suppress all output by design.

Just do this in your script

    rm -rf /secret/files > /dev/null 2>&1
That pipes STDOUT to /dev/null and redirects STDERR to STDOUT.

Re: PAM Duress – Alternate passwords for panic situations

#73

It's a very cool idea, but I think it would be most useful if applied to things like phones. I suspect most people pressed for passwords, are using a GUI system.

Exactly. It would be great to have a secondary pin (or my middle finger fingerprint, for example) in my phone to enter in a dummy environment with a few games, some family pics and so.

I think on Android you can set up multiple users.

Re: PAM Duress – Alternate passwords for panic situations

#74
post #48
post #17

The company that was pitching my employer retina scanners on data center doors 20 years ago had an idea like this. Left eye gets you in, right eye gets you in and alerts security.

This is also very typical for regular alarm systems with a keypad. A PIN disarms the alarms system, the same PIN + 1 disarms the alarm system and notifies security.

I worked at a place where the duress code was ROT5: 1234 was your normal access code, 6789 lerted security.

Re: PAM Duress – Alternate passwords for panic situations

#75
There are multiple levels of protection one might want.

I.e. when you are being selected for random questioning entering US as a non-US citizen, you'd benefit from steganography-like approach: you give a password, and relatively bland, non-personal stuff shows up, giving appearance of full access to a system.

If you only care about your privacy, the next one is to have a destroy-everything script (and it's not that hard: usually, passphrases are only used to decrypt the actual encryption keys, so overwriting those keys should be super fast). This would also work against unsophisticated attacks which are not going to really cost you your life.

If there is a potential for you to be a target of a sophisticated attack and the attacker does not care about taking your life, the biggest benefit is to have a way to inform someone of your whereabouts while you are actually giving access, ideally in a way that buys you time (eg. "webcam has detected stress on your face, please wait another 6 hours before trying to log in again" — sorry, company mandated software, when it happens usually, we call support).

Re: PAM Duress – Alternate passwords for panic situations

#76
post #50

Earlier quoted context omitted.

The duress login shouldn't reveal that anything is happening, so they have no reason to suspect you're using such a feature at all. Thus there would be no reason to ask you to log in again, and even if they do, you can simply use the duress credentials a second time.

If they can monitor network connections, they can see the duress connections, too.

You don't need to make it take any network actions, but even if you wanted to do that you could just use TLS. It would easily blend in with all the other services that use TLS as part of their normal operation.

Re: PAM Duress – Alternate passwords for panic situations

#77

Earlier quoted context omitted.

If your attacker has a full image of your system why are they bothering with duress?

Also depending on the jurisdiction depending on the circumstances triggering it can be a felony the same as destroying evidence or tampering with an investigation, if a court compelled you congrats you’ve just earned yourself a contempt of court charge that can last pretty indefinitely. In a jurisdiction that doesn’t adhere to the rule of law you are already screwed. What people often don’t seem to comprehend is that…

Deleting data, if someone can prove it, also opens you up to Adverse Inference, which means the jury can consider the plaintiff's reasonable inference as to what the destroyed documents contained.

https://en.wikipedia.org/wiki/Adverse_inference

Re: PAM Duress – Alternate passwords for panic situations

#78
post #23

What I never quite understand is how this can work in practice. When someone is under real duress, they do not always behave in a logical way and may be too stressed to remember certain details like a password that they never use...

You don’t understand how someone can remember a password under stress?

Re: PAM Duress – Alternate passwords for panic situations

#79

Training is very important in duress systems. I once worked in a place with a keypad duress code on the security system. If you prefixed your security PIN with NN-, it was the duress version of the code and would trigger a silent alarm. This was setup long-ago, and not communicated. One night, the keypad was acting glitchy. Partially out of frustration (countdown is running), and partially to test, I ended up acciden…

An interesting way to use this PAM-Duress system would be to write a program that

(a) begins recording your microphone and webcam video immediately upon login

(b) Aggressively try the hell out of every passwordless Wi-Fi network it can detect, then use headless chrome to aggressively smack every button to get past the stupid login pages

(c) Stream that video and audio to a server that saves it.

Re: PAM Duress – Alternate passwords for panic situations

#80
post #72
post #69

The Hello World example shows echoing to stdout from the duress script. Seems like a bad idea. I don't want to get beaten or shot when some rm -rf fails with an I/O error, alerting the attacker to what's going on. It seems like it would be more sensible for the module to suppress all output by design.

Just do this in your script rm -rf /secret/files > /dev/null 2>&1 That pipes STDOUT to /dev/null and redirects STDERR to STDOUT.

Seems like this should be baked in to the module. There don't seem to be any circumstances where you would want stdout/stderr from duress.d scripts to appear.
Post reply on HN