Hey, surprised to find myself here and appreciate all the discussion. I'm the author of the above project and wanted to shed some light on the inspiration for the project.
It started as a simple weekend project based on an off-hand comment someone made in a security professional chat I'm in. I had used duress words in military and translating the concept to a PAM seemed like a fun exercise. Also supports my current shift towards swapping careers from pure software engineering to cyber-research or cybersecurity generally. So in the end, it was a weekend project that served a dual purpose as a resume stamp.
The design use case I had in mind was more benign; such as corporate espionage or journalists getting their devices confiscated (maybe keep a sticky note on the laptop that has a duress password on it as a red-herring). Comments to the effect that law enforcement would image a device are very relevant as any competent law enforcement agency should have their staff trained to get the device fully powered off and hand it to someone that can maintain a chain of custody and get a golden image for use in potential criminal charges.
One thought I had was to apply this to SSH auth for honeypots and if a rockyou.txt password is attempted it runs some routines that aid in crafting the honeypot before the intruder drops to a shell prompt. Another even more light-hearted implementation could be you have password X is the one you login to normally and your "duress" password Y just clears your browser history and is the one you give your spouse for when they log into your computer :). I'm sure there's use cases in the full spectrum and with it being a relatively simple implementation with user generated scripts, it'd be easy to extend to any potential use case.
In any case I'm glad it prompted such a good discussion. Feel free to submit issues if there are particular feature requests or bugs that one might run across. Additionally if there's a PR up, I'm currently the only dedicated dev on the project and welcome anyone that wants to review my PRs; always prefer a 3rd person review even on my own projects. I created a demo video using Pushover and in the process of doing the demo uncovered some bugs that I patched as well as some fixes to the documentation. Again, glad you all found this interesting and humbled it fostered such a good discussion.
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 accidentally engaging the duress code by tapping a convenient corner number, which resulted in NNNNNNNNN-PIN.
After law enforcement had surrounded the building, a quick chat and search alongside a few officers got it all sorted.
As part of a duress protocol — where your extortioner is likely observing you — law enforcement would be required to go through the motions of arresting you and taking you offsite. You can expect to be held for X hours regardless of whether they believed you had simply made a mistake.
Long and unavoidable administrative delays make it much harder for villains to subvert protocols. See also time-delay bank vaults and mandatory two-week vacations for pension fund managers, where they are locked out of corpnet.
Mostly cases where businesses rely on individuals instead of process.
As a simple example, it's very easy, when starting a company, to issue personalized email addresses to early employees and then people communicate using those email addresses. It's perfectly fine to email the CTO at first-name@example.com, because everyone knows everyone else and it works.
As you grow large, it becomes important for people to address roles rather than individuals. This way, if people leave their role, they can (semi-transparently) be replaced by someone else taking that role who will then continue to receive all of the same emails, be able to respond to them, etc. So then it becomes important to have e.g. a cto@example.com address. When the CTO takes a vacation, their email gets routed to someone taking over their duties, you don't need to communicate to everyone to start emailing somebody-else@example.com instead.
This isn't how any of my workplaces have worked. When someone leaves, they or their boss sends an email announcing the role changes. Which companies practice the role@ method?
As JulianMorrison notes, this is common in finance. The FDIC strongly recommends that banks enforce this[1] – you can't cook the books when you have no access to the systems.
But sometimes it's not just about cooking the books: the last "SSL cert expiration" fire I lived through happened because the person who had credentials to Digicert had to take sick leave. It was never a documented/defined process because "just flip Tim an email" was always sufficient, Tim didn't mind doing the work, and Tim didn't like going on vacation.
Two week lockouts mean there's no chance of shadow IT/back channel work happening, and forces you to document your processes.
IIRC, over here, banks are required to give employees at least one two-week contiguous block of leave, during which they can't get into the office, use work systems, or log in remotely. The idea being that oh-so-clever scams generally require the operator to be there keeping all the balls in the air, and locking them out will reveal their tricks.
My old company locked us out several years ago for a period of time that continues to be uninterrupted.
It certainly did shake out lots of problems...
(My point is that after having had that happen to me, if it EVER happens again and isn't cleared up within minutes, the sonic boom you hear will be my tactical resume deployment. I dismissed the warning signs as "minor glitches". Never again. However, if it is something planned and I agreed to it beforehand, I guess that's OK. On second reading, you might have been describing something like that.)
Not from the US, but here at a bank I worked with: If you trigger the silent alarm they'd have reason to suspect you are threatened and would take you to custody to make sure you are safe and release you once it's sorted out (probably an hour or so).
That makes sense. Sorting things out takes time. But trying to create an illusion that no alarm was triggered to prevent criminals from gaining knowledge: not a reason to imprison an innocent person.
Kind a hard word to use for an arrest. In many places police can arrest you for some period if they suspect you have committed a crime. This is no different. No need for sensational language.
In the US they can’t do anything unless they have “probable cause” you committed a crime. That’s broad, but it excludes “this guy pushed the number 6 three times in a row.”
And “imprison” and “arrest” are pretty darn close. In the US, when you are arrested, you are usually searched, fingerprinted, and a mugshot is taken.
The mugshot can become a public record. There are websites that match mugshots to names, and make money by being paid to take mugshots down.
Nobody wants the google result for their name to be a mugshot.
Probable cause isn't "pushed button multiple times" it is "silent alarm was triggered and this guy is on the only guy in the building".
If US is doing stupid shit then US is doing stupid shit. What else can we expect a third world country to do? In civilized world you are processed yes, but since you are just arrested and not accused you will just be held until the pre-investigation has concluded
This thread is long dead and off the frontpage - and this likely won't be seen by anyone (or even you nextlevelwizard) but here goes.
> What else can we expect a third world country to do?
We can criticise the largest economy in the world as much as we want inside a browser developed mostly in the US on infrastructure (the internet) whose large parts were developed in the US talking on a website created and owned by a US based company investing capital in one of the largest tech markets in the world (the valley).
That said - the fact they have police/healthcare/tuition problems does not in fact make it a third-world county.
A developing country ("third world") is typically one with low human development index (HDI) (the US is "very high"). Low economic output (the US is the largest economy) etc.
In the US, what you're talking about is referred to as "detainment" which is very different from an arrest. I think that's where a lot of the confusion is coming from.
People can be taken into protective custody without any suspicion they committed a crime, though typically this is mostly done with children and they're taken to foster care, not county detention. It has been used in the past to protect people from getting lynched after being publicly accused of a crime even if the police don't suspect them, and is used to protect confidential informants by arresting them along with everyone else just to keep up appearances, though in this case they usually agree to it in advance.
There's 'arrested' and 'detained'. In the US police can detain anyone for up to 48 hours (72 hours if it's a weekend or long holiday). If they don't file charges by then they have to release you.
For a silent/duress alarm it's easy to cross reference the person at the door with a list of personnel authorized to be in the facility. Security in a scenario like that would normally ask for an ID, radio it back to their security office to validate the person is on the access list for that office/building/facility/etc and then do a quick walk-around.
I had a similar false trigger trying to make an international call from our office phones. I didn’t know the exact incantation of the prefix, but knew it was 9 for an outside line and at home I used 011 then the country code. That didn’t seem to work, so I thought maybe I needed to drop the zero, resulting in me inadvertently dialing 911 and hanging up when that didn’t give me the dial tone I expected. I found the right sequence and was interrupted multiple times in the call as our floor fire coordinator showed up, then a few minutes later facilities, then a few minutes later local police.
I guess the system worked and I never forgot the correct prefix after that.
I always find it crazy when systems make you dial 9 for an outside line, for this very reason.
Did the same thing myself my first week in college. Got the police. Told them what I did and I could hear the eye-roll on the other end of the line, and was told I was the third person that day.
I'd always assumed (UK) that 9 was a deliberate choice to make it easier to dial the emergency number, 999, because you can just mash 9 until something happens. I guess if it's the same number in all other countries who have a range of emergency numbers, then that might not be the reason.
> The 9-9-9 format was chosen based on the 'button A' and 'button B' design of pre-payment coin-operated public payphones in wide use (first introduced in 1925) which could be easily modified to allow free use of the 9 digit on the rotary dial in addition to the 0 digit (then used to call the operator), without allowing free use of numbers involving other digits
There's a citation, but it's a book from 1950, so not particularly easy to verify.
My working theory is that in old times phones had rotary dial instead of key pad. Number 1 was the longest to dial, 9 was the shortest (as I remember from childhood days). Thus, fastest way to dial 3 digit code was to use numbers with as much as 9 as possible (997,998,999).
I would add that 911 is a "queer" choice (for rotary phones), in other countries the emergency numbers are lowish numbers, in Italy 112 or 113 (or 115), and there are several records in the past of people managing to "dial" them by quickly pushing and releasing the hook switch.
There was another reason for this as it was common, many, many years ago, to restrict the possibility to make phone calls by using a little lock on the dial, like this:
Did you introduce the EU emergency number as the national one? If so - good choice.
In France we have the plethora of numbers (15, 17, 18 - I actually do not know what 16 does), and also 112.
We are still teaching "18" as the primary number (you get the firemen who will either come for a fire, or for an accident, or dispatch). We could go for 112 (and keep the older number for a generation, redirecting them to 112) and not rely on people to know which number to call.
UPDATE: I just asked my 17 yo son which number he would call in an emergency and he said 112. So there is hope :)
JFYI, besides and before the EU emergency number, in Italy we traditionally had:
112 Carabinieri (one of the two national "police" corps)
113 Polizia (the other national police corps)
115 Pompieri (Fire Brigade)
118 Ambulanza (Ambulance)
In Italian it is a common phrase "roba da chiamare il 112" o "roba da chiamare il 113" (something that needs a call to 112 or 113) as a synonym of "a serious emergency" and of course if you called those numbers they would anyway forward the call to the appropriate service (like ambulance, fire brigade, etc.).
The EU emergency number is slowly being introduced (some regions have it already, some not yet), but the 112 is already well in the minds of anyone.
> How does/did a citizen make the decision of which police force to call?
It is a good question.
It depends.
There may be territorial choices or also "political" ones.
Typically Carabinieri have more presence in the country/villages/small towns whilst Police have more presence in larger cities (but there are Carabinieri there as well and - additionally - the local police, which were once called Vigili Urbani and now are called Polizia Municipale, and there is also the Polizia Regionale, to the joy of foreigners that do have a really hard time to understand the subtleties), highways and main roads are typically Police only (Polizia Stradale), but minor roads are usually patroled by the Carabinieri.
So usually you call (called) 112 or 113 depending on where you are (where the emergency happens).
The "political" part is even more subtle.
The Carabinieri are a branch of the military, whilst the Police are "civil", people leaning to the right tend to trust the Carabinieri (whose motto is "nei secoli fedele" i.e. "faithful in centuries") more than Police, whilst people leaning to the left tend to trust the Police as being more independent.
Until not so many years ago if you (or your family) had some relationship/contacts with some (left side) parties or association you would have not been allowed to join the Carabinieri (whether this was official policy or simply what happened is another thing).
The popular perception was (is) that the Carabinieri operate strictly by the Law, whilst Police is a little more "giving/flexible" (on minor things).
On the other hand, once it was easier to join the Carabinieri with a lower level of school/education than to join the Police, so we have here all the jokes about stupidity/ignorance targeting the Carabinieri (the same ones that traditionally in the UK are about the Irish or the Polish).
In France we also have two "police" forces: the "gendarmerie" and the "police nationale".
You may know "gendarmerie" from the Louis de Funes movies (Le gendarme de St Tropez, ...) - this is a military unit that mostly works in the countryside.
The "police nationale" is an entity attached to the ministry of interior and does more or less the same things, but more in the cities.
There is a history of hatred between these organizations - yes, this is how stupid we are. They share competencies (the most well known being the elite units - GIGN and RAID)
When you want to call the police, you dial 17 and you get the right one, depending on where you are.
If you have a health problem, you call the 18 (firemen), or the 15 (ambulance).
If there is a fire, you call the 18.
This is why having a single 112 number is easier to teach to children and tourists.
TL;DR Running out of numbers and putting in temporary measures requiring the 16 as prefix. Measures that likely didn't scale as well as expected since we moved on to a different system within basically 10 years.
I heard a very interesting explanation (on BBC R4) of the reason for choosing 9 (one of the slowest numbers to dial), rather than 1 (the quickest).
The old overhead telephone lines could knock against each other in the wind, producing a pulse which (to the system) appeared to be a 1. This could easily happen three times in a row, resulting in an unwanted call to the emergency services.
On rotaryphones 0 takes the longest to dial, then comes the 9. 1 was the fastest to dial, I think this is the reason why emergency numbers tend to have the lower numbers.
Pedantic tidbit of archaic lore: this was so because each digit was represented by the number of clicks that the rotating disc triggered on the line (with 10 clicks for 0).
If the dial was locked or missing, you could still "dial" a number by quickly tapping it with the on-hook switch the receiver would rest on, because that was the same effect the rotary dial mechanism was producing
Was the arrangement of the numbers backwards from the US rotary phone? Because in the US 1 was the shortest. That’s why large cities like New York got 212 and Los Angeles got 213 which were the fastest to dial on a rotary phone.
We stopped extensions since there were multiple exchanges being used on campus so you have to dial someone's entire number. But, you will have to dial 9 and 1 and then the number. Everyone has externally accessible phone numbers so why are we still dialling 91 when youve got to dial the whole thing anyway?
I had the same issue happen but on a fax machine. Naturally, I couldn't hear anything when the 911 operator picked up, so I continued to try out various combinations, until the watchman and a cop showed up to check on the situation: just me trying to fax something abroad late at night.
I've seen it with someone with a certain amount of dementia trying to make a modem work. What he was trying to do was actually impossible and he responded to failure by trying variations on it.
Perhaps it needs the 1 for long distance? (No, it doesn't, the software knows better.) Perhaps it needs a 9 for an outside line? (No, the modem already has an outside line, it doesn't go through the phone system.)
To dial out at my office, you have to dial 991. It’s only a matter of time before I either accidentally dial 911 at work or accidentally dial 991 in an actual emergency.
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.
1) Put a tiny dot of Black 2.0, not very noticeable and blocks the light very well.
2) Don't do personal stuff on your company laptop. If the company doesn't let you modify it, joke's on them, only company files will get leaked. Your personal stuff shouldn't be on that laptop.
3) Fuck that, if there are photons you can collect them
I found out the hard way that a job I had once (DIY store) had a hidden panic button under the counter. I was just fidgeting while we were closing up, hands found it and did their exploration thing.
I mean it happens, the security company sent out a van already (as they should) and called to confirm. They charge a fee (just over €100 I believe? Or €250? I forgot) for false alarms, but that's fair enough. Better safe than sorry.
Anyway, a DIY store with at most 100K in the safe (weekly takings at the time, most of that was probably electronic) is probably a lot less serious than whatever you were working for, to have it surrounded by law enforcement.
Author here; it relates more with physical security and I've used them in the military and in corporate structures. Most duress word programs are designed to be spoken; say security calls because an alarm is set off and the aggressors are coercing you to get the security off their backs. One may say, "Sorry I was working late and fumbled the alarm. Mr. Rogers has a board meeting tomorrow so I've been working late," where Mr Rogers is a fake name of no one that works at the company.
I kinda just thought to turn that concept into a PAM as a thought-experiment mostly but there are some edge case security examples where something like this could be useful, say for journalists or when dealing with corporate espionage.
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).
> 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.
DO NOT DO THIS UNDER ANY CIRCUMSTANCE unless you have first talked with a lawyer about this idea.
18 USC 1001 says (in part):
> whoever, in any matter within the jurisdiction of the executive, legislative, or judicial branch of the Government of the United States, knowingly and willfully falsifies, conceals, or covers up by any trick, scheme, or device a material fact shall be fined under this title [and] imprisoned not more than 5 years
Prosecuting lies to federal agents is a very common technique used by US Attorneys to essentially bootstrap felony charges[1], and federal courts have stretched "materiality" pretty far[2] so saying "oh, I didn't have anything illegal on the 'secret partition'" might not save you.
The law here is not completely developed. The US Supreme Court has not ruled on the extent to which electronic devices of a US person may be searched at a border.
In practice, courts have generally allowed manual, cursory searches of electronic devices (such as looking at recent photos) as being similar to a search of luggage. However, courts have disagreed on how intrusive the search can be and whether a more invasive search at the border can be conducted without some additional suspicion.
Yes. Courts have upheld that a manual search of your phone by customs is legal. But more invasive, forensic investigation of your devices has been found to be unconstitutional. I'm not sure exactly where or how the line is drawn between the two.
Relatedly, make sure you trigger the password lock on your device before handing it over. They may be able to compel you to give your biometrics but not your password (the latter is considered compelled speech, and the courts have not fully litigated whether the former is treated the same).
Nova Launcher on Android (and maybe other launchers, I do not know) has a nifty little feature to activate password lock bypassing biometrics with a gesture. Which comes in handy everytime I go through the border.
At least on Android, turning off or restarting your phone will work as well. Because you must enter your pin or password upon first starting up rather than use biometrics. At least, that seems to be the default. It may be a setting somewhere to turn that off.
> 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.
Is there a practical way to implement this today with Linux? I know VeraCrypt supports hidden operating systems, but I think only Windows?
>usually, passphrases are only used to decrypt the actual encryption keys, so overwriting those keys should be super fast
I'm not sure if it's really that simple with modern flash storage. There might be no guarantee that attempting to overwrite some data will actually affect the particular memory cells where it is stored. You would probably have to trigger a secure erase to reset all memory cells and hope that it is correctly implemented by the storage device's firmware.
I think all of that could be easily implemented by logging into different accounts by entering a different password/passcode.
So UserA:regularPassword would be one’s usual account, but UserA:obviousToGuess123 would actually log into UserB, and UserA:ohshithelp would log into UserC which has a startup script to secretly call police or whatever.
Comments are full of gunpoint scenarios, but I think a far more likely scenario for most HN readers is law enforcement / customs agents asking you to unlock your device during travel or some other random checkpoint so they can scan it. In that case, I doubt the officer would even have a clue about the use of a duress password to selectively and silently delete some private data. I think the biggest risk would be that a scan of your device could detect the PAM config and duress script which could be a flag to monitor you more closely, or might possibly be considered illegal itself in some jurisdictions.
Technically you'd also need to rewrite the logs in a plausible manner (removing the mentions of the PAM module and potentially replacing it with their "normal" equivalents) and depending on your threat model, actually securely erase the files so that disk recovery software can't later restore the deleted files.
If your threat model is someone that will even invest the time to sift through your logs, it might be wise to disable (persistent) logging in the first place.
> Forensics agent pulls and mounts hard drive
> Agent sees /home/hiddenuser
> Government seeks search warrant for content
> DA demonstrates recent knowledge/use of /home/hiddenuser
> Judge holds you in contempt until you provide encryption keys
Forgetting the keys is established as protected speech under 1A. Don’t have the case handy atm. Fairly new. Knowing the keys and intentionally withholding them has yet to be established either way. But there will be a case soon enough. Funny thing about law is that both sides (prosec. & defense) often don’t want many things clarified further because they usually have far-reaching impacts to parallel legal issues. Roe v Wade is a perfect example.
No basis for such a warrant for some US citizen entering the country. No such case has ever occurred, at least at the time when I received legal advice on the subject.
Consider the alternative: You're not worse off than you would be if you didn't hide it.
Hiding your login is a good security practice against all kinds of potential coercion.
Is this what the typical airport threat scenario looks like? How do they do this with soldered in drives?
> Agent sees /home/hiddenuser
Or they see nothing, because your drive is encrypted. They come to ask you for the key, you comply they see $blandaccount with some seemingly important company data and a scary corporate message as the desktop background (as justification why there is even encryption). Bonus points if you complain about it yourself ("If you ask me all of this is a bit paranoid"). Afterwards you use the real key and see $realaccount, because you thought about plausible deniability and how to use it propperly – if you still trust the integrity of your device, that is.
I don't know the legal implications, but if the duress password unlocks your device and simply deletes a directory or two, and the officer only asked you to unlock your device (without a warrant, by the way), how is that lying?
Despite rumors to the contrary, the police aren’t stupid. They are trained to ask questions in ways that elicit a confession or falsehood.
The simplest example is asking “Do you know why I pulled you over?”. Typically, people spontaneously confess to speeding, sometimes they break down and admit that someone is wrapped up in a rug in the trunk.
The courts have consistently ruled that customs is different and you can be searched without a warrant. Don’t cross borders with contraband or evidence of criminal acts/dissident identity/your email correspondence with foreign agents/etc.
>The simplest example is asking “Do you know why I pulled you over?”. Typically, people spontaneously confess to speeding, sometimes they break down and admit that someone is wrapped up in a rug in the trunk.
I was asked this once, after I read a hilarious reddit comment, and found myself in a similar situation. I looked at the cop and said "it's not because of the pot in my trunk is it?". "Step out and open your trunk, sir". He opened the trunk to find a crock pot I had just purchased. I could tell he was flipping through emotions from stifling laughter to being highly annoyed. They eventually let me go and told me to slow down with a half smirk.
I don't recommend doing this, and I have zero plans to ever do it again as it wasn't as simple as stepping out and showing my guilt/joke. I was detained, backup units showed up, even a K9. They didn't search the inside of my car, but they did inspect other items inside the trunk to make sure I wasn't pulling a fast one on them.
Yeah, what you did was not smart. If you're being pulled over for a minor traffic infraction and you already know that you're guilty, simply admitting to it is usually the best option. I've gotten out of many tickets this way, because cops really do appreciate when you're not trying to BS them.
I was also pulled over once and accused of running a stop sign that I knew I didn't run, because I had seen the cop sitting there as I pulled up to the stop sign and made extra sure to completely stop. Due to the time of day, I believe he was (illegally) fishing for a DUI stop, and had considered filing a complaint with the department but never did.
Why wasn't it smart (besides actually talking to the cop)? I was not guilty of anything but making a joke in bad taste (and maybe doing 59 in a 55). It was an inconvenience to be detained for an hour, but it wasn't a hot day, I didn't have any obligations...
>simply admitting
no your best option is not to say a GD thing. story time: i was once pulled over on the eastern shore by a cop that was barely my age. i didn't say a word to him for the 10 minute stop. that really messed with his mental state and I could tell his internal hard drive was returning a seek error. at the end he stammered out "o-okay, w-well you slow down and haveaniceday" then he quick walked back to his car and turned down a side road.
You gave the cop probable cause to search your vehicle. That is never smart.
I'm sticking by what I said. As I clearly said in my post, I was only referring to minor traffic infractions where you know you're guilty. I guarantee I would have gotten some or even all of the tickets I got out of if I had blindly followed "NEVER TALK TO COPS" advice.
1. The probability of your being in a stressful situation without the option to leave is high - you probably arrived via plane, so you can't simply go back, and you don't know the local laws well.
2. You usually know that a customs checkpoint is upcoming.
So, in that case, it's far better to prepare (i.e. don't bring things you don't want searched/compromised) and cooperate.
I was once "detained" whilst going from France to England while the customs official searched my bag.
I complained to the UK immigration and the same customs officier called me back, searched my bag again, and said "unless you agree to withdraw your complaint, we are going to have to continue searching your bag until the train departs and you miss it".
i.e. costing me about £150 in expenses.
As expected, I withdraw it and went on my way.
However I now make a point to record the name / number of custom officials I make a complaint to -- in case they turn out to be jerks like the UK one was.
Everytime this is posted I feel the need to mention to Brits specifically: this does not apply.
"It may harm your defence if when questioned you fail to mention something you will later rely on in court".
Failure to answer can seriously harm your defence and I've heard of people I personally know (though I wasn't in the courtroom) where the prosecution hammered the point that they "came up with a plausible sounding story" after the arrest.
Obviously Border Patrol is not the same as being arrested; but this is an important caveat for the video posted.
Talk to british police. If you feel like lying, keep your story straight or give basic facts.
The right to silence began in England and it's only because of the endless undercutting of rights going on there and the lack of backbone for standing up to this (liberalism is now seemingly a historical footnote for the UK) that it has caveats, the right to silence has still not disappeared entirely.
As even the Wikipedia article on it[1] notes:
> If this failure occurs at an authorised place of detention (e.g. a police station), no inferences can be drawn from any failure occurring before the accused is allowed an opportunity to consult a legal advisor.
The "Don't talk to the police" is not the full point made in that video, it's "Don't talk to the police… until you've spoken to your legal advisor and not without a legal advisor present".
So, *don't talk to the police*, they're not your friends and they don't have your best interests at heart and it's their job to get evidence against you, not yours.
>"Dr Heizenburg, do you know how fast you were driving?"
>"No, but I know exactly where I am"
To which the police officer replies "You were driving at 145 km/h!"
Heisenberg whispers to his passenger, "Great Erwin, now thanks to this idiot we're lost". The officer overhears him, and angrily orders them out of the car. He searches their glove compartment, and then opens the car boot. He reels back in shock:
Yeah but one other thing to consider is just how technically advanced having a duress password is for the average joe. I think about it like this. Say you're a CBP border agent on the US/Canada border. You inspect peoples phones for images of contraband, etc upon entry. You probably inspect ~150-200 phones per day, now say among the sea of people that are coming through, one of the people's whose phone you searched was actually in "duress mode" and was hiding the real data on the phone. You can't tell me an officer is going to pick that out unless it's something really obvious.
I would go as so far as to say that most border agent's that search phones are probably not even aware that this is a thing that people do. Sure they might have gotten training in a classroom for it, but as far as real world experience goes, maybe 1 out of every 5000 people has a setup like this.
Even if it isn't lying, it's destruction of evidence. 18 U.S. Code 1519:
> Whoever knowingly alters, destroys, mutilates, conceals, covers up, falsifies, or makes a false entry in any record, document, or tangible object with the intent to impede, obstruct, or influence the investigation or proper administration of any matter within the jurisdiction of any department or agency of the United States or any case filed under title 11, or in relation to or contemplation of any such matter or case, shall be fined under this title, imprisoned not more than 20 years, or both.
> investigation or proper administration of any matter within the jurisdiction of any department or agency of the United States
I mean, you’re not seeking to obstruct anything other than a federal agent looking at your personal pictures, which they explicitly do not need to fulfill their duty.
Now if you were removing evidence of your crimes.
Anyway, I know it doesn’t work that way, but I think it should.
Not clear. You can argue you were afraid for your life or property in the case you did not expect the agent or courts to react reasonably to the now-concealed information. As well, they would need to prove you concealed or destroyed information.
Similar case law exists in this context, but for actions like running from the police.
Do not do this unless you have strict guidance from a lawyer immediately before this happens. One small mistake could open you up to criminal liability and a world of hurt. Better to just plan ahead, bring a burner phone and show the photos to the agent when asked.
Are you insane? Going along with the courts is usually not in your best interests. Hiding the evidence and never going to trial certainly is. If we are talking about information that you definitely need to hide then the penalty for your obstruction of justice, whatever its form, will be a rounding error on your sentence. If it does not definitely need to be hidden then should they find out they are unlikely to charge you.
An attorney will tell you what is legal. An excellent attorney will tell you what you can get away with.
Strong language I know, but prisons are full of innocent people.
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.
Scanner is something you look in with both eyes. And then while your eyes are completely hidden you close one eye.
Heck. You could set it up so that it scans both eyes and then does a second scan where you choose what your ok signal is (both eyes, right only, left only, no eyes).
Yeah i think technicaly it could work. But I actually think that is a terrible idea. Humans have a lot less self control then we think. This will lead to many false alarms.
Also consider that most of us recall an oft-used PIN as much via muscle memory as a pattern on the keypad rather than as the actual digits, which would make ROT5'ing it that much harder.
I hate when my bank calls me about something and then asks to confirm my identity prior to giving out details about my account. Even when I think I know what it is about (e.g., a transaction with my card was declined just before the phone call), I feel very strange giving out any information to an inbound caller.
One thing I have thought about doing is providing mistaken information to the caller and see if they go along with it. I came up with this idea when one bank said they could send me a text message and I could read back the number to them (huge red flag).
Does anyone else have any ideas for how to authenticate a BigCorp caller whose corporate policies do not allow them to provide any account information to the people they are calling?
> Does anyone else have any ideas for how to authenticate a BigCorp caller whose corporate policies do not allow them to provide any account information to the people they are calling?
I mean, it's really their problem, isn't it?
If you need something from them, call their customer line and ask. If they need something from you, then they'll figure it out.
I had a financial institution call me one time and ask
"Is this nucleardog?"
"Yes."
"Alright, this is reallyfastwords can we start by verifying your date of birth?"
"No. You called me. I didn't even catch who you are. What can I help you with."
"I'm with really fast words. I can't tell you anything until I verify your identity."
"You called me. You verify your identity first."
"If you don't verify, then I can't tell you why I called!"
"That's fine."
There was a loooong pause before she finally decided on "Okay, what _day_ in June of 1985 were you born?" and apparently that was satisfactory.
Banks themselves tell you not to give out their info, so that scenario plays out more often than you think. I've had it happen and they just sent a letter by mail instead.
Google called me wanting to confirm my business address and asked me a bunch of personal details, as well as a 6 digit code that was going to be sent to my number (the one they called me on?). I refused and told them to give me a number to call them back on and they said they didn't have that facility. I then asked if they could email me or point me to a form and they said they could only do it on that same call.
After 10 minutes in a verification tug-of-war, the rep escalated me to someone who did provide proof they were actually Google (using a field I updated in my account). All up it took 15 minutes and felt very fraudulent until they finally gave me some helpful context.
> told them to give me a number to call them back on
I hope you managed to communicate that you needed it to be able to independently verify that this number belonged to the purported caller. Eg, if it's from your "credit card company", the number should show up on the credit card company's website.
And they are starting to understand more and people know that too.
Typically banks, when challenged here in Australia, will ask you to hang up and call the number on the back of your card (debit or credit).
Normally they give you a reference number so when you are speaking with someone, you can bypass things and pick-up with the person you were originally speaking with.
>Does anyone else have any ideas for how to authenticate a BigCorp caller whose corporate policies do not allow them to provide any account information to the people they are calling?
Definitely. Hang up the phone and call the phone number on the card associated with your account or look up the appropriate telephone number and call them back.
If they're legit, they will be perfectly fine with that. If not, they'll likely squawk about it.
Either way, the correct process begins with you hanging up without providing any information to the caller.
My bank will also send SMS "fraud alerts" with a request to confirm or deny a transaction. That's the same situation, IMHO and the right action is to call the known to be valid phone number for their customer service.
Perhaps there are other, fancier ways to do something like this, but as a general rule, scammers can't change the customer service phone number printed on your card, or hack third party services just to give you a fake phone number online.
Wait a couple of minutes or call back from a different phone. In the UK it may still be possible for an attacker to hold the line open after you hang up - and then simulate the dial tone.
I've heard this, but I don't understand it. Doesn't the UI feel completely different when it comes to placing a call versus using the keypad on an existing call? On android at least you have to explicitly show the keypad.
How? If I explicitly push the red button on my mobile phone, how does the line still stay open?
I can understand this attack via land line, but who seriously has a land line in 2021? Even my 93 year old grandma has a mobile phone. (Albeit we did get her one that looks like a land line phone :D )
My grandmother (80s) and her circle of friends all use landlines to communicate. Technically her's is a VoIP line since about six months ago, but it's designed as a drop in replacement (uses the same phones/numbers) so I wonder if there's a possibility the attack is still open.
I also use a landline fairly often (mostly out of habit), and most companies only have my landline number as I don't want them contacting me while I'm out/busy.
You're right that it's a dwindling number, but it's certainly not at zero yet.
Yeah that works, but it's usually time-consuming to get to the specific department that actually called. I wish these companies could route your call to their fraud dept if their fraud dept had just called you, but sadly this doesn't seem to have caught on yet.
In Singapore, Banks send regular reminders that they will never ask us for our personal information over a phone call. It is slowly becoming "common knowledge" among the non-tech-savvy folk I meet in everyday life.
Then there's an antifraud scenario, when the bank still calls you and asks stuff, now you need precise classification what they can ask you and what you can tell them.
Most banks here (UK) have a mobile app, so I've always wondered why they don't use that to auth the call?
Bank: Hey I'm calling from HSBC, want to verify it?
Me: Sure
Bank: Ok, so open you mobile app, and enter 637482
Me: Ok, cool thats given me 274893
Bank: Yep, that's all confirmed so ...
That would save you giving out personal details to authenticate yourself, but may lull people into dropping their guard & divulging personal details before the bank authenticates on _their side_ — as in, nothing in that script prevents a scammer saying "Yep, that's all confirmed" no matter what the person says & then a lay person may feel more secure even though they've proved nothing
I was thinking more that once you put the code in, it says that it is a valid call (or not) then you get the response code to give back - at that point they can continue as normal
This is exactly why I’ve thought of giving a fake reply, since the only way for me to know that they’re who they say they are is to see if they can recognize both an invalid response and a valid one.
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.
The feature exactly like that exists in Xiaomi phones. It's called Second space, and basically allows you to have second profile with different apps or accounts. Interesting thing is that you can set it up to open when unlocking the phone with specific fingerprint. The idea is to fill that Second space with dummy info, and unlock it with your little finger, for example (or vice versa, use it for sensitive information). Obviously, it wouldn't fool thorough phone scan (and if you dig deep enough in the settings you can see if the feature is enabled) but can be useful at quick cursory scans, like if you need to provide your phone at the border
Why would being security conscious automatically disqualify biometrics?
Security is all about threat models, and I can imagine quite a few scenarios where biometrics might fare better than passwords. Shoulder surfing and trivial passwords/PINs come to mind, for example.
And who said that it's biometrics vs. anything else? It's quite advisable to combine authentication factors.
Shoulder surfing and weak passwords are both something you can control at any time. Biometric identification can be exploited involuntarily by someone literally using force to apply your finger to a device or similar. I shouldn't need to say this, it's so obvious that it's a common plot device in action movies.
If you are so easily swayed, you would probably not be in an adversarial situation with a government anyway.
But this article is about a system for giving up passwords under duress without necessarily compromising all your security, such that your antagonist has no way of knowing or showing that there's another password concealing more important information.
Pretty sure Guantanamo Bay and “enhances interrogation” has shown us that after your antagonist has used the $5 wrench to beat a working password out of you, they then keep on beating you every day for another few weeks just in case there’s more you should have told them.
If “those guys” are your adversary, you were fucked before you started.
> If you are so easily swayed, you would probably not be in an adversarial situation with a government anyway.
Complying in the face of threats of physical violence is equivalent to "being easily swayed"?
You seem to have a pretty specific threat/defense model that you didn't clarify. I wouldn't generalize from that to "biometrics are bad for all users in all situations".
People who realistically anticipate opponents (the state, kidnappers) using force to get at information on a personally targeted basis are likely willing to deal with a degree of real pressure, as shown by the long-term intransigence of many political prisoners through history.
What I'm saying is that if such threats are unacceptable to a person, chances are they are not going to involve themselves in the sort of activities that require keeping secrets in the first place, or are sufficiently disciplined to have weak device security because they don't write anything down.
> Shoulder surfing and weak passwords are both something you can control at any time.
How, exactly? And "require users to watch out for shoulder surfing and use strong passwords" does not count.
Any chance you are thinking about pretty specific circumstances here (security-aware, technical employees generally not having to enter passwords in public spaces)?
I don't understand why you wouldn't think those count. At some point security rests upon the discipline and good judgment of the person with information to secure. I don't believe you can make a technological system which offers perfect security and perfect convenience. Biometrics are very convenient, but can be exploited by force. Strong passwords and environmental awareness (of snoopers) are quite robust, but at a considerable loss of convenience.
Sure, but nobody can pre-emptively mandate you use facial recognition on your personal communications device, and then put sensitive information in there. I can see a situation in a repressive country where if you buy a phone they set it up with facial recognition in the store and make you activate it, but then you know not to store stuff there. You could just physically damage the camera at a later date and claim you weren't able to make use of that any more.
I've a device (Onyx BOOX) which apparently can only be password-secured if I create a vendor-based account on it. (I've been trying to see if this is bypassable, so far, no dice.) That's not biometrics, but it's a case of being strongly limited by a system architecture.
If you're using a device at the obligation of an employer, you may well find that it has, and/or organisational policy requires, biometrics.
It's increasingly difficult to find devices that don't include some form of biometrics-based functionality. The notion that that becomes the primary or only means of securing access is not entirely far-fetched.
Capabilities, possibilities, and dependencies have a really funny way of becoming hard requirements over time.
I could speak the Celtic of my ancient ancestors or communicate in cuneiform or ancient Egyptian hyroglyphics, if really wanted to. My ability to integrate and participate in modern life would be quite limited. The online and digital world are rapidly approaching this state.
You can push the lock button many time (when pulling you phone from the pocket for example) and it will require lock the phone and require to use your passcode
I don't think they hide their existence from each other however. If they're like Unix users, then one might see something like /home/user1 /home/user2 /home/user3, etc. so that all usernames would be clearly visible and the user could be then forced to reveal all passwords. The aim is to obtain plausible deniability, that is logging in as the safest user according to the situation, while at the same time hiding all others.
I'd love that feature (android 9+) if it allowed me to install some of the gazillion apps (e.g. every bloody fast food place that only has deals via their app) but restricts them from accessing my real user contacts, emails, msgs, gps/location, etc.
Blackberry phones had this feature and it was pretty bulletproof.
I believe users cannot access each others' data. So yes you can use it this way. I'm pretty sure it existed at Android 9. Are you running stock Android or some Samsung bull?
It uses the same authentication system everything else uses, so it would work in any login screen on a system that uses PAM (Linux and macOS), not just a terminal.
There's always a big issue with systems like this: Any sophisticated attacker will have an image of the machine he's trying to get into at hand to stop exactly what this pam module is trying to achieve from happening.
All this would do is make you appear in a worse light to the deciding judge when it comes to trial or get your other kneecap shattered in a not so civil situation.
So you're saying if I'm held at gunpoint or forced to surrender my password at the US airport that a password to clear my account of anything would be useless?
Neither of them know anything about me.
It reminds me of the Trezor hardware wallet that allows you to have multiple passwords into your account. If your forced to give access you can log into the version with little in it. Nobody knows that you have secondary accounts with more in it...
If you're held under gunpoint, that script that wipes your entire hard drive will only make your day worse.
AFAIK if you actually get detained and questioned at airports, your drive will already get imaged before any password is even tried. You may be able to get away with this on a mobile device where this feature isn't generally expected (because who uses Linux on a smartphone in the first place).
I always wonder at what scenarios like these are supposed to be about. If saying no is not an option, pissing off your captors by giving them fake info probably isn't either.
I don't know what law enforcement would be looking for on my work drive, but if saying no is no longer an option, my encryption password isn't worth getting shot over.
The “real” problem is either: (a) You know the authorities want access to your data because <x>, and you travel across a border with it. (b) You possess sensitive information and are not aware of law enforcement’s desire to get it; (c) You’re swept up at random; (d) You’re a criminal, or carry a paper trail of potential illegal activity.
Solutions:
(a) Means you are stupid. The only way to win is not to play.
(b) Means you either didn’t follow your employer’s security guidelines or aren’t aware of the risks associated with whatever is on your device. You can’t solve that problem without understanding that.
(c) You should use discretion re: what you cross a border with and either accept the risk or do something else.
Which is the same as (a). Either have an USB stick with plausibly-deniable encryption or, better yet, store the data somewhere online (in encrypted form, of course) and download it once you crossed the border. There is no reason to have it readily available on your laptop.
I think the focus on Law Enforcement as the sole source of duress is no longer correct. Just as one example, we now live in an era where any entry point to a corporate network can equal millions or billions in eventual ransom payouts, right? As endpoint security mitigations improve, duress will not just be a silly nerd porn, and will probably not be limited to "high level" people, either.
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.
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.
If the attack is in hot the data is unencrypted, so getting the login password will (usually) also give access to the unencrypted disk (already mounted)
The duress credentials are exactly how you avoid the "pipe wrench" scenario. The point of the FDE in that case is simply to prevent them from looking on the disk without your supervision.
If the pipe wrench is getting applied regardless, that's a much different situation. In that case you could simply not comply at all.
The duress credentials are meant to create plausible deniability of non-compliance, by giving the appearance of a genuine login which just reveals nothing.
Keep in mind that the duress credentials serve several purposes.
1. Give the appearance of compliance. It's possible that the investigator will be satisfied and abandon further search attempts. Wrench averted.
2. Provide the opportunity to perform a duress action, without the immediate appearance of doing so. This has a wide range of possibilities, including removing or disabling access to information, triggering warnings or notices to allies or supporters, revealing innocuous content, enabling a set of additional countermeasures (e.g., attacks from within the investigator's own space or network, or against the investigator's own tools, see Signal's response to Celebrite: https://signal.org/blog/cellebrite-vulnerabilities/). Note that a protocol which denies the investigation subject access to a device would prevent this. The presumption that a subject would provide an access password provides opportunity for defences.
Whether or not the pipe wrench (or any analogous or equivalent means of coercion) is applied is almost a moot point. With a duress password, you're largely assuming it will be. The objective isn't to prevent the wrench. It's to render it ineffective.
Understood and agreed. This depends heavily on what the investigator expects to find. If the duress key removes information known to be present ... out comes the wrench.
Or you could just be dealing with someone who DGAF. This ultimately seems to be a chief characteristic of many situations in which strong crypto is proposed. It's the breakdown of civil liberties, rights, and rule of law which might be the true ur-problem here.
Why not honeypot into a docker with fake data? Everyone would be happy (during a first moment). Sure if the attacks t is well informed then they will double check whether the target they got in is real or not.
Lawenforcement yes, but I'm not sure most criminals are digital enough. Especially if it all looks just normal logged in, but in the background deletes some hidden files.
People who would want the data of someone knowledgable enough to install a custom pam module and write a script to utilize it are most likely also sophisticated and informed enough to know what to look for. This is not some street thug, it's most likely either law enforcement or organized crime who know very well what they want and that it's supposed to be on your machine.
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 if you get picked up by a “secret police” in the middle of the night it’s pretty much game over already.
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.
And these days, it’s common for the decryption keys to exist only in a Secure Enclave type thing that makes extracting those keys many orders of magnitude more difficult that asking you for your password while they hit you with a wrench.
My understanding is that, with veracrypt (which implements something similar to the linked system), if you enter the duress password, the hidden areas appear to simply be unallocated disc space.
Nice, pretty cool stuff. In high-school I worked on something similar (https://github.com/rafket/pam_duress), though this seems to have a somewhat cleaner implementation which is nice to see, and hopefully a more eager maintainer.
I’m reading the readme of your project, and got to the part where it says
> for example a mail could be automatically sent from his computer to a rescuer, a script could delete sensitive files in his hard-disk or a certain Rick Astley song could be appropriately played
And I’m just imagining someone having set two duress passwords; one for kidnapping situations and one that they put there as a joke. And then they get kidnapped and they try to input the one supposed to call for help, but they misremember so they input the rickroll trigger instead.
And the kidnappers are like “hey what the hell, you think this is funny man? turn that off” and the kidnapped person cries for having messed up their one chance at calling for help.
There are some issues with nuvious' pam-duress that allow for untrusted string inputs when handling scripts with system() call, and I sent a patch to them via E-mail in an attempt to highlight the issues and provide a basis for a better way to handle it.
Hey, just found that patch in my email. Will try to get that encoded into a formal issues on the project. If you have time yourself feel free to that or any other issue yourself. Also looking for 3rd party reviews on the PR's I have open now and into the future.
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...
The only way I can imagine remembering a duress passphrase is to make it slightly different in some way.
So that means I'd have to keep updating my duress passphrase alongside my regular passphrase.
Either way I love this idea and I might actually start using it. I'm just trying to figure out how to set a practical passphrase I will be able to remember. My passphrases generally are in muscle memory after having entered them for a few days.
Edit: A simple system I just came up with is to use one of the numbers in the passphrase and increment it by one to indicate each level of duress.
Interesting idea. I find that it's pretty hard to modify the end of a password though, I'm likely to press enter rather than add anything else. Probably a good idea to change the first character, so you have the rest of the password to remember that you're supposed to do that.
If you used that password twice two years ago when you installed the module and you're suddenly pulled in an interrogation room in a foreign country? When you have about one chance to enter it right while some very angry officers look over your shoulder?
This is why usually these trigger-passwords are just a variation suffix away. If your real password was 123456 + Ok a system like that would trigger if you e.g. append a certain sign to it: 123451 + Ok. So you don't have to remember a different password, you just have to remember the one character or button that makes it call security.
If your threat model is “guy with guns,” they’ll just follow you and snatch it when you think you’re safe and unlock the device. If your threat model is “government at border” just mail the device or data to yourself overnight. Don’t be that guy…
I was flying into Atlanta (Intl) with “radioactive” rocks (not on purpose, just picked some up near a volcano, they looked cool) and they flipped their collective shit. I was taken to a separate area where they dumped my stuff next to another guy who got pulled into “routine” inspection. This other guy “forgot” his phone pin earlier that day… he was still there four hours later, after my four hours of reasonably straight forward BS.
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.
Hey, saw this as mentioned earlier and incorporated your feedback and one other commenter that pointed out a privilege escalation vulnerability. If you have a spare moment would appreciate your critique on the resolution to your concern and/or any other issues you see generally with the codebase. Just a request though, regardless thanks for your feedback!
I may actually incorporate that into the system() call in the module itself now that I think about it. The Hello World implementation was just a quick way for me to debug while I developed it and it's probably smarter to dump it to /dev/null by default.
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.
You have the freedom to do whatever you want with the script. It's trivial to `exec >/dev/null 2>/dev/null` first thing in a script if you want it to be silent.
Are you seriously writing a script when the cops are at your door? No, you aren't. You always need to verify that your protective mechanisms work before actually relying on them.
As I alluded to in my original comment, you might not pick up on a transient error like an I/O error during testing. This is exactly the sort of thing a sensible default setting in the program should cover.
I'm sorry but error handling and testing requirements are true for any software or script a person writes. The application should not give a shit, and a simple execve() is the best way to go about it. It's the principle of least surprise, and people have had to keep in mind fork/exec semantics for decades.
5 years on we're somehow all managing our own crypto keys, the phone is the key to unlock our digital lives, so we're all in the counterintelligence game. more tools like this.
Good old US. Land of the free. Canadian border agents are equally bad, in my experience. Guess it's just part and parcel with living in the Anglosphere.
I think it should be pretty trivial to have a hidden dualboot, let's say you have some plain boring Windows that takes 10% of you drive and 90% is unassigned. In reality that's encrypted LVM disk with bootloader on a flash drive that is easily tossed away if necessary. Or zapped in a microwave if you watched too much of Mr. Robot.
Do not carry devices with sensitive data around if not necessary, simple as.
All this hidden user stuff will go nowhere.
Have the data encrypted on a server and access it remotely.
Anything else is simply not safe at all or might cost you prison time, check the UK laws on this.
I mean, that's pretty cool, but who enables password logins for SSH anymore? If I'm an attacker, I'm going to wonder why my target of duress is giving me a password and not a private key; most likely if I have access to my target of duress, then I have access to some kind of client / endpoint that my target uses to connect to the network, and that client will have the SSH private keys likely already loaded into ssh-agent.
Maybe a more modern concept would be to both a) have a duress private key, that triggers duress scripts in the same way, b) an implementation of ssh-agent that adds the duress private key when a duress password is entered?
Yes, and perhaps _not_ use pam_duress for remote logins, in case you want to keep your duress password simple (think "password" or something similar, actually memorable in a duress situation).
I use an authentication PGP subkey for SSH so I have to unlock it with a passphrase before using it. Normal SSH keys can be encrypted similarly, and either gpg-agent or ssh-agent can save your passphrase in memory for an amount of time.
Alas, work in this space appears to be abandoned, too bad too because much could be done to improve robustness when writing with umounted aspects, or preserving security against attackers that can take images of the disk at different times.
Not to mention: integrating the results in standard software so the mere presence of the software on your host doesn't harm the deniability.
You could set this up with three possible passwords, #1 for normal login, #2 for what looks like normal login but deletes most sensitive things and #3 that wipes the disk encryption keys and reboots. If forced by criminals or a not so free government enter #2 and pretend everything is normal. If pressured by the US or EU government with your lawyer present enter #3, see it fail and claim you forgot the encryption keys to make it boot (which is technically true, just never admit you made it delete them since that's illegal in most places)
Using #3 could land you in jail indefinitely in the UK I believe: if they don’t believe you forgot the password, they can interpret that as a refusal to give them the password (or unlock the computer), and jail you for this… until you give them the password.
Which you can’t, because there is no password at this point. So either you admit that you just wiped your computer with the panic password, or you can shut up and rot in jail until you die.
You need a way to make them believe you. Covertly wiping your computer is probably not going to end well.
Author here; #3 also defies the use-case for a duress word. The attacker is supposed to be presented with what appears to be a normal login scenario while in the background sensitive data is being scrubbed or even have the routines remove the pam-duress module completely so there's no evidence there was a duress routine in place.
Real law enforcement agencies would also simply confiscate the device and hand it to a forensic team to pull a "golden image" from it to work with in lieu of a user session.
It's a theoretical thing under the Regulation of Investigatory Powers Act, IIR. It hasn't been tested. In practice under the law it'd probably be a stretch under a sensible judiciary since you can't prove a negative and thus can't prove you don't know something.
In a number of countries there is a defined offense, like in Australia if they don't believe you they can jail you for six months under the Cybercrime Act, 2001, or possibly 2 years (failure to obey a court order under the Crimes Act, 1914).
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.
Author here and I wasn't really thinking of this as a useful use case either. Most of my consideration was say corporate espionage or journalists working in authoritarian countries where killing the person would create a highly visible incident. Mostly was just a thought-experiment turned into a real implementation. With any tool like this the risks/benefits should always be considered.
Nice idea! I have this on my social site, people have two passwords, their regular one and an 'under duress' one that wipes their profile/locks it down.
I always wondered why more services don't offer it.
The reason we have it is it's a fairly political place (not by design, but when you offer 'free speech' you get everyone booted from every other place) and we've had a fair few members arrested, and I'd hate to think my site contributes to that so easy wipe.
Just like how ancient games and screen savers had a “Boss Mode” shortcut that showed a fake screenshot of Excel or whatever, all modern devices should have an “Allow limited or fake access to someone else to avoid the socially awkward situation of saying No” option.
Call it Duress/Panic/Boss/Jealous Boy//Girlfriend/Puritan Family Mode or whatever.
iOS has something called Guided Access which sorta helps a little bit but is very obvious to the other party.
This is a joke, but the person under duress also has to sell that they are under duress. This isn't something you can really "train" the average person to do on command.
It reminds me a bit of Jon Lovitz Pathological Liars Anonymous bit. "Okay! Here's the password...ya that's the ticket."
Duress password "1234", just make sure you have a very good backup and disable SSH password login. Anyone trying to snoop around is going to trigger it.
perhaps i could use that as a screensaver password to share with my girlfriend? it would close spreadsheets, emacs, un-mount journals and personal drives. PAM's used to reauth from the screen-saver, right?
Yes, those _are good, i have an Alt-F9 alternate desktop for guests, but a 2 letter password for her to bypass the screen-lock and change the music or something would in fact remove my sometimes duress, i think..
if passwords also covered account scopes -- which is what this tool enables one to monkey-patch into the OS, i could give you my password so you could gorge on my code without me having to worry about you reading my journals or abusing ~/.ssh
other than that, i second your notion.
I'm thrilled by the idea of using passwords to switch between the sorts of things i do without having to log-out.
This could result in serious personal harm if the individual(s) causing the duress sense something is up, which they almost certainly will if things start magically disappearing or locking up. You better make sure that whatever you are protecting with this is more important than your personal safety.
Your safety is compromised, but that does not mean the danger cannot be escalated. If you are mugged at gunpoint, are you going to hand over all your cash and keep your hands up as much as possible or are you going to swiftly cut up your credit cards?
For sure; there's risk/benefit to this kind of mitigation. One thing to note is all the actions occur before the user drops into a shell (or for desktop login the desktop rendering). If one is simply getting rid of LUKS containers or deleting VPN credentials it wouldn't take very long at all.
One could even write in a routine that removes the duress module entirely so it's a one-shot duress password that cleans up sensitive data, notifies anyone who needs it and then immediately removes all evidence that pam-duress was employed.
But you are right this is a tool with risks/benefits and the risks changed based on what's being protected and the context of the coercion.
It started as a simple weekend project based on an off-hand comment someone made in a security professional chat I'm in. I had used duress words in military and translating the concept to a PAM seemed like a fun exercise. Also supports my current shift towards swapping careers from pure software engineering to cyber-research or cybersecurity generally. So in the end, it was a weekend project that served a dual purpose as a resume stamp.
The design use case I had in mind was more benign; such as corporate espionage or journalists getting their devices confiscated (maybe keep a sticky note on the laptop that has a duress password on it as a red-herring). Comments to the effect that law enforcement would image a device are very relevant as any competent law enforcement agency should have their staff trained to get the device fully powered off and hand it to someone that can maintain a chain of custody and get a golden image for use in potential criminal charges.
One thought I had was to apply this to SSH auth for honeypots and if a rockyou.txt password is attempted it runs some routines that aid in crafting the honeypot before the intruder drops to a shell prompt. Another even more light-hearted implementation could be you have password X is the one you login to normally and your "duress" password Y just clears your browser history and is the one you give your spouse for when they log into your computer :). I'm sure there's use cases in the full spectrum and with it being a relatively simple implementation with user generated scripts, it'd be easy to extend to any potential use case.
In any case I'm glad it prompted such a good discussion. Feel free to submit issues if there are particular feature requests or bugs that one might run across. Additionally if there's a PR up, I'm currently the only dedicated dev on the project and welcome anyone that wants to review my PRs; always prefer a 3rd person review even on my own projects. I created a demo video using Pushover and in the process of doing the demo uncovered some bugs that I patched as well as some fixes to the documentation. Again, glad you all found this interesting and humbled it fostered such a good discussion.