Contents
Intro
I've seen a few blogs recently and tweets talking about authentication and handling passwords, it got me thinking...
I'm going to start by caveating.
I'm all for learning how authentication works, if you're anything like me, I learn best by doing, so I've played around with authentication locally. But don't roll it out to production.
Why
Authentication is often the linchpin in the security of your application.
If we've seen anything over the last few years that data breaches of applications are only increasing, so application security has to be top of the priorities.
There is plenty to think about too about securing your application even before you get to your authentication system.
Thinking about writing your own authentication?
What about cookies?
Cookies are plaintext, so you don't want to put anything secret in there and visible to anyone using the computer.
Is it using the Path argument to limit the cookie to your application?
Is it shared over subdomains?
It is Secure and only available over HTTPS connections?
What about Cross Site Scripting (XSS) attacks?
Browser Storage
Okay so you've dealt with cookies.
But maybe your storing data in browser storage - please never store anything sensitive or personal identifiable information (PII) in browser storage - have you ensured this is as secure as possible? e.g. using session storage rather than local.
Rate Limits
What about limiting the number of requests? So that someone could not keep trying lots of different passwords.
How are you going to implement rate limiting? IP based; cookie based etc.
Do you lock out specific IP addresses after X attempts?
What about valid users who get locked?
Password Security
Now let's talk about passwords. Are you going to set password requirements? If so, what are you going to make them?
Are you going to check if that password has been compromised using https://haveibeenpwned.com/ for example?
How are you storing the passwords? What happens if someone puts in a really long one, say generated by a password manager, is it going to get truncated? (I've seen this happen many times)
How are you hashing and salting the passwords?
Please Please never keep passwords in plaintext.
Database security
So, you're storing them in a database somewhere.
How are you protecting that database to ensure its not breached?
If the database does get breached how are you limiting that to as few records as possible?
What about the network security around the database?
The list goes on, and on and on and on...
Options
So, you're thinking alright, you've made your point, so what options do I have.
Well, fortunately you are in luck! There are now plenty of IDaaS (Identity as a Service) offerings.
They often have great free tiers, for example Azure B2C has 50,000 Monthly Active Users...FREE!
As with anything you need to find the best for your use case so I'll list a few below for you to check out:
Auth0
Azure AD
Azure B2C - Business To Customer
AWS Cognito
Firebase Authentication
Okta
OneLogin
Magic
Twilio
These companies have literal teams of people working to ensure that their authentication is secure and it's their business to make sure it is!
Summary
In summary, authentication is hard! There is a lot to think about, my list here only scratches the surface and some of it you will still need to consider e.g. general database security.
But there are plenty of authentication providers you can use, even for free!
Stick to what adds value to your application/business! Leave the authentication to the companies whose job it is :D
Let me know your favourite authentication providers below!
Happy building!
Photo by Micah Williams on Unsplash
Top comments (26)
I view this more as an incomplete list of pitfalls rather than a course of action.
There are good reasons to roll your own, even if that might only affect a minority of cases. Anyway, what I advise is not to read such articles as "don't roll your own" but rather a "be aware of what you are doing".
Those cited experts didn't fall from the sky, but went through the regular learning cycle before specializing in their field. These kind of articles always make me worried that people might take it as "this topic is too complex for you, don't even start learning".
And the author thankfully started out by making clear that this is not how you should look at it. Just wanted to reiterate.
Thank you!
There is definitely a problem with suggesting we leave it to other companies as though we are incapable of the security ourselves. The truth of the matter is that those companies are "reinventing the wheel." There are backend frameworks, such as Ruby on Rails, built to maintain security through password hashing, automatic CSRF attack protection, JWT web token gems, and pretty much all.the security you need. Front-end libraries like React also take care of security measures on the client-side.
If you suggest we "leave it to the experts" persay, you're leaving no room for aspiring developers to become that expert. There is a lot of value in encouraging people to not only understand how to use the technology, but also WHY it works the way it does.
I would never say that people are incapable of it, there are plenty of people and applications that do a great job!
However, I would rather (and encourage everyone to) spend time building the value that my application provides than setting up auth every time and all the associated things that need thinking about. :)
I would encourage everyone to read and play around with learning how authentication works and the principles, however that is not a reason to roll your own out into production.
Splendid argument for doing what's good for your own (or your organisations) goals, and paying trusted experts do the stuff you need to run a service online but isn't your unique value!
I will add more to your argument: many of the quoted 3rd parties also support multi-factor authentication (which now becomes a selling point for you), and by designing your own product to use an external auth provider, you are setting yourself up for much easier integration with your large customer's own auth systems when that day arrives, finally: do you really want to operate a customer support team that spends 80% of the time helping with password resets (I have the stats from a large platform my previous employer runs), when your customers already have a perfectly good login platform... :)
Oh - did I mention support for API keys, machine-to-machine authentication....
Depending on your product/service, you may also be happy to accept authentication from social media platforms (login with FB, or Twitter, or Github...) @see this very platform for samples!
Yes, that is a great shout on the social media platforms and API keys!
Thank you! :D
Because password dumps are inevitable,, I have encouraged users and friends the generation of strong random ones. The browsers offer it, you could roll in your own. View source on my pwa programtom.com/dev_examples/Strong... . The browsers also are able to save the logins, or, the users could use third party. As being something super important, we, developers should and must write tests to validate the security. This is something we must do, If we do not delegate to others.
I think there is so much that developers have to consider, so in my book the more I can hand off to experts/companies providing services the better! I can then focus on the value I'm bringing :D
There is some sense, logic, truth to that, until you get big enough. After that, it may actually become a weak spot.
haven't heard of all of the IDaaS that you listed But most of them I know are not free. To add to your list, I recommend:
Thanks :) I think most of them have a free tier as opposed to being completely free. But the free tiers are probably suitable for most applications :)
You still need to handle rate limiting and database security even you use IDaaS. I think we should not implement our own "approach" of auth instead. There are standard ways to do it.
Yes, I agree there are definitely things in my list you'd still need to consider :)
Even with the standard ways, I think time would be better spent adding value to my application.
How to delete my password from haveibeenpwned.com/ ? I emailed them a list of my passwords but there's no reply.
Your passwords are already out there in the open, exposed through data dumps, shared on the Internet and used by crooks.
"Have I Been Pwned" only makes you aware of those leaks, meaning that you should not use those passwords anymore. The only thing you can do is replace those leaked passwords by new ones. Use a password manager for that and random generated passwords.
It's probably worthwhile reading their FAQ to better understand what the service is about, what data leaks are, and how their leak data is stored: haveibeenpwned.com/FAQs
My password was in Top 5 DEV Comments of the week of 2020-Oct-29. It of course is out in the open.
dev.to/devteam/top-5-dev-comments-...
Good for you.
I understand the gist of the article but am strongly opposed to this sort of clickbait title.
For most use-cases it may make sense to use an external auth service, but there are also many cases where using an internal with system is preferable - even just the fact that you're not at the mercy of an external service and its subscription fees is justification enough.
Stop trying to convince everyone else that just because a certain rationale makes sense in your context, it should also be followed by everyone else.
Great article, really good to see someone fighting for good security!
Thanks Doug :D
I’d add SimpleLogin to the list of identity providers, especially if your app wants to promote privacy.
It's worth to mention that auth is not only provider but libraries as well. Eg on the frontend there are many of them for OAuth2, but if I'm not satisfied with their quality?
Thank you for the comment, I don't quite understand though, would you be able to elaborate? :)
Sure!
Assume you don't build your own authorization on backend but use External extensions from Okta for example, you still need to use their or any other js version for frontend authentication.
Unfortunately when it comes to JS frontend, many libraries are not quite good written to be used by every project.
Just because they should be broad enough to support multiple backend providers they are too complex and too buggy.
The real advice should be "Don't Roll your Own Encryption". That is something that should be left to researchers and scientists, as its a concept that must be mathematically proven.
I dont want any of these. I want complete control of my data and service. Keycloak is open source but uses Java, you know anyone that does node?