DEV Community

Discussion on: Developers Dilemma - Storing Passwords

Collapse
 
bailey profile image
Bailey Matthews

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.

Collapse
 
ajrom profile image
A.J. Romaniello

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.