Earlier quoted context omitted.
Bitcoin is much easier (and faster) to acquire than to liquidate. I'd rather be paid in cash.
You can liquidate bitcoin in about 5 minutes using Coinbase.
took me a week to get my bitcoin.
I found Prezi's source code
161–170 of 266 posts
Re: I found Prezi's source code
#162The guy found and brought to their attention a simple exploit that could have seen valuable source code released into the wild and the guys at Prezi are debating about paying him a bounty?
Does this mean that Prezi do not value their code and don't believe there would have been any significant loss if that code became public?
Are they saying that the next person that discovers serious flaws in their security should just keep quiet - or sell it on to some hacker, where at least they can make some money from it?
Just what message are the Prezi people trying to send by nit-picking over $500?
Re: I found Prezi's source code
#163Why even have a limited scope on bounty programs? (This is not the only time I've seen that.) Is it only to limit payout? Are their legal reasons? For example, their client tablet applications are ineligible. I just don't get the reasoning. In their position, I'd pay him the $500 and remove the idea of scope. I'm just curious if there's some counter-argument I'm not thinking about.
[deleted]
We continue to have internal discussions about whether we should give this guy the $500 reward.
My advice would be to add up the hours of the people who have contributed internally to this discussion and then multiply it by their hourly rate, then try and add in the rough cost of the delay from these people not spending time on their current projects, add a 30% fudge factor for organisational overhead, add on the $500 that you owe anyway, then double the result and pay that, just so you don't feel like doing this again.
Re: I found Prezi's source code
#164Earlier quoted context omitted.
'Just want to add that this shows a very large misconception in the corporate security world. Security is not something you can get a "B - good effort" for. Security is all encompassing. You either get an A+ and the hacker does not get in, or you get an F and your data is gone. There is no middle ground.' That's not true. There are substantially different levels of security required depending on the expected resource…
I disagree here - you've either lost the data or you haven't. You can make guesses as to the expected resources of the attacker, but if you're wrong and the attacker has more resources, then you might as well have not even bothered. As an example, you have some fairly non-sensitive private health records. Here are three approaches: (1) No security at all. You hope nobody is going to bother taking them and using them…
I think the idea the parent was trying to express is there is different risk appetites for various things/companies. If it would cost more than your profits to secure something 100%, obviously you need to look at other ways to go about it. Mitigation is a major force in information security. Mitigation isn't solving the risk, it's just making sure that the impact of the risk is low if it does get exploited. Likewise, while PCI data needs to be as locked down as possible, other data doesn't need that level of security because the tradeoffs are too massive to be cost effective or business effective.
What you should realize is that "security teams" are generally not responsible for the level of security at organizations. The information security team will generally present the risk to the business owner of that process, that data, that application, etc and let the business owner decide if they want to accept the risk, mitigate the risk, or avoid the risk. If I went to the CEO of Dropbox and told him the biggest security flaw in Dropbox is that users can share files with each other, he's going to tell me to jump in a lake because that's their entire business.
Nothing is 100% secure, and nothing can be 100% secure. I'm not agreeing or disagreeing with what Prezi is doing, but your notions of all-or-nothing security seem a little out of touch with the reality of business.
Re: I found Prezi's source code
#165Earlier quoted context omitted.
'Just want to add that this shows a very large misconception in the corporate security world. Security is not something you can get a "B - good effort" for. Security is all encompassing. You either get an A+ and the hacker does not get in, or you get an F and your data is gone. There is no middle ground.' That's not true. There are substantially different levels of security required depending on the expected resource…
I disagree here - you've either lost the data or you haven't. You can make guesses as to the expected resources of the attacker, but if you're wrong and the attacker has more resources, then you might as well have not even bothered. As an example, you have some fairly non-sensitive private health records. Here are three approaches: (1) No security at all. You hope nobody is going to bother taking them and using them…
"Because they tried" doesn't get a B. You're not graded on effort. What you're graded on - when it comes to defense as opposed to recovery, though both are a part of this - is how likely a breach is. Unfortunately, you don't always learn your grade (and when you do, it's bad).
"Gambling with security will always be a losing bet in the long run. Rather just make it secure. Going off some strange 'expected resources' is just asking for the time when your data somehow becomes valuable and those resources get brought (or more likely, one of your employees annoys the wrong person with too much free time)."
So, every site you deploy is going to indefinitely withstand armed assault by government forces?
Re: I found Prezi's source code
#166Earlier quoted context omitted.
'Just want to add that this shows a very large misconception in the corporate security world. Security is not something you can get a "B - good effort" for. Security is all encompassing. You either get an A+ and the hacker does not get in, or you get an F and your data is gone. There is no middle ground.' That's not true. There are substantially different levels of security required depending on the expected resource…
Almost by definition, there is only a secure access continuum for known points of attack. Once you breach the access layer--no matter how it's done--the game is over. - One copy of your data that is publicly writable is very insecure - One copy with credentialed access is better - Redundant copies with credentialed access and PK-signed master-slave synchronization is better still - Add periodic off-site backups to en…
Defense in depth is an important principle, and compromise of some but not all layers could be said to form something of a continuum, but I think a stronger case is that odds of a breach forms a continuum.
Re: I found Prezi's source code
#167Earlier quoted context omitted.
Well of course there have to be rules. Does spear phishing employees email accounts and using their password to access control panels count as a bug? I bet I could hack a lot of companies that way. Does being susceptible to a massive DDoS count as a bug? Cutting power to the building? I can't speak for Prezi, but it seems like they want people to test the security of their app, but not of their employees or back offi…
> Does spear phishing employees email accounts and using their password to access control panels count as a bug? Yes, because those control panels should require 2FA, so password-only access is a bug.
2FA is susceptible to spear phishing if all the attacker needs is a one time login.
Remember that credentials and tokens can be relayed.
Re: I found Prezi's source code
#168Earlier quoted context omitted.
[deleted]
To be frank, this isn't some minor display bug, he had access your source. In other words, this could have ended your company . He could have sold or leaked it. If naivety is stopping you from grasping the possible consequences, then go ahead and read about Adobe's recent mishap. You should be on your knees worshipping him.
Leaked source code does not end a company. Tone back the melodrama.
A legitimate company cannot use stolen code like that, and prezi isn't the type of service with ground breaking algorithms to copy into other code.
Re: I found Prezi's source code
#169This sends a worrying message to others - in future don't bother reporting vulnerabilities to Prezi, just obtain the source and sell exploits to the highest bidder. It's no wonder security researchers turn to black hat methods, when they're treated/compensated like shit for their effort. "Swag" in return for your source code? What a joke
"It's no wonder security researchers turn to black hat methods" -- this seems such a binary and pointless reduction of the options available. Yes, Prezi could have turned this into a PR and security win, and failed to capitalize; but the assumption that now the only option for a security researcher is to turn to the dark side is... pretty ridiculous.
Those who "turn to blackhat methods" do so because they want to make money and don't place a premium on the potential moral/legal/ethical issues at play in how they're doing it. They make a choice, irrespective of the shortsightedness on display by Prezi here. Don't conflate the two behaviors.
Re: I found Prezi's source code
#170Why even have a limited scope on bounty programs? (This is not the only time I've seen that.) Is it only to limit payout? Are their legal reasons? For example, their client tablet applications are ineligible. I just don't get the reasoning. In their position, I'd pay him the $500 and remove the idea of scope. I'm just curious if there's some counter-argument I'm not thinking about.
I think it's ridiculous, I've reported similar "out of scope" bugs and got no bounty for them.
Even worse are the companies that DON'T state any kind of bug bounty or instructions to report a security bug...
I found a data leak issue in one of the web properties of an S&P 500 company last week and I'm not sure if I should report it, because I feel that if misunderstood it could have negative consequences for me; and not having a security contact means I can't be sure the person I'm talking to understands my motives.