If you're new to web application development and security, don't blindly follow the advice of someone else who is also new to web application security.
You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant.
Security is a hairy issue, and no single blog post/article is going to distill the nuances down in an easy to digest manner.
If you are a business, then definitely yes. But the average self-taught developer will not have the resources available to hire a security consultant.
Instead of throwing money at the problem, you can instead choose to teach yourself more about the subject. We maintain a curated list on Github for people interested in learning about application security for this very reason.
> If you are a business, then definitely yes. But the average self-taught developer will not have the resources available to hire a security consultant.
True. You don't need to hire consultants to perform a security audit. Ask HN and Security Stack Exchange are good free alternatives to get critiques on your approach.
If you build something open source and it gets incredibly popular, security researchers will also probably come to you. This creates its own problems, of course. (Can't have problems without PR.)
You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant.
It is easy to write that, and on the face of it, it's hard to argue against.
The trouble is, those audits and consultants don't come cheap, and if you're new at web apps and working on your first one that no-one has ever heard of yet, there is little really essential that you wouldn't find investing the same time reading the usual beginners' guides to security on-line. It's all risk management, and if you even make that effort you'll already be a significantly harder target than many established sites.
As a corporate lawyer once told me when I was getting the very first contract drawn up for a new business, for a simple supplier relationship, he could certainly charge me five figures and write an extensive document protecting the business against every conceivable threat he could imagine involving that supplier, but until the business had actual revenues worth protecting and the deal with that particular supplier was worth a lot more than the legal fees, he wouldn't advise doing it.
Security is never perfect. It is a deterrent, not impenetrable prevention. So sure, to security people, it is never good enough. To everyone else, a easy to digest blog post might give them food for thought that would make their work one step better than it was before, resulting in security that is still flawed, but better. So why not just accept the post for what it is - some basic advice to do that one better step.
Do you honestly feel that the work of beginning web developers falls into the same risk management quadrant as a major governmental database of personal information?
Security is never perfect, and to security people, we know that there is a tradeoff between Security and Users.
We don't advocate letting The Perfect be the Enemy of the Good when it comes to security, and on the same token we want you to implement security properly if you do it.
Since the security advice in the article is bad, this is more the case of the wildly incorrect is the enemy of the reader who takes the advice. Somewhat different.
This is something we help with a lot at Tinfoil (https://www.tinfoilsecurity.com). You can read our blog for useful tips and info, but we always recommend actually running our web application scans against your app in order to actually look for vulnerabilities. Is it as good as having 'tptacek or someone else from Matasano looking at it as a human? Not quite, since humans have more ingenuity. Is it better than reading a blog post and trying to follow 'best practices'? Infinitely.
In general, you may be right, but the security suggestions in this particular post are the same I hear from people "who have experience in security." Also, they often encourage readers to basically go out and find the thing everyone says is the best thing (i.e. "When storing passwords, salt and hash them first, using an existing, widely used crypto library.")
I challenge you to point out specific suggestions in this article which are wrong or misleading, or to point out glaring omissions.
Most (all?) encryption functions are also hash functions, they're just special hash functions with the extra property of making it extremely difficult to discover the source. (edit: I realized after posting this, that this item is incorrect in regards to the cipher text, which obviously changes in length in relation to the length of the source, unlike the output of a hash function which is a fixed length)
If OAuth is not for authentication, someone better tell Google: "Google APIs use the OAuth 2.0 protocol for authentication and authorization." [1]
TLS is basically just the newest version of SSL. The name was changed for legal reasons. So it is an understandable oversight [2]
The others aren't security related, so I didn't address them.
> Most (all?) encryption functions are also hash functions, they're just special hash functions with the extra property of making it extremely difficult to discover the source.
The special property that encryption functions have compared to hashing functions isn't that it is extremely difficult to discover the source, but rather almost the reverse -- that for every encryption function there exists a function (decryption function) by which you can recover the unique source.
Hashing functions in general do not have an inverse function: while you might be able to recover several possible sources from them (and this might be easy or difficult), you cannot recover the single source, because the space of inputs is larger than the space of outputs, so there can be no unique mapping from outputs back to inputs that would generate them.
Most (all?) encryption functions are also hash functions, they're just special hash functions with the extra property of making it extremely difficult to discover the source.
There's a fundamental difference between storing a password so that you can read it again (encrypt implies this), and storing it so that you can only verify it, not read it (hash). But a broader criticism of the article is that it is far too sweeping in its judgements based on scant knowledge of the topic - the little mistakes are just indications of that.
It's fine to be a beginner asking questions and the mistakes are not really so important, but it's not really useful to attempt a definitive summary of a field which you know very little about.
Can you explain why OAuth is not for authentication? What does it not do that you expect an authentication system to do? What is fundamentally wrong with every site that allows me to sign in with a github/google/facebook account (via OAuth)?
> What is fundamentally wrong with every site that allows me to sign in with a github/google/facebook account (via OAuth)?
That is a inaccurate statement.
Those sites allow you to login with your Github/Facebook/Google Accounts. That isn't OAuth. Those sites also use OAuth in order to let 3rd party applications access the users data stored on that system.
Take this Scenario
Alan has a service that finds funny tweets.
cpitman wants to use Alan's service, to find his funny tweets.
No OAuth Example:
cpitman gives Alan service his Twitter Username and Password.
Alan service logs into Twitter, and pulls twitter data.
With OAuth:
Alan service opens a request to Twitter asking for twitter data for cpitman
Alan service redirects cpitman to Twitter
Twitter notifies cpitman that Alan Service wants to access twitter data
cpitman agrees
Twitter passes back a token
Alan service uses token to access cpitman twitter data.
People usually use OpenID for that bit and OAuth for the authorisation to use the third party APIs as the customer. There's nothing horribly wrong with third-party signin if it suits you and for smaller projects however it does limit your relationship with customers and tie you in to third party services which might be charged for or shut down at any time, so it's not ideal for many websites. It depends on your requirements.
If you can afford it, buy a proven security solution. For example use an IBM Datapower or ISAM appliance (or similar from F5). Enterprises will choose something like this to secure their many internal web applications.
You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant.
Security is a hairy issue, and no single blog post/article is going to distill the nuances down in an easy to digest manner.