We have all heard of the leaks major corporations can have and don't hear at all about the 30 million cyber attacks each year.
Which leads us developers to get cold feet when it comes to storing users sensitive data.
What Do I Do?
Personally I have started using gems such as Omniauth and forcing users to use their provider of choice as the secure entry point into my own application.
Why spend time and resources storing their sensitive information when we can authenticate them via a third party application? (Who most likely has spent more time and money keeping their users safe.)
Thus coming to my conclusion...
All we need is a users email, their third-party login of choice, and that returned UID from said third-party.
- Fully authenticated user
- We get more information than a user would have to input themselves
- No blame on you if a third-party has compromised passwords
Discussion
What are your thoughts on this matter?
- Do you prefer using third-party authentication systems for your applications?
- Do you disagree with me and think we should still be storing user sensitive passwords?
- How do you go about securing your application users data?
Top comments (7)
While I haven't used any myself yet, I think there is a huge advantage to using third party services. It's just so much faster to use them and have all the popular Google, Facebook and Apple login methods ready alongside password reset logic.
But when you have the time and resources to develop your in-house methods, maybe you would have more control over what could happen.
Exactly what lead me to the idea of only using them for authentication and allows me to spend more time on building out the rest of the application.
There are some disadvantages to be aware of:
That being said I think using both is probably the best way to go! Thanks for your thoughts.
I actually don’t agree with this method at all, the idea of a user signing up to my service but storing their sensitive data on a 3rd party where I don’t have control is worrying. Especially from a privacy control point of view.
Also, there is no promises that 3rd party services actually store anything more securely than you can. I would more argue the fact this makes it less secure as there is now a way for a malicious user to access a users account by either compromising the 3rd party (which you would never know about because you can’t monitor this), or somehow tricking your service into thinking you received the correct UID.
At the end of the day, as long as you securely hash a users password and ensure that database access is restricted, you have a really secure application. Regardless of whatever security you have, a users account is only as strong as their password.
Thanks for your view point!
It also is a downfall considering that most O-Auth application extensions are maintained by open-source contributors.
As for compromising the UID this is solved via gems such as devise that require user authentication via authenticity tokens to prevent malicious attacks like this. Although I agree it definitely would be easier for someone to fake your UID/email and somehow trick your application into registering/appearing as you rather than trying to un-hash your users passwords from a restricted database.
Thanks again for your comments.
Hi A.J. and thanks for your article! I'm currently developing a web app and when I designed the login system I spent a lot of time trying to decide if I should use 3rd party systems or roll out my own.
But there is one thing that made me go my own way, and it's the fact that to change some critical settings I want users to enter their password. How could we do this if we use a 3rd party system? With a 3rd party system we don't have the password so the only way would be maybe sending a confirmation email...
Is there something I'm missing here? Do you think there is any way to do what I want using a 3rd party auth system?
I believe passwords are the tip of the iceberg, and are a problem only because a password leads to systems & data.
Sure, if you don't store the password, there is less chance that it's compromised, but that doesn't reduce at all the risk of data leak from other components of your app, including what can still be personal information, or confidential information.
You might not be the one to leak the user password (which, let's face it, they probably used everywhere), but you can still leak a lot of data and get blamed for it.
Thank you for your comments. Between you and Bailey I think I've decided to just buckle up and handle my own data and ensure it is secure.
I like what you said about how ( 'they probably used everywhere' ), because this is kind of my original thought on the matter. If they have a very weak password for an oauth application this could make it less secure, and vice versus.
I believe the best way to solve this is just by making sure the database is secure and rather not leave it up to a third party provider for authentication.