Live data from Hacker News

Never Give Your Information To 10 Minute Old Startups

blog.ryankearney.com

131–140 of 185 posts

Re: Never Give Your Information To 10 Minute Old Startups

#131
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 agree with you and have done so in the past. Quietly telling the developers of a website that they have large vulnerabilities that allow me to gain almost complete access to large numbers of accounts.

With things like that, especially when revealing it could lead to people using the vulnerability maliciously I don't think it is ethical to release details of it, unless they don't make any indication they are going to fix it.

It is bothersome when they don't even thank you for bringing it to their attention however.

Re: Never Give Your Information To 10 Minute Old Startups

#132
post #34

Earlier quoted context omitted.

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…

Why did you share Ryan's email address in a previous comment and why have't you deleted it yet ?

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

Re: Never Give Your Information To 10 Minute Old Startups

#133
post #95

Earlier quoted context omitted.

I was slightly sympathetic to them right up until smeagle posted RKearney's email. While not noticing an incredibly obvious security hole is serious, it's somewhat understandable in the context of a site that unintentionally goes public before it's ready. What's far, far worse is the mindset in which someone who points out a security hole is the problem , and should be personally attacked. They should have thanked hi…

> it's somewhat understandable in the context of a site that unintentionally goes public before it's ready Sorry, but no. There is absolutely no good reason while creating an user controller - even when writing the very first lines - to not check against current user on sensible actions. Actually, I may argue that's the very first thing you do once the controller skeleton is set up.

Agreed. You don't even need to add any gems or do any rails magic for this to work. In your controller:

    def edit
      @aws_credentials = current_user.aws_credentials
    end

    def update
      current_user.aws_credentials.update_attributes(
        params[:aws_credentials].slice(:a, :b, :c)
      )
    end

Re: Never Give Your Information To 10 Minute Old Startups

#134
post #9

Security stuff aside, I'm curious why a system would be designed this way. Surely (in most systems) all users have the same page for managing their account (eg: /account) or is this system designed so that the management portion (eg: what a support person would use) is the same as what the users use? I don't think I've encountered a site that had accounts edited this way before.

The last time I used Rails (2009), the way RESTful URLs are set up encouraged this pattern. It's simple enough to restrict access to the user in question, but it is (or was) easy to overlook.

It's REST, it must be good.

Re: Never Give Your Information To 10 Minute Old Startups

#135

Earlier quoted context omitted.

> it's somewhat understandable in the context of a site that unintentionally goes public before it's ready Sorry, but no. There is absolutely no good reason while creating an user controller - even when writing the very first lines - to not check against current user on sensible actions. Actually, I may argue that's the very first thing you do once the controller skeleton is set up.

Agreed. You don't even need to add any gems or do any rails magic for this to work. In your controller: def edit @aws_credentials = current_user.aws_credentials end def update current_user.aws_credentials.update_attributes( params[:aws_credentials].slice(:a, :b, :c) ) end

Don't forget `destroy`.

Re: Never Give Your Information To 10 Minute Old Startups

#136
post #117

Earlier quoted context omitted.

I think it's at an entirely different level when it's a brand new company and a trivial security flaw. That just seems like incompetence, and he's absolutely right to suggest not trusting people like that with your data.

It's incompetence (at security), but not malice, and they were willing to fix the problem quickly. It's a problem of competing claims -- you want to keep the world safe so end users are protected, and are willing to use new (secure) services, but you also want to avoid discouraging developers (either these guys, or others who see how they're being ragged on and choose not to develop something on their own). It's not…

The mistake betrays so much incompetence that there is really no way for me to trust anything they ever do again. The other mistakes they make might not be quite so easy to find.

Re: Never Give Your Information To 10 Minute Old Startups

#137
post #70
post #34

Earlier quoted context omitted.

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…

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 stored terabyte per year. (Of course these losses, should they occur, would probably be not uniformely distributed).

Re: Never Give Your Information To 10 Minute Old Startups

#138
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. I find the lack of basic security un-fucking-acceptable and in need of public shaming.

Good security should define the underlying template/infrastructure for your app, not be an afterthought.

Re: Never Give Your Information To 10 Minute Old Startups

#139

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…

somewhere, a low orbit ion cannon is warming...
Post reply on HN