Live data from Hacker News

Never Give Your Information To 10 Minute Old Startups

blog.ryankearney.com

41–50 of 185 posts

Re: Never Give Your Information To 10 Minute Old Startups

#41
post #27

Many folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of break…

Sorry, but I think you're being far too kind.

A policy of so-called responsible disclosure is a reasonable approach to take when dealing with an established product/service that contains a minor vulnerability, something potentially dangerous but unlikely to be exploited in the immediate future with serious negative effects.

In this case, we appear to have a new project run by people who don't know what they're doing, with a glaring vulnerability that had presumably already compromised 80+ people's sensitive credentials and in turn who knows what other sensitive information. Bringing it down as fast as humanly possible and loudly so no-one else gets damaged in the meantime is entirely justified in a case like this.

Re: Never Give Your Information To 10 Minute Old Startups

#42
post #27

Many folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of break…

He submitted this article after the vulnerability was already fixed. (I grant that the initial comment came before.) I'd be inclined to agree with you, overall, save for a couple mitigating factors in this case:

1) The founder's behavior in the other thread, including refusing to notify affected parties.

2) Such a simple mistake worries me about what else might be vulnerable in the application which is built to handle users' backup data, and for that reason alone, I think this article is extremely important right now.

Re: Never Give Your Information To 10 Minute Old Startups

#43
post #34

Earlier quoted context omitted.

I have mixed feeling about this. On one hand we all want to move quickly, get users, add new features, etc etc. On the other, security issues like this are just so vital that nothing else really matter if your data is not secure. It's especially true for a BACKUP SERVICE that promises ridiculous stuff like "99.999999999%" uptime on the frontpage.

we're incredibly sorry about all of this. honestly, this was all accidental. it was a pet project we started to toy with Glacier and a week later i accidentally hit the Like button sending a ping to my friends on FB. bless my friends for being so influential i guess. shame on us for using Rails carelessly. if you have any experience with startups, you'll know that 99% of the things you launch go nowhere--this project…

Classy response. Now here's your chance to take lemons and make lemonade. Clearly your pet project is something that people find really interesting and useful. So it went public before you intended and had some security flaws: oh well, that's in the past now. Write your mea culpa about how much you learned from this experience, hit the front page of HN again, sign up a bunch of users, and go get some venture capital. Good luck!

Re: Never Give Your Information To 10 Minute Old Startups

#44
post #27

Many folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of break…

I'm generally with you, but I do hope that this tarring and feathering will drive home one point:

Don't trust the client.

The user ID in the URL like this is a giant "try editing me and see what happens" sign, even if you came with no intention of providing unsolicited pen testing. I seriously doubt just this one person noticed.

Re: Never Give Your Information To 10 Minute Old Startups

#45
post #27

Many folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of break…

You speak of "responsible disclosure", but what about "responsible launch"?

If a backend is coded this poorly, it betrays irreparable and highly dangerous levels of idiocy, laziness, and lack of foresight in the ones who coded it. Everyone deserves to be informed of this blunder so they know to avoid this group like the plague.

Public ridicule and preemptive destruction of the brand is the only conscionable reaction.

Re: Never Give Your Information To 10 Minute Old Startups

#46
post #27

Many folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of break…

Sorry, but I think you're being far too kind. A policy of so-called responsible disclosure is a reasonable approach to take when dealing with an established product/service that contains a minor vulnerability, something potentially dangerous but unlikely to be exploited in the immediate future with serious negative effects. In this case, we appear to have a new project run by people who don't know what they're doing,…

Completely agree. Look at his responses to the security issue being brought up in the original thread [1]. This is someone who is clearly playing fast and loose with some frameworks, and people's information, and does not deserve to be given that consideration.

In his own responses, he says that he won't email the users! I can't imagine how upset I would be if this had my information. Access control for something like this is dead simple

[1]http://news.ycombinator.com/item?id=4619424

Re: Never Give Your Information To 10 Minute Old Startups

#47
post #12

Earlier quoted context omitted.

> Is it considered apropos to state how surprised you are that developers who come across as relatively senior are capable of making an incredibly fundamental security mistake such as this? Only if you're concerned that you can't tell who is "relatively senior." In this case, your judgement was unfortunately wrong.

'Relatively senior' here means 'ostensibly trusted with important tasks in the past'. Both of the creators of this application (I won't say 'founders of this startup' because that's silly) are ex-WePay.

I had to look up WePay on Google. The wikipedia page says they have 30 employees as of a year ago, did YC and 1 round of funding.

I have to be honest - that doesn't demonstrate a high level of trust at all these days. It's sad, but true. Plus, if you say they're "ex-WePay," I assume they were just everyday developers for WePay, not critical resources.

Re: Never Give Your Information To 10 Minute Old Startups

#48
Ryan, your post is NOT an example of responsible disclosure. You could have written your post and posted it AFTER alerting the Ice Box Pro guys and waiting until they had the main issues fixed. Your post would still be a good post. In fact, you seem to weigh the importance of your post getting on HackerNews above the security of the people who tried Ice Box Pro. The creators of Ice Box Pro had good intentions and messed up security (as almost any startup does to some extend). You are either ignorant to what security actually means or unethical, which at best is as bad as what the creators of Ice Box Pro did and maybe worse. Will you take responsibility if any of the users that tried Ice Box Pro get hacked as a consequence of your post?

Re: Never Give Your Information To 10 Minute Old Startups

#49
post #34

Earlier quoted context omitted.

I have mixed feeling about this. On one hand we all want to move quickly, get users, add new features, etc etc. On the other, security issues like this are just so vital that nothing else really matter if your data is not secure. It's especially true for a BACKUP SERVICE that promises ridiculous stuff like "99.999999999%" uptime on the frontpage.

we're incredibly sorry about all of this. honestly, this was all accidental. it was a pet project we started to toy with Glacier and a week later i accidentally hit the Like button sending a ping to my friends on FB. bless my friends for being so influential i guess. shame on us for using Rails carelessly. if you have any experience with startups, you'll know that 99% of the things you launch go nowhere--this project…

Contacted a PR person in between the last thread and this one, I'm guessing? That's a rapid 180.

You have a long way to go in my mind, in terms of fixing the initial response. You probably have help now, which is great, but your initial kneejerk demonstrates underlying trouble to me which you need to fix.

You're in a tough spot, too, because you can't delete those godawful comments without looking suspicious.

Re: Never Give Your Information To 10 Minute Old Startups

#50
post #27

Many folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of break…

You speak of "responsible disclosure", but what about "responsible launch"? If a backend is coded this poorly, it betrays irreparable and highly dangerous levels of idiocy, laziness, and lack of foresight in the ones who coded it. Everyone deserves to be informed of this blunder so they know to avoid this group like the plague. Public ridicule and preemptive destruction of the brand is the only conscionable reaction.

It sounds like it wasn't launched yet. The founders say they built it for themselves and their friends to start. Someone discovered the URL and posted it to Hacker News.

They probably should have shut it down or disabled registrations once it got out until it was tested.

Post reply on HN