Hacker News Reader

This is exactly the page most startups should have.

First, startup customers to a first approximation don't care about the distinction between CSRF attacks and SQL injection. The neuroreceptor this page is trying to trip is "this company understands the concept of application security". For most companies, counterintuitively, the more you delve into the specifics, the less confidence you instill: you're increasing your customers perception of risk.

Second, there's nothing a typical company can say to clear the bar you're implicitly setting, which is "convince a technologist familiar with the issues that their application is free of vulnerabilities". Nobody is free of vulnerabilities. There are no tea leaves to be read here about code quality. To understand code quality, you have to look at or test code.

Third, since the objections they're addressing on this page are nebulous, appeals to authority through naming best practices or citing industry analogs are just fine. Also, what do you expect to learn from "PCI compliance"? PCI is a joke.

Fourth, most companies don't disclose vulnerabilities. Contributors to this bug bounty have disclosed, which presumably means that payout on the bounty doesn't include an NDA. So what are you complaining about? There's a list of named bugfinders on the bounty page. Go ask them what they found.

Github has over the last few years built one of the best appsec teams in the business. Look at their security page. Coinbase's is, if anything, better. Dial back your expectations for pages like this. Coinbase makes it easy for people who have found vulnerabilities to report them to Coinbase, and makes it clear that they understand the basic concept of security for application providers. I grade security pages "pass/fail", and this one clearly passes. Startups should take cues from it and pages like it.

(I don't know anything about Coinbase's actual security practices or the wisdom of keeping "90% of bitcoins offline" or whatnot; I'm talking exclusively about the page itself. I don't like Bitcoin and find it very difficult to take seriously.)

First- yeah, sure, which is why I explicitly said "that this seems like a marketing site".

Second- That's not the bar I'm setting at all, and putting that extreme viewpoint in my mouth is silly at best. I do agree with your underlying point though, which is that you can't gauge code quality without looking at the code. That's why I think they'd be better off saying "and we do regular audits" and detail that bit. Otherwise this is basically them saying "we do security well, trust us!".

Third- They aren't really naming the best practices, simply stating that they follow them. If they're going to say they follow the standards of the payment industry, they should have some standard to point at and say they follow (even if it is a joke).

Fourth- I'm not expecting them to disclose everything, just pointing out that without that disclosure the number found there seems a bit high (especially for a company that's only 18 months old).

The major difference between these guys and Github is that I haven't seen the Github CEO and Founder post his security page on this site. This was clearly an advertisement to the people on this site, and I don't think it does a good job at all of saying that they understand security. What it tells me is that they understand security blogs, as most of the content in that post seems like it was ripped from topics on this site over the last year.

(I also like asides- if Github's appsec team is so good how come their enterprise product gets nailed with exploits all the time? Their last set of releases broke their authentication system so badly that it allowed anyone to log in as anyone else, including admins).

> I don't like Bitcoin and find it very difficult to take seriously.

What don't you like or take seriously about Bitcoin, from a security perspective?

To elaborate just a wee bit on what Thomas said, there are many, many startups which transact real money (via, e.g., taking credit cards on their website, even if via one of the methods where it doesn't get POSTed at their server) which don't go as far as saying "Here's the address you can talk to if you find something critical. We WILL get back to you."

Startups without this page have often found out about security vulnerabilities via posts at third party sites. Regardless of the moral righteousness of that, that is for better or worse the cultural expectation of many security researchers.

Also, since it's on your website, you're going to have a bit of tension in serving the "Needs to report a security vulnerability" audience at the same time as you're supporting non-technical customers who care about "security" for business reasons. Those are very different conversations. I had one with a stakeholder at a large organization who was worried about the physical security of my servers recently. I told him that they were in a professionally managed datacenter, behind a gate, which required a keycard to access, and that if I showed up at the door they would turn me away because that isn't the model at my host. His response was, I kid you not, "Oh, wow, you're Fortune 500? Sorry, I just have to ask that because a lot of our vendors keep the server in their home or office."

>90% of customer funds are stored offline. >Offline storage provides an important security measure against theft or loss. >We distribute bitcoin geographically in safety deposit boxes around the world.

Using offline, split, encrypted files has a huge amount of security: Breaking into n+1 bank vaults (simultaneously) is not enough. That's pretty nice. It's not 100% secure, but probably better than average compared to online wallets or exchanges.

I cringe when I see "Safe Deposit" spelled wrong.

Well, they have the company of the BBC: http://www.bbc.co.uk/news/business-17224846

> I'm honestly not that impressed by this.

Not that impressed? I'm impressed they are not even ashamed of showing things that are probably the default in most web frameworks nowadays, as if they were features they had to work on.

> We whitelist attributes on all models to prevent mass-assignment vulnerabilities.

That's simply embarrassing, you don't even need a framework to avoid that. Gotta love Rails devs and their fancy "vulnerabilities".

Does Rails come with goegraphically distributed cold storage these days? That's pretty sweet if so.

>SQL Injection is something every web application should do. This is a completely separate issue from CSRF (cross site request forgery), but they conflate the two as if they're one.

It sounds like they're describing a web application firewall that detects and blocks both of those things together. (I assume the application itself is also secured to their knowledge against these separately.)

Maybe it's more of a "Coming Soon: For Sale" post.