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

Show HN: DeathSwitch

deathswitch.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Show HN: DeathSwitch

#41

Post by cbhl »

Anyone who's interested in an idea like this might want to see if Google's Inactive Account Manager is right for them. (Disclaimer: I work for YouTube, which is part of Google.)

It triggers if you don't sign in to a Google Account for X months, where you choose X from 3, 6, 9, 12, 15, or 18.

You can provide up to 10 contacts (email addresses, phone numbers, and custom messages) for people whom you want to be notified once the timer expires. You can also grant them access to the data from your Google Account; they'll need both the link in the email as well as a code from an SMS sent to the phone number you provided for them.

You can also choose whether you want your account to be deleted if the Inactive Account Manager triggers.

Re: Show HN: DeathSwitch

#42

Post by chk »

steakejjs wrote: post #22

You've got to be kidding me. Despite the policy difficulties of running a site like this (when is someone dead?, how long until release of secrets?, how to deal with lack of access to emails? etc), This site is completely insecure. https://www.deathswitch.com/members/myaccount.php is vulnerable to a CSRF hijack through the update email page. This literally took 20 seconds to find...who knows what would happen if I de…

Can I ask how you identify issues like this so quickly? I'm an infosec student, and I'd love to hear what your thought process is when briefly looking over the security of a certain website.

Re: Show HN: DeathSwitch

#44

Post by D4AHNGM »

Kinda weird you've implemented SSL/TLS everywhere except the home page. Surely that's not a deliberate omission?

Also, as much as I hate to be a pedant, spelling mistakes/missing words on the homepage look sloppy:

"The people in your life will feel better knowing they can expect an email from your after you’re gone."

"you canlog back"

Re: Show HN: DeathSwitch

#45

Post by javert »

copperx wrote: post #31
javert wrote: post #27

Earlier quoted context omitted.

> Posted this in another thread but what company would you trust to launch and maintain this kind of service? A law firm. That is the "correct" answer to this problem and is what people actually use.

What about life insurance companies? It could be offered as an "addon" service.

That's a pretty good idea.

But in reality, they probably wouldn't make enough money from this for it to be worth the trouble to them.

Re: Show HN: DeathSwitch

#46

Post by javert »

caio1982 wrote: post #8
rpedela wrote: post #4

Interesting idea. I think my father might be interested. Every time he flies on a plane (not often), he lets me know where various financial information is and the passwords to get at it. The pricing seems really strange to me. Wouldn't only messages be sent when someone is dead or severly disabled? A model similar to life insurance makes more sense to me where the customer pays a small amount of money on a yearly ba…

So your father and also I would be interested. But I really doubt a service like that would last given the current startups scene we have now. It must be rock solid. Fully dependable. It's life-and-death business here. I'd pay a good amount for this kind of solution.

> I'd pay a good amount for this kind of solution.

Use a law firm.

Re: Show HN: DeathSwitch

#47

Post by mercer »

nedwin wrote: post #18

Posted this in another thread but what company would you trust to launch and maintain this kind of service? You need to know that when you kick the bucket in 10, 20, 30, 40, 50 years etc that the switch is actually going to work. You need a company with the right moral compass; funding to pay for hosting, maintenance etc; and the longevity to keep going for the next 100 years. Companies on the "maybe" list for me inc…

To me it seems that there are two separate problems: 1) storying the information you want released upon your death, and 2) keeping it secure until that time.

For storing, perhaps a torrent or blockchain approach might work, where the encrypted data is stored on the computers of many users who 'buy into' this.

For release, I still feel that the safest way would be to give the 'key' to a trusted person (perhaps along with your will?). Any other approach leaves something so important too uncertain.

Re: Show HN: DeathSwitch

#49

Post by steakejjs »

chk wrote: post #42
steakejjs wrote: post #22

You've got to be kidding me. Despite the policy difficulties of running a site like this (when is someone dead?, how long until release of secrets?, how to deal with lack of access to emails? etc), This site is completely insecure. https://www.deathswitch.com/members/myaccount.php is vulnerable to a CSRF hijack through the update email page. This literally took 20 seconds to find...who knows what would happen if I de…

Can I ask how you identify issues like this so quickly? I'm an infosec student, and I'd love to hear what your thought process is when briefly looking over the security of a certain website.

I've got a lot of practice breaking things. CSRF can be identified really fast by checking for unique tokens. Some unguessable token should be submitted with each state changing request. If not, attackers can steal authenticated accounts by making a request to the "change PW" or "change email" URLs. It's a little confusing at first.

XSS I just set JavaScript as something that shows up in a field on a different page. The RCE I mentioned is just uploading a PHP file for the "file upload" feature associated with messages. If he puts the uploaded file within the webroot (and the file is php since his whole site is php) then the file will be executed when you go to its URL

Web app security is something that infosec professors don't talk about at all (in my experience). I had to teach myself but OWASP is very good to get started. It also helps to write a lot of software as well since you'll tend to find pitfalls of doing things wrong

edit: If you would like to see more of the technical how-tos behind CSRF check this link out. It is a blog I wrote about CSRF and how one would actually attack someone with it. http://ejj.io/csrf-password-bruteforce/

Re: Show HN: DeathSwitch

#50

Post by chk »

steakejjs wrote: post #49
chk wrote: post #42

Earlier quoted context omitted.

Can I ask how you identify issues like this so quickly? I'm an infosec student, and I'd love to hear what your thought process is when briefly looking over the security of a certain website.

I've got a lot of practice breaking things. CSRF can be identified really fast by checking for unique tokens. Some unguessable token should be submitted with each state changing request. If not, attackers can steal authenticated accounts by making a request to the "change PW" or "change email" URLs. It's a little confusing at first. XSS I just set JavaScript as something that shows up in a field on a different page.…

Hey, I appreciate the response. BTW, I tried to follow you on Twitter via your website link but it said user doesn't exist anymore. :-/
Post reply on HN