Regardless, this is an example of why cloud communication (and ticketing and database off-loading [see MongoHQ] and...) systems probably won't ever become commonplace in most of the government space and the finance and health sectors.
1. VPNs are almost always terrible for security because people tend to get them for one need (i.e. email, one line of business app, etc.) but when their computer gets compromised the attacker now has access to the superset of everything which every VPN user has ever needed to access and in all likelihood a bunch of other things which were never intended to be exposed but were never adequately firewalled internally.
You can't prove your cloud provider is using security best practices, while you theoretically can prove (or disprove) the same internally. Few companies do proper auditing, reviews, and pentests, but they have the capability to do so.
But you don't have to. They do. Look at Amazon. They publish their security audit each year, and now every company that uses them doesn't have to do their own audit. They can point their auditor at Amazon's report and say "see our datacenter passes".
Also, do you do a security review on your power company, or do you assume they've done it?
I don't know how common this line of thought is in security. But if it is common, then if you're a small company, aren't you better off not hosting my stuff at these large companies, because it's putting information you collect with someone who is more likely to be "interesting" to the right people?
If you think you haven't been hacked, you probably have (or you are so small that you may have only been probed by bots).
If you haven't actually been hacked yet, it is only a matter of time. Ideally you start designing security layers now, before you are compromised.
I agree. We might not like rolling out our own instances, but it prevents hackers from being able to grab ALL THE DATA in one fell swoop. It really amazes me that some EHR systems have gone the cloud route.
Also, "cloud" for services like this means "your own private instance of the software running in a private VM in our datacenter" not "your own customer_id in a shared database."
Small companies typically can't afford competent and professional security analysts, engineers, penetration testers, and auditors.
I guess what I'm saying is that regardless of who you are, there is no easily discernible best practice playbook, just a sea of tradeoffs generally made by people with a woefully inadequate grasp of the risks involved. Heck, even the best security people are at a disadvantage in the asymmetrical battle of infosec.
It's why your gmail account is more likely to get hacked than my piddly self hosted imap server. Google's network security is unarguably better than mine, but you are never going to social engineer your way into changing my password, which is actually doable with gmail (happened to my sister in law).
I think you have to assume that you're going to be hacked if you're a big enough target. You don't know what you don't know about your vulnerabilities. The better question is how you're going to design your data and platform to minimize the damage a major hack can do.
Nevertheless, in all implementations I am aware of, the default for that parameter is 10. And earlier, you wrote:
> If they used ten rounds, it's dire, and just saying "bcrypt" doesn't say much unless you also specify the number of rounds.
tedunangst and I both assumed you were referring to the default 10 work factor of BCrypt and were calling it "rounds" as many of us are doing.
The obvious question that tedunangst is asking (and others in this thread) is whether a work factor of 10 is considered too low.
Targeted cracking attempts against specific hashes are definitely still an issue though.
To you have a credible source for the "10..12 is too low for 2015" claim?
HHVM 3.6 on a small Ubuntu server
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(11))", setup="import bcrypt", number=5) / 5
0.13497538566589357
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(12))", setup="import bcrypt", number=5) / 5
0.28287739753723146
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(13))", setup="import bcrypt", number=5) / 5
0.5341608047485351
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(14))", setup="import bcrypt", number=5) / 5
1.069920015335083
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(15))", setup="import bcrypt", number=5) / 5
2.151028203964233
That's five repetitions of a bcrypt hash with the work factor passed in bcrypt.gensalt(). The resulting units are seconds.
Good thing you made me re-measure :) That makes 13 my new bcrypt default.