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.
Encryption passwords is not hashing (think this was fixed after publishing due to comments below)
OAuth is not for authentication
SPA is not suited to all or even most websites, and is far from being 'king' in any sense.
CDNs have pros and cons, they don't suit everyone.
Localisation does not mean serving assets closer to home, but translating stuff.
Nothing better than SSL? TLS