Never Give Your Information To 10 Minute Old Startups • Hacker News Board

Re: Never Give Your Information To 10 Minute Old Startups

#151

Post by Evbn » Sat, Oct 06, 2012, 3:43 PM UTC

anonymouz wrote: post #137

smeagol wrote: post #70

Earlier quoted context omitted.

RE: durability: http://aws.amazon.com/glacier/faqs/#How_durable_is_Amazon_Gl...

Thanks, I would find it helpful if you could also explain that on your homepage. The statement "Amazon Glacier is designed to provide average annual durability of 99.999999999% for an archive" is quite clear and meaningful, but "Glacier is built for durability of 99.999999999%" just seems like a non-sensical marketing blurb. If I got my math right, this means that they expect to lose on average about 10 bytes per sto…

Yeah, it is more like 1 file in a 100 billion gets lost.

Re: Never Give Your Information To 10 Minute Old Startups

#152

Post by hollerith » Sat, Oct 06, 2012, 3:50 PM UTC

whyleyc wrote: post #141

hollerith wrote: post #132

Earlier quoted context omitted.

On Hacker News, you cannot delete or edit a comment except during the first 2 hours of the comment's existence.

Which answers part two of my question but not part one ...

Right. We're still waiting for an answer to why he published his critic's email address.

Re: Never Give Your Information To 10 Minute Old Startups

#153

Post by patio11 » Sat, Oct 06, 2012, 4:02 PM UTC

nikcub wrote: post #122

patio11 wrote: 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…

My own policy is that each situation is unique and in some cases you have to disclose details upfront. I believe this was one of those cases. The founders of this application were told in the original thread that there were security issues. They didn't respond to the issue and continued allowing users to signup. Their immediate response should have been to shut down the application with a maintenance page. Their resp…

I gave Diaspora advice on fixing the vulnerabilities then a week to do it prior to mentioning anything more specific than "There exist multiple very bad bugs here."

Re: Never Give Your Information To 10 Minute Old Startups

#154

Post by kcbanner » Sat, Oct 06, 2012, 4:35 PM UTC

gambler wrote: post #112

zacharyvoase wrote: post #21

Earlier quoted context omitted.

'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.

Working in a cool company doesn't automatically mean the developer is competent. Neither is working for a large corp for that matter. I've seen far too many examples of this, unfortunately.

Yep. This happens all the time.

Re: Never Give Your Information To 10 Minute Old Startups

#155

Post by jfoster » Sat, Oct 06, 2012, 4:35 PM UTC

JoeCortopassi wrote: post #46

Silhouette wrote: post #41

Earlier quoted context omitted.

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

But the privacy of a security disclosure shouldn't just be based on the company responsible for it. It should also take into account the fact that users of that company's product could be harmed by a public disclosure.

In this case I think the public disclosure would have two effects: 1. Put current users of the product at risk. 2. Prevent people from signing up for the product.

So the question really becomes, does 1 outweigh 2, or vice-versa? (and the answer to that also depends on how cooperative & quick the company will be with a fix)

Re: Never Give Your Information To 10 Minute Old Startups

#156

Post by nikcub » Sat, Oct 06, 2012, 4:36 PM UTC

patio11 wrote: post #153

nikcub wrote: post #122

Earlier quoted context omitted.

My own policy is that each situation is unique and in some cases you have to disclose details upfront. I believe this was one of those cases. The founders of this application were told in the original thread that there were security issues. They didn't respond to the issue and continued allowing users to signup. Their immediate response should have been to shut down the application with a maintenance page. Their resp…

I gave Diaspora advice on fixing the vulnerabilities then a week to do it prior to mentioning anything more specific than "There exist multiple very bad bugs here."

I mis-remembered. It is interesting to read that thread again[1] since there was a similar discussion about disclosure.

FTR, I don't think that the gap between saying there is a security vulnerability and describing it is very large, especially when the audience contains capable penetration testers.

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

Re: Never Give Your Information To 10 Minute Old Startups

#157

Post by brianpan » Sat, Oct 06, 2012, 4:37 PM UTC

mryan wrote: post #130

whalesalad wrote: post #93

Earlier quoted context omitted.

Totally not the same thing. Not even close. Knowing a tracking number is nothing compared to having access to someone's AWS account. That's like saying knowing where someone's car is parked is the same as having their keys and a full tank of gas. I agree with silhouette. These guys scaffolded a rails project and and then slapped bootstrap on it. You can't trust an MVP this extreme.

This is exactly the same thing - an obvious security oversight that resulted in private information being disclosed, simply by modifying the URL. The fact that the results are so different is irrelevant - the attack vector was essentially the same. Also, even with the complete lack of security on this site, it should still not be possible to take any action on the victim's AWS account. IAM has read-only roles for thi…

The results absolutely do matter. If you're running a site, you should be auditing the areas where the security risk is the greatest and taking extra precautions, and those areas are hopefully few. If you're not first taking care of the places where the results are disastrous, then you're doing it wrong.

Obviously if there is a known attack vector, you would fix any similar issues everywhere, but not all code is the same.

Re: Never Give Your Information To 10 Minute Old Startups

#158

Post by driverdan » Sat, Oct 06, 2012, 4:54 PM UTC

Major data leaks / security issues like this are not confined to sites that are 10 minutes old. Yesterday I discovered a recently funded startup is exposing all personal user data and activity to the world via their public, unprotected APIs. I'm hoping they fix it quickly before someone interested in harvesting that data finds it.

Re: Never Give Your Information To 10 Minute Old Startups

#159

Post by konstruktor » Sat, Oct 06, 2012, 5:22 PM UTC

Silhouette wrote: post #41

patio11 wrote: 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,…

Also, this is what I would call a functioning market. People using SaaS products should make it very clear that skipping security will take "viable" out of you MVP. Making an example of them may be a humiliating experience for the guys who built this, but it incentivizes doing the right thing.

Re: Never Give Your Information To 10 Minute Old Startups

#160

Post by mryan » Sat, Oct 06, 2012, 5:30 PM UTC

brianpan wrote: post #157

mryan wrote: post #130

Earlier quoted context omitted.

This is exactly the same thing - an obvious security oversight that resulted in private information being disclosed, simply by modifying the URL. The fact that the results are so different is irrelevant - the attack vector was essentially the same. Also, even with the complete lack of security on this site, it should still not be possible to take any action on the victim's AWS account. IAM has read-only roles for thi…

The results absolutely do matter. If you're running a site, you should be auditing the areas where the security risk is the greatest and taking extra precautions, and those areas are hopefully few. If you're not first taking care of the places where the results are disastrous, then you're doing it wrong. Obviously if there is a known attack vector, you would fix any similar issues everywhere, but not all code is the…

The point I was making is that this particular flaw is indeed the same as the UPS flaw when considered at a high level - modifying a URL caused sensitive data to be disclosed.

In practical terms, of course the nature of data that is disclosed is relevant. AWS keys are incredibly valuable, and should be treated as such.