5 ms·

An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. Then again, I once submitted a bug report to my bank, because the l

An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. Then again, I once submitted a bug report to my bank, because the login method could be switched from password+pin to pin only, when not logged in, and they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password. (And that's not even getting into the difference between real two-factor authentication the some-factor one-and-a-half-times they had implemented by adding a PIN to a password login.) I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security. Assuming the host of the bug bounty program is operating in good faith, adding some kind of barrier to entry or punishment for untested entries will weed out submitters acting in bad faith.

gamer191 10mo ago
Agreed, although the reimbursement should be based on whether a reasonable person could consider that to be a vulnerability. Often it’s tricky for outsiders to tell whether a behaviour is expected or a vulnerability
- dlcarrier 10mo ago
  Yeah, the reimbursement would need to be for a good-faith submission worth considering, even if it wasn't actionable.
fredrikholm 10mo ago
> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. I refer to this as the Notion-to-Confluence cost border. When Notion first came out, it was snappy and easy to use. Creating a page being essentially free of effort, you very quickly had thousands of them, mostly useless. Confluence, at least in west EU, is offensively slow. The thought of adding a page is sufficiently demoralizing that it's easier to update an existing page and save yourself minutes of request time outs. Consequently, there's some ~20 pages even in large companies. I'm not saying that sleep(15 * SECOND) is the way to counter, but once something becomes very easy to do at scale, it explodes to the point where the original utility is now lost in a sea of noise.
- teekert 10mo ago
  It’s strange how sensitive humans are to these sort of relative perceived efforts. Having a charged, cordless vacuum cleaner ready to go and take around the house has also changed our vacuuming game. Because carrying a big unwieldy vacuum cleaner and needing to find a power socket at every location just feels like much more effort. Even though it really isn't.
  - TeMPOraL 10mo ago
    It is. The classical vacuum is heavier, you have to find the socket and plug it in (non-trivial if you have few of them, or have kids and sockets have kid blocks on them), and perhaps most importantly, you need two free hands to operate it (particularly when carrying, plugging in and repositioning). That alone is enough to turn it into a primary activity, i.e. the kind of thing that you explicitly decide to do and becomes your main focus. Meanwhile, a charged cordless cleaner is something you can semi-consciously grab with one hand while passing by, and use on the go to do some cleaning while actually focused on something else. It's an entirely different class of activity, much easier to fit in during the day. Ironically, the cordless vacuum is even better than vacuum robots in this regard! I was surprised to hear from some friends and acquaintances that they prefer the manual vacuum to robotic one, and find it a better time/effort saver - but I eventually realized they're right, simply because the apps for controling the robotic vacuums are all steaming piles of shit, and their bad UI alone turns activating the robot into primary activity. It may be a brief activity, but it still requires full focus.
    - neutronicus 10mo ago
      Ok but the corded vacuum actually fucking works. I keep having to get it from progressively more inconvenient locations to which it has been banished in order to humor my wife’s delusion that the roomba or the handhold do anything. I can make multiple passes with the handheld to get 80% of the crumbs in a small area, troubleshoot why the robot didn’t run yesterday in order to hope it will get the crumbs tomorrow, or just get the corded vacuum out and actually clean a whole room. Work involves cables. Any product that promises something different is a lie.
nospice 10mo ago
> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. The problem is that bug bounty slop works. A lot of companies with second-tier bug bounties outsource triage to contractors (there's an entire industry built around that). If a report looks plausible, the contractor files a bug. The engineers who receive the report are often not qualified to debate exploitability, so they just make the suggested fix and move on. The reporter gets credit or a token payout. Everyone is happy. Unless you have a top-notch security team with a lot of time on their hands, pushing back is not in your interest. If you keep getting into fights with reporters, you'll eventually get it wrong and you're gonna get derided on HN and get headlines about how you don't take security seriously. In this model, it doesn't matter if you require a deposit, because on average, bogus reports still pay off. You also create an interesting problem that a sketchy vendor can hold the reporter's money hostage if the reporter doesn't agree to unreasonable terms.
- zrm 10mo ago
  Triage gets outsourced because the quality of reports is low. If filing a bad report costs money, low quality reports go down. Meanwhile anyone still doing it is funding your top notch security team because then they can thoroughly investigate the report and if it turns out to be nothing then the reporter ends up paying them for their time.
  - nospice 10mo ago
    My point is that on average, filing bad but plausibly-sounding reports makes the reporter money. Curl is the odd exception with naming-and-shaming, not the rule. Spamming H1 with AI-generated reports is lucrative. A modest deposit is unlikely to change that. A big deposit (thousands of dollars) would, but it would also discourage a lot of legitimate reports.
- notpushkin 10mo ago
  I don’t think it works for curl though. You would guess that sloperators would figure out that their reports aren’t going through with curl specifically (because, well, people are actually looking into them and can call bullshit), and move on. For some reason they either didn’t notice (e.g. there’s just too many people trying to get in on it), or did notice, but decided they don’t care. Deposit should help here: companies probably will not do it, so when you see a project requires a deposit, you’ll probably stop and think about it.
saghm 10mo ago
That anecdote is hilarious and scary in equal measures. Optional passwords are certainly more convenient than required ones, but so are optional PINs. The most convenient UX would be never needing to log in at all! Unless you find it inconvenient for others to have access to your bank account of course
- sersi 10mo ago
  I really hate the current trend of not having passwords. For example perplexity doesn't have a password, just an email verification to login.
  - eXpl0it3r 10mo ago
    I hate this as well, especially since I have greylisting enabled on some email addresses, so by the time the email login is delivered, the login session has already timed out and of course the sender uses different mail servers everytime. So in some cases, it's nearly impossible to login and takes minutes...
    - crote 10mo ago
      It's the same on the sender side. Most people of course just outsource it to some SaaS like Sendgrid, and of course have some fancy microservice event bus architecture to get it there. That 'your login email has been sent' actually means 'your email has entered the very first queue, and we're hoping it makes it through all the layers soon'. There have been plenty of instances where I tried to log in somewhere, and the first attempt to contact my mail server was twenty minutes later. And of course they then deliver all five retries at once.
  - 6510 10mo ago
    Long long ago the google toolbar queries could be reverse engineered to do an i feel lucky search on gmail. I created a login that (if @gmail.com) forwarded to the specific mail. Unlikely to happen but it seems fun to extend email [clients] with uri's. It is just a document browser, who cares how they are delivered.
  - 10mo ago
bawolff 10mo ago
Bug bounties often involve a lot of risk for submitters. Often the person reading the report doesn't know that much and misinterprets it. Often rules are unclear about what sort of reports are wanted. A pay to enter would increase that risk. Honestly bug bounties are kind of miserable for both sides. I've worked on the recieving side of bug bounty programs. You wouldnt believe the shit that is submitted. This was before AI and it was significant work to sort through, i can only imagine what its like now. On the other hand for a submitter, you are essentially working on spec with no garuntee your work is going to be evaluated fairly. Even if it is, you are rolling the dice that your report is not a duplicate of an issue reported 10 years ago that the company just doesn't feel like fixing.
- ANarrativeApe 10mo ago
  Pay to enter would increase the risk of submitting a bug report. However, if the submission fees were added to the bounty payable, then the risk reward changes in favour of the submitter of genuine bugs. You could even have refund the submission fee in the case of a good faith non bug submission. A little game theory can go a long way in improving the bug bounty system...
  - CTDOCodebases 10mo ago
    They could allow submitters to double down on submissions escalating the bug to more skilled and experienced code reviewers who get a cut of the doubled submission fee for reviews.
  - bawolff 10mo ago
    If a competent neutral party was evaluating them, i would agree. However currently these things tend to be luck of a draw.
  - airza 10mo ago
    You’re assuming that the companies operating these programs would act in good faith which they often do not.
- eterm 10mo ago
dmurray 10mo ago
cURL would operate such a program in good faith, and quickly earn the trust of the people who submit the kind of bug reports cURL values. Your bank would not. Nor would mine, or most retail banks. If the upfront cost would genuinely put off potential submitters, a cottage industry would spring up of hackers who would front you the money in return for a cut if your bug looked good. If that seems gross, it's really not - they end up doing bug triage for the project, which is something any software company would be happy to pay people for.
sudahtigabulan 10mo ago
> I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security. Sadly, yeah. And will do anything only if they believe they can actually be caught. An EU-wide bank I used to be customer of until recently, supported login with Qualified Electronic Signatures, but only if your dongle supports... SHA-1. Mine didn't. It's been deprecated at least a decade ago. A government-certified identity provider made software that supposedly allowed you to have multiple such electronic signatures plugged in, presenting them in a list, but if one of them happened to be a YubiKey... crash. YubiKey conforms to the same standard as the PIV modules they sold, but the developers made some assumptions beyond the standard. I just wanted their software not to crash while my YubiKey is plugged in. I reported it, and they replied that it's not their problem.
- burnt-resistor 10mo ago
  Name and shame, and give them a trial by media.
laserbeam 10mo ago
For weak bank logins, my guess is that reimbursing all account takeovers is cheaper than having a complex login process that would scare away non-technical customers. Or, well, I could see myself making that decision if I were more versed in finance than in computer science and I had a reasonable risk assessment in front of me to tell me how many account takeovers happen.
- dlcarrier 10mo ago
  Banks aren't even liable for losses from account takeovers, at least if their system is compliant, regardless of whether that makes it secure. Their biggest incentive is customer satisfaction, which fraud does hurt. It's credit cards that have to reimburse for fraud, but they charge the merchant for it, plus fees, so they have absolutely no incentive to prevent fraud, if not an incentive to outright encourage fraud. That would explain why their implementation of the already compromised EMV was further nerfed by a lack of a PIN in the US.
  - crote 10mo ago
    > Their biggest incentive is customer satisfaction At a bank? No way. They are some of the most customer-hostile organizations I've interacted with. Dealing with payment accounts is a necessary evil for them, and they are very much aware of the effort required to switch to a different bank, and of the massive regulatory moat preventing consumer-friendly competition from popping up. A bank doesn't care about screwing over a handful of customers. As long as it's not common enough to draw the attention of the press and/or a regulatory agency, they are not going to spend any money on improving.
    - cestith 10mo ago
      Case in point: Wells Fargo foreclosure fraud. Case in point: Wells Fargo opening new accounts in customer names without direction from, approval by, or notification to said customers. The primary incentive of a bank is to make money rather than customer satisfaction, security, or most other things. Sometimes other priorities suffer in the race to profit, sometimes including regulatory compliance and legality.
icar 10mo ago
> I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security. I personally came to that conclusion thanks to the GrapheneOS situation regarding device attestation. Insecure devices get full features from some apps because they are certified, although they cite security, while GrapheneOS get half featured apps because it's "insecure" (read, doesn't have the Google certification, but are actually the most secure devices you can get, worldwide)
- cynicalsecurity 10mo ago
  It's not about securing your device from external threats or bad actors; it's about securing the device from you.
  - trashb 10mo ago
    I see it a little differently. I would change your statement to the following: It's not about securing your device from external threats or bad actors; it's about securing the organization from any blame / wrongdoing. Most organizations today are looking high and low to shove the blame to others instead of taking responsibility.
    - TeMPOraL 10mo ago
      It's related, but GP is still right to bring it up - it's the one question that is most important wrt. security, and also conveniently the least often asked: security for who, and from what? "Security" isn't an absolute good.
  - subscribed 10mo ago
    Play Integrity certifies (and banks/etc approve) that Android 8.0 (oreo) unpatched for several years, full of vulnerabilities for RCE, 0-click, privilege escalation, etc, so full of holes it's trivial to get a root and then hide it (or use leaked cert), is absolutely a-ok, safe to use and secure for user. Yes? Is this what you're suggesting? :) Because this is what's certified and embraced.
duxup 10mo ago
Are bug reports a 100% sure black and white thing? Could people who think they found a bug but not sure be turned off by the up front cost / risk of finding out they are wrong or not technically finding a bug?
entuno 10mo ago
A problem with this approach is that one of the key functions of a bug bounty program is to encourage people to report vulnerabilities to the developers, rather than selling them elsewhere. If I have to pay money to submit a vulnerability to the developers with no guarantee that I'll even get refunded for a high quality and good faith report, let alone any actual payout, there's much less incentive for me to do so compared to selling them to someone else who won't charge me money for the privilege.
- UncleMeat 10mo ago
  In a past life I was deeply involved in the operation of a bug bounty program. Discouraging people from selling on the black market was nowhere on the list of motivations. We wanted to encourage white hat security researchers to look at our domain rather than other domains so we could collect more data on the kinds of vulns that appeared in our domain to help prioritize efforts that would fix the root causes of recurring bug patterns. I've also submitted bug bounties and received rewards and I've worked with a bunch of other people who have done this. At no point did I even consider selling on the black market and I suspect that my friends from grad school were the same way. Maybe the $1,000,000 bounties for zero click rce on iphones or whatever exist to discourage selling on the black market, but I'm not even sure that is true. "Well, I'll just find a way to sell this to the russian mob" is not exactly something that is on the radar of the vast majority of security researchers.
  - entuno 10mo ago
    There are plenty of places you can sell exploits other than OCGs. At the more legitimate end of that market is people like ZDI who will then collaborate with the vendors (after a time), or companies making exploit kits/tooling for pentesters/red teaming. More questionable ones are companies that make things like forensics tools or spyware who are legal, but perhaps ethically dubious. All completely legal, but not great for the wider community if they're getting the vulns rather than the developers. If you're trying to protect your own website and servers, those markets won't be a concern for you. If you ship a widely used product that's an attractive target (like web browser, mobile device, network kit, etc) then they definitely are.
BrandoElFollito 10mo ago
I found that banks are one of the worst organizations when it comes to authentication. They are regulated but the requirements are completely outdated and irrelevant in a risk context. And then you have banks such as Boursobank (a French online bank) that has weak traditional authentication (and a faulty app, but they do not care) and out of the blue also provides passkeys. Making it at the same time horribly bad and wonderfully good. The worst part is that they hide behind regulations when in fact there are only few of them. Other instiytutions such as SWIFT are as bad and equally arrogant.
dspillett 10mo ago
> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. It would also stop a lot of genuine submissions unfortunately, as some literally can't pay not just won't pay (for both technical or financial reasons), and adds complexity¹. Each project working this way will need to process a bunch of payments and refunds on top of the actual bounty payments, which is not admin free nor potential financially cost free. I can't think of an easy answer that would work for more than a very short amount of time. As soon as there is money involved and an easy way to use tooling rather than actual effort/understanding to be involved, many will try to game the system ruining it for those genuine participants. Heck, even if the reward is just credit² rather than money, that will happen. Many individual people are honest and useful, people as a whole are a bunch of untrustworthy arseholes who will innocence you and the rest of the world for a penny or just for shits & giggles. > Assuming the host of the bug bounty program is operating in good faith This is a significant assumption. One that is it harder to not be paranoid about when you are putting money down. > they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password This does not surprise me. My primary bank (FirstDirect, UK) switched the way I authenticate from “between 5 and 9 alphanumeric characters”³ to a 5-digit pin, and all their messages about it assured me (like hell!) that this was “just as secure as before”…⁴ -------- [1] Needing a payment processing option that is compatible with both the reporter and reportee, at the point of submission. At the moment that can be arranged after the bounty is awarded rather than something a project like curl needs to have internationally setup and supported before accepting submissions. [2] ref: people submitting several simple documentation fixes, one misplaced comma or 'postrophe per pull request, to game some “pull requests accepted” metric somewhere. [3] which wasn't ideal to start with [4] I would accept the description “no less secure than before” if they admitted that the previous auth requirements were also lax.
greggsy 10mo ago
PIN only isn't too uncommon for online banking these days. You still need to complete a SMS auth to do anything other than view records though, like transfer money.
shevy-java 10mo ago
It may stop it but it may also hinder real people contributing. How many people want to pay a free in order to "contribute"?
entuno 10mo ago
There's also the issue of what happens to my money as a researcher. Is it paid to the company, or is someone holding it in escrow? What if it takes the developer months to respond, or they never do? Do they just get to keep my money indefinitely? What if the vendor pulls out of the scheme? What if I do a chargeback on the payment I made? Etc, etc I wonder if a better model would be to make the platform pay to entry, but not the specific bugs? So you have to pay a fee to gain access to a platform like HackerOne, and if your signal:noise ratio gets too bad then your account gets revoked? That would make it feel like less of a gamble than having to pay for every individual bug - but still has the same problem that it's putting a big barrier in front of legitimate good-faith researchers.
latexr 10mo ago
> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. That adds an extra layer of complexity to the cURL maintainers, handling other people’s money and whatnot. It was considered. Daniel (cURL’s lead) has been discussing this for months. Whatever “quick and easy” solution you think of, it’s already been suggested and thought about and rejected for some reason.
billy99k 10mo ago
I've been active in the bug bounty community for almost 7 years now. The problem is that the majority of companies don't act in good faith. Even when you have something fully exploitable and valid, they will many times find some way to not pay you or lower the severity to pay you very little. The catch-all excuse is something along the lines: "although this is vulnerable, it doesn't impact the business". I've gotten this excuse, even when I could prove it was a production server with customer information that I could access. Sites like Hackerone can help, but in the end, it comes down to the company running the bug bounty program.
smusamashah 10mo ago
Github can use youtube strikes like system. PRs are tied to people. Someone reported for submitting slop should get a badge or something similar. If a PR is submitted by someone who is then known to submit slops, they can be easily ignored by the maintainers. EDIT: Or may be something like SponsorBlock for youtube. There could be a browser extension that will collectively tag sloppers the sameway and can help identify sloppers.
Hendrikto 10mo ago
> I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security. This is the key insight. Nobody cares at all about actual security. It is all about checklists and compliance.

gamer191 10mo ago

Agreed, although the reimbursement should be based on whether a reasonable person could consider that to be a vulnerability. Often it’s tricky for outsiders to tell whether a behaviour is expected or a vulnerability

dlcarrier 10mo ago
Yeah, the reimbursement would need to be for a good-faith submission worth considering, even if it wasn't actionable.

fredrikholm 10mo ago

> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. I refer to this as the Notion-to-Confluence cost border. When Notion first came out, it was snappy and easy to use. Creating a page being essentially free of effort, you very quickly had thousands of them, mostly useless. Confluence, at least in west EU, is offensively slow. The thought of adding a page is sufficiently demoralizing that it's easier to update an existing page and save yourself minutes of request time outs. Consequently, there's some ~20 pages even in large companies. I'm not saying that sleep(15 * SECOND) is the way to counter, but once something becomes very easy to do at scale, it explodes to the point where the original utility is now lost in a sea of noise.

teekert 10mo ago
It’s strange how sensitive humans are to these sort of relative perceived efforts. Having a charged, cordless vacuum cleaner ready to go and take around the house has also changed our vacuuming game. Because carrying a big unwieldy vacuum cleaner and needing to find a power socket at every location just feels like much more effort. Even though it really isn't.
- TeMPOraL 10mo ago
  It is. The classical vacuum is heavier, you have to find the socket and plug it in (non-trivial if you have few of them, or have kids and sockets have kid blocks on them), and perhaps most importantly, you need two free hands to operate it (particularly when carrying, plugging in and repositioning). That alone is enough to turn it into a primary activity, i.e. the kind of thing that you explicitly decide to do and becomes your main focus. Meanwhile, a charged cordless cleaner is something you can semi-consciously grab with one hand while passing by, and use on the go to do some cleaning while actually focused on something else. It's an entirely different class of activity, much easier to fit in during the day. Ironically, the cordless vacuum is even better than vacuum robots in this regard! I was surprised to hear from some friends and acquaintances that they prefer the manual vacuum to robotic one, and find it a better time/effort saver - but I eventually realized they're right, simply because the apps for controling the robotic vacuums are all steaming piles of shit, and their bad UI alone turns activating the robot into primary activity. It may be a brief activity, but it still requires full focus.
  - neutronicus 10mo ago
    Ok but the corded vacuum actually fucking works. I keep having to get it from progressively more inconvenient locations to which it has been banished in order to humor my wife’s delusion that the roomba or the handhold do anything. I can make multiple passes with the handheld to get 80% of the crumbs in a small area, troubleshoot why the robot didn’t run yesterday in order to hope it will get the crumbs tomorrow, or just get the corded vacuum out and actually clean a whole room. Work involves cables. Any product that promises something different is a lie.

nospice 10mo ago

> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. The problem is that bug bounty slop works. A lot of companies with second-tier bug bounties outsource triage to contractors (there's an entire industry built around that). If a report looks plausible, the contractor files a bug. The engineers who receive the report are often not qualified to debate exploitability, so they just make the suggested fix and move on. The reporter gets credit or a token payout. Everyone is happy. Unless you have a top-notch security team with a lot of time on their hands, pushing back is not in your interest. If you keep getting into fights with reporters, you'll eventually get it wrong and you're gonna get derided on HN and get headlines about how you don't take security seriously. In this model, it doesn't matter if you require a deposit, because on average, bogus reports still pay off. You also create an interesting problem that a sketchy vendor can hold the reporter's money hostage if the reporter doesn't agree to unreasonable terms.

zrm 10mo ago
Triage gets outsourced because the quality of reports is low. If filing a bad report costs money, low quality reports go down. Meanwhile anyone still doing it is funding your top notch security team because then they can thoroughly investigate the report and if it turns out to be nothing then the reporter ends up paying them for their time.
- nospice 10mo ago
  My point is that on average, filing bad but plausibly-sounding reports makes the reporter money. Curl is the odd exception with naming-and-shaming, not the rule. Spamming H1 with AI-generated reports is lucrative. A modest deposit is unlikely to change that. A big deposit (thousands of dollars) would, but it would also discourage a lot of legitimate reports.
notpushkin 10mo ago
I don’t think it works for curl though. You would guess that sloperators would figure out that their reports aren’t going through with curl specifically (because, well, people are actually looking into them and can call bullshit), and move on. For some reason they either didn’t notice (e.g. there’s just too many people trying to get in on it), or did notice, but decided they don’t care. Deposit should help here: companies probably will not do it, so when you see a project requires a deposit, you’ll probably stop and think about it.

saghm 10mo ago

That anecdote is hilarious and scary in equal measures. Optional passwords are certainly more convenient than required ones, but so are optional PINs. The most convenient UX would be never needing to log in at all! Unless you find it inconvenient for others to have access to your bank account of course

sersi 10mo ago
I really hate the current trend of not having passwords. For example perplexity doesn't have a password, just an email verification to login.
- eXpl0it3r 10mo ago
  I hate this as well, especially since I have greylisting enabled on some email addresses, so by the time the email login is delivered, the login session has already timed out and of course the sender uses different mail servers everytime. So in some cases, it's nearly impossible to login and takes minutes...
  - crote 10mo ago
    It's the same on the sender side. Most people of course just outsource it to some SaaS like Sendgrid, and of course have some fancy microservice event bus architecture to get it there. That 'your login email has been sent' actually means 'your email has entered the very first queue, and we're hoping it makes it through all the layers soon'. There have been plenty of instances where I tried to log in somewhere, and the first attempt to contact my mail server was twenty minutes later. And of course they then deliver all five retries at once.
- 6510 10mo ago
  Long long ago the google toolbar queries could be reverse engineered to do an i feel lucky search on gmail. I created a login that (if @gmail.com) forwarded to the specific mail. Unlikely to happen but it seems fun to extend email [clients] with uri's. It is just a document browser, who cares how they are delivered.
- 10mo ago

bawolff 10mo ago

Bug bounties often involve a lot of risk for submitters. Often the person reading the report doesn't know that much and misinterprets it. Often rules are unclear about what sort of reports are wanted. A pay to enter would increase that risk. Honestly bug bounties are kind of miserable for both sides. I've worked on the recieving side of bug bounty programs. You wouldnt believe the shit that is submitted. This was before AI and it was significant work to sort through, i can only imagine what its like now. On the other hand for a submitter, you are essentially working on spec with no garuntee your work is going to be evaluated fairly. Even if it is, you are rolling the dice that your report is not a duplicate of an issue reported 10 years ago that the company just doesn't feel like fixing.

ANarrativeApe 10mo ago
Pay to enter would increase the risk of submitting a bug report. However, if the submission fees were added to the bounty payable, then the risk reward changes in favour of the submitter of genuine bugs. You could even have refund the submission fee in the case of a good faith non bug submission. A little game theory can go a long way in improving the bug bounty system...
- CTDOCodebases 10mo ago
  They could allow submitters to double down on submissions escalating the bug to more skilled and experienced code reviewers who get a cut of the doubled submission fee for reviews.
- bawolff 10mo ago
  If a competent neutral party was evaluating them, i would agree. However currently these things tend to be luck of a draw.
- airza 10mo ago
  You’re assuming that the companies operating these programs would act in good faith which they often do not.
eterm 10mo ago

dmurray 10mo ago

cURL would operate such a program in good faith, and quickly earn the trust of the people who submit the kind of bug reports cURL values. Your bank would not. Nor would mine, or most retail banks. If the upfront cost would genuinely put off potential submitters, a cottage industry would spring up of hackers who would front you the money in return for a cut if your bug looked good. If that seems gross, it's really not - they end up doing bug triage for the project, which is something any software company would be happy to pay people for.

sudahtigabulan 10mo ago

> I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security. Sadly, yeah. And will do anything only if they believe they can actually be caught. An EU-wide bank I used to be customer of until recently, supported login with Qualified Electronic Signatures, but only if your dongle supports... SHA-1. Mine didn't. It's been deprecated at least a decade ago. A government-certified identity provider made software that supposedly allowed you to have multiple such electronic signatures plugged in, presenting them in a list, but if one of them happened to be a YubiKey... crash. YubiKey conforms to the same standard as the PIV modules they sold, but the developers made some assumptions beyond the standard. I just wanted their software not to crash while my YubiKey is plugged in. I reported it, and they replied that it's not their problem.

burnt-resistor 10mo ago
Name and shame, and give them a trial by media.

laserbeam 10mo ago

For weak bank logins, my guess is that reimbursing all account takeovers is cheaper than having a complex login process that would scare away non-technical customers. Or, well, I could see myself making that decision if I were more versed in finance than in computer science and I had a reasonable risk assessment in front of me to tell me how many account takeovers happen.

dlcarrier 10mo ago
Banks aren't even liable for losses from account takeovers, at least if their system is compliant, regardless of whether that makes it secure. Their biggest incentive is customer satisfaction, which fraud does hurt. It's credit cards that have to reimburse for fraud, but they charge the merchant for it, plus fees, so they have absolutely no incentive to prevent fraud, if not an incentive to outright encourage fraud. That would explain why their implementation of the already compromised EMV was further nerfed by a lack of a PIN in the US.
- crote 10mo ago
  > Their biggest incentive is customer satisfaction At a bank? No way. They are some of the most customer-hostile organizations I've interacted with. Dealing with payment accounts is a necessary evil for them, and they are very much aware of the effort required to switch to a different bank, and of the massive regulatory moat preventing consumer-friendly competition from popping up. A bank doesn't care about screwing over a handful of customers. As long as it's not common enough to draw the attention of the press and/or a regulatory agency, they are not going to spend any money on improving.
  - cestith 10mo ago
    Case in point: Wells Fargo foreclosure fraud. Case in point: Wells Fargo opening new accounts in customer names without direction from, approval by, or notification to said customers. The primary incentive of a bank is to make money rather than customer satisfaction, security, or most other things. Sometimes other priorities suffer in the race to profit, sometimes including regulatory compliance and legality.

icar 10mo ago

> I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security. I personally came to that conclusion thanks to the GrapheneOS situation regarding device attestation. Insecure devices get full features from some apps because they are certified, although they cite security, while GrapheneOS get half featured apps because it's "insecure" (read, doesn't have the Google certification, but are actually the most secure devices you can get, worldwide)

cynicalsecurity 10mo ago
It's not about securing your device from external threats or bad actors; it's about securing the device from you.
- trashb 10mo ago
  I see it a little differently. I would change your statement to the following: It's not about securing your device from external threats or bad actors; it's about securing the organization from any blame / wrongdoing. Most organizations today are looking high and low to shove the blame to others instead of taking responsibility.
  - TeMPOraL 10mo ago
    It's related, but GP is still right to bring it up - it's the one question that is most important wrt. security, and also conveniently the least often asked: security for who, and from what? "Security" isn't an absolute good.
- subscribed 10mo ago
  Play Integrity certifies (and banks/etc approve) that Android 8.0 (oreo) unpatched for several years, full of vulnerabilities for RCE, 0-click, privilege escalation, etc, so full of holes it's trivial to get a root and then hide it (or use leaked cert), is absolutely a-ok, safe to use and secure for user. Yes? Is this what you're suggesting? :) Because this is what's certified and embraced.

duxup 10mo ago

Are bug reports a 100% sure black and white thing? Could people who think they found a bug but not sure be turned off by the up front cost / risk of finding out they are wrong or not technically finding a bug?

entuno 10mo ago

A problem with this approach is that one of the key functions of a bug bounty program is to encourage people to report vulnerabilities to the developers, rather than selling them elsewhere. If I have to pay money to submit a vulnerability to the developers with no guarantee that I'll even get refunded for a high quality and good faith report, let alone any actual payout, there's much less incentive for me to do so compared to selling them to someone else who won't charge me money for the privilege.

UncleMeat 10mo ago
In a past life I was deeply involved in the operation of a bug bounty program. Discouraging people from selling on the black market was nowhere on the list of motivations. We wanted to encourage white hat security researchers to look at our domain rather than other domains so we could collect more data on the kinds of vulns that appeared in our domain to help prioritize efforts that would fix the root causes of recurring bug patterns. I've also submitted bug bounties and received rewards and I've worked with a bunch of other people who have done this. At no point did I even consider selling on the black market and I suspect that my friends from grad school were the same way. Maybe the $1,000,000 bounties for zero click rce on iphones or whatever exist to discourage selling on the black market, but I'm not even sure that is true. "Well, I'll just find a way to sell this to the russian mob" is not exactly something that is on the radar of the vast majority of security researchers.
- entuno 10mo ago
  There are plenty of places you can sell exploits other than OCGs. At the more legitimate end of that market is people like ZDI who will then collaborate with the vendors (after a time), or companies making exploit kits/tooling for pentesters/red teaming. More questionable ones are companies that make things like forensics tools or spyware who are legal, but perhaps ethically dubious. All completely legal, but not great for the wider community if they're getting the vulns rather than the developers. If you're trying to protect your own website and servers, those markets won't be a concern for you. If you ship a widely used product that's an attractive target (like web browser, mobile device, network kit, etc) then they definitely are.

BrandoElFollito 10mo ago

I found that banks are one of the worst organizations when it comes to authentication. They are regulated but the requirements are completely outdated and irrelevant in a risk context. And then you have banks such as Boursobank (a French online bank) that has weak traditional authentication (and a faulty app, but they do not care) and out of the blue also provides passkeys. Making it at the same time horribly bad and wonderfully good. The worst part is that they hide behind regulations when in fact there are only few of them. Other instiytutions such as SWIFT are as bad and equally arrogant.

dspillett 10mo ago

> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. It would also stop a lot of genuine submissions unfortunately, as some literally can't pay not just won't pay (for both technical or financial reasons), and adds complexity¹. Each project working this way will need to process a bunch of payments and refunds on top of the actual bounty payments, which is not admin free nor potential financially cost free. I can't think of an easy answer that would work for more than a very short amount of time. As soon as there is money involved and an easy way to use tooling rather than actual effort/understanding to be involved, many will try to game the system ruining it for those genuine participants. Heck, even if the reward is just credit² rather than money, that will happen. Many individual people are honest and useful, people as a whole are a bunch of untrustworthy arseholes who will innocence you and the rest of the world for a penny or just for shits & giggles. > Assuming the host of the bug bounty program is operating in good faith This is a significant assumption. One that is it harder to not be paranoid about when you are putting money down. > they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password This does not surprise me. My primary bank (FirstDirect, UK) switched the way I authenticate from “between 5 and 9 alphanumeric characters”³ to a 5-digit pin, and all their messages about it assured me (like hell!) that this was “just as secure as before”…⁴ -------- [1] Needing a payment processing option that is compatible with both the reporter and reportee, at the point of submission. At the moment that can be arranged after the bounty is awarded rather than something a project like curl needs to have internationally setup and supported before accepting submissions. [2] ref: people submitting several simple documentation fixes, one misplaced comma or 'postrophe per pull request, to game some “pull requests accepted” metric somewhere. [3] which wasn't ideal to start with [4] I would accept the description “no less secure than before” if they admitted that the previous auth requirements were also lax.

greggsy 10mo ago

PIN only isn't too uncommon for online banking these days. You still need to complete a SMS auth to do anything other than view records though, like transfer money.

shevy-java 10mo ago

It may stop it but it may also hinder real people contributing. How many people want to pay a free in order to "contribute"?

entuno 10mo ago

There's also the issue of what happens to my money as a researcher. Is it paid to the company, or is someone holding it in escrow? What if it takes the developer months to respond, or they never do? Do they just get to keep my money indefinitely? What if the vendor pulls out of the scheme? What if I do a chargeback on the payment I made? Etc, etc I wonder if a better model would be to make the platform pay to entry, but not the specific bugs? So you have to pay a fee to gain access to a platform like HackerOne, and if your signal:noise ratio gets too bad then your account gets revoked? That would make it feel like less of a gamble than having to pay for every individual bug - but still has the same problem that it's putting a big barrier in front of legitimate good-faith researchers.

latexr 10mo ago

> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. That adds an extra layer of complexity to the cURL maintainers, handling other people’s money and whatnot. It was considered. Daniel (cURL’s lead) has been discussing this for months. Whatever “quick and easy” solution you think of, it’s already been suggested and thought about and rejected for some reason.

billy99k 10mo ago

I've been active in the bug bounty community for almost 7 years now. The problem is that the majority of companies don't act in good faith. Even when you have something fully exploitable and valid, they will many times find some way to not pay you or lower the severity to pay you very little. The catch-all excuse is something along the lines: "although this is vulnerable, it doesn't impact the business". I've gotten this excuse, even when I could prove it was a production server with customer information that I could access. Sites like Hackerone can help, but in the end, it comes down to the company running the bug bounty program.

smusamashah 10mo ago

Github can use youtube strikes like system. PRs are tied to people. Someone reported for submitting slop should get a badge or something similar. If a PR is submitted by someone who is then known to submit slops, they can be easily ignored by the maintainers. EDIT: Or may be something like SponsorBlock for youtube. There could be a browser extension that will collectively tag sloppers the sameway and can help identify sloppers.

Hendrikto 10mo ago

> I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security. This is the key insight. Nobody cares at all about actual security. It is all about checklists and compliance.