Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PAM Duress – Alternate passwords for panic situations

github.com

Post reply on HN
Print view View original

351–358 of 358 posts

Re: PAM Duress – Alternate passwords for panic situations

#351

Post by tgsovlerkhgsel »

nucleardog wrote: post #220
gnicholas wrote: post #204

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 a…

> 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 thi…

> I mean, it's really their problem, isn't it?

They'll typically make it your problem by blocking a transaction or your account...

Re: PAM Duress – Alternate passwords for panic situations

#352

Post by jaywalk »

o-__-o wrote: post #349
jaywalk wrote: post #313

Earlier quoted context omitted.

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…

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…

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.

Re: PAM Duress – Alternate passwords for panic situations

#353

Post by stevenwliao »

solatic wrote: post #285
matrixagent wrote: post #279

Earlier quoted context omitted.

> All orgs should consider locking out all employees for at least one uninterrupted week a year. Very easy way to shake out all sorts of problems. Could you give some examples?

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 addre…

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?

Re: PAM Duress – Alternate passwords for panic situations

#354

Post by nuvious »

wowaname wrote: post #304
rafael859 wrote: post #15

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.

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.

Re: PAM Duress – Alternate passwords for panic situations

#355

Post by wowaname »

sleavey wrote: post #347
wowaname wrote: post #299

Earlier quoted context omitted.

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.

Re: PAM Duress – Alternate passwords for panic situations

#356

Post by wowaname »

nuvious wrote: post #354
wowaname wrote: post #304

Earlier quoted context omitted.

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.

I don't use Github, but thanks for confirming you received it, and feel free to take time to get around to it.

Re: PAM Duress – Alternate passwords for panic situations

#357

Post by nuvious »

sleavey wrote: 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.

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!

https://github.com/nuvious/pam-duress/pull/19

Re: PAM Duress – Alternate passwords for panic situations

#358

Post by Angostura »

sebzim4500 wrote: post #266
Angostura wrote: post #210

Earlier quoted context omitted.

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.

The UI feels exactly the same if you are using a landline.
Post reply on HN