Coinbase design allows for mass, targeted phishing of its users

How would they go about fixing that? Verified by Visa is the same - you get redirected to some random domain "arcot.com"?. There's a verification code, but that's viewable by anyone that has your credit card (including the site operator where you just input your CC number).

Wouldn't Coinbase need to fully redirect to their own domain, or popup a window with the URL visible in order for users to know they're really dealing with Coinbase?

Sure, the user needs to allow the permissions first, but the warning where disproportionate to the power it gave away.

They've disabled this kind of access since though.

http://www.theverge.com/2014/2/7/5386222/a-string-of-thefts-...

Banks have entire security teams working around the clock and they work in an area where transactions are mostly reversible. When you work with Bitcoin nothing is reversible so you have to take things even more seriously than the banks.

http://blog.shubh.am/full-disclosure-coinbase-security/#tech...

You're reading the Proof of Concept, which is meant to be a practical demonstration of how once could use the bug to their advantage. I didn't document the proof of concept in detail, to ensure that others couldn't easily use the blog post as a guide to harvesting Coinbase emails.

If you want the full, technical bug report, please visit: http://shubh.am/bugs/coinbase.htm

Coinbase responded to him on the 25th[1]:

"We've spent some time considering the implications of this behavior and have built this intentionally. The benefits to obscuring this information is minimal and, in our opinion, not worth the additional friction alternative flows would introduce"

Anyone can signup on Coinbase, right? So even if they did add some rate limiting, unless it was severe (or required a verified account), attackers would just sign up for more accounts.

1: http://shubh.am/bugs/coinbase.htm

Edit: I also like this part of their response: "Furthermore, it's not necessary to use "Burp Suite Intruder" in the manner demonstrated here. The functionality is exposed more directly in an intentional fashion over our API"

https://hackerone.com/reports/5200

And anyways, an attacker could simply sign up for multiple accounts.

I don't think much of Coinbase technically (terrible execution in the past, use of MongoDB), but this breathless report is really overhyping an minor design decision on Coinbase's part.

1: https://hackerone.com/reports/5200

The email content copy should include a footer with a link to get out of receiving such emails. Since they are sending emails to "unverified" email address there is a good chance they get marked as spam by recipients there by damaging their email sender reputation.

Gee, that's just what I look for in a financial service provider! This is the natural, uncontrolled result of Silicon Valley startup culture meets financial services. It's hard to get everything right, all the time, but particularly when operating in a financial domain it seems companies are better off accepting the severity of security issues and rewarding and engaging people who have taken the time to raise them than creating PR problems by demonstrating a lack of professionalism through suggesting that customer information (name, email, fact they use your service) is of no consequence and that enumeration issues are invalid.

Clearly:

(1) most users care about their privacy and time (ie. the sanctity of their inbox);

(2) the issue has been misevaluated by Coinbase; and

(3) the poster has been extremely patient and deserves an apology.

(Disclaimer: I, too, grew up in Sydney and spent my younger years doing security research. I work at one of Coinbase's competitors, Payward, operator of the Kraken exchange. We have an extremely successful bounty program that frequently pays out for all sorts of little issues. We consider this a requirement for security-conscious operation on the modern internet. After all, security is a process! Should security researchers choose to dedicate some of their valuable time to helping us improve our systems, I can promise them - at the bare minimum - a friendlier and less dismissive response.)

But as someone who very occasionally does such things (but isn't looking to "make a name" for myself as a security researcher, which is often a motivation):

1) The initial motivation isn't so much about documenting security flaws, but finding them in the first place. It is a very hands-on immediate-results-oriented type of problem solving where you look at a system that is intended (or should be intended, based on what it is doing) to be secure and find ways in which the security is lacking.

2) From there, informing the company is just about being a decent net citizen. If you can work around their security from the outside, other (potentially more nefarious) people can too, and in most cases the company simply doesn't realize they have a security problem, so informing them is good for everyone.

3) From there, if they refuse to fix the problem and it is very legitimately a security issue, responsible full disclosure (with a solid window of not talking about the bug publically, I go with Google's 60-day window as a guideline) is about being a decent net citizen toward the product's users (if not the product's company). If they have gaping security flaws in their product that they won't fix, users who could and likely will get screwed by them deserve to know so they can make an informed decision as to whether the company they are using is adequately protecting their interests.

But as I said, everyone is different, for some people they are mostly resume building a collection of public CVEs on their way to a security research position, for me it is just a fun very occasional hobby and I've not publicly disclosed a gaping security flaw since the mid-1990s because most companies will do the right thing in fixing real security issues if poked a bit these days.

More importantly, don't ever give the user the full name of someone whose email address they pulled out of thin air!