3 ms·

Authentication is rarely something I want to write myself. There are many security concerns that need to be considered, many that I forget about. Libraries like

Authentication is rarely something I want to write myself. There are many security concerns that need to be considered, many that I forget about. Libraries like devise are well thought out, and have been security hardened. I'd much rather use an established authentication library or service than roll my own. At higher scales, I've written authentication middleware services when performance was critical and we had complex auth needs, but as a starting place for a new app, I would not roll my own.

debarshri 4y ago
I think it really depends. Sometime you want to have control over the process, and if you have experience building authentication before i would recommend doing it yourself rather than working with an abstraction defined by a library. I have seen first hand with tools like fusion auth when you hit the situation which cannot be resolved while adding more complexity to your product, I would rather start building it into the product than increasing the product complexity and working with an abstraction you dont have control over. Again take advice with grain of salt.
- bvirb 4y ago
  Imagine you want to stop someone from brute-force password attempts on your users. You could add some code to lock a user out after a specific number of attempts within a given time period for that username. But then say it's a real user and they forgot their password and they want to get back in without having to wait. You might then allow them to reset their password (which requires re-verifying access to their email addresses) and immediately reset the lock so they can get back in. But then since that functionality technically allows anyone to have your app send a password reset email to any of your users without authentication you might want to limit the rate at which those resets can be requested. None of that is particularly hard, but it's a lot to build, test, and maintain. Start throwing in more account features you might take for granted elsewhere (MFA, recovery codes, re-enter current password to change your password, allow a user to sign out of all their sessions, etc etc) and you could find yourself spending all your time building your user system instead of your application features. I would guess, for most applications, user systems are standard enough that rolling your own isn't going to be worth the possible additional customization.
  - debarshri 4y ago
    I dont think you need these features from day 1. My advice should be taken with grain of salt. If the effort of building these features is alot in your product, then yes you should buy into a library or a service or a product. But you also buy into the complexity these product bring that might not be relevant for the project you are building.
  - nokya 4y ago
    You identified the threat correctly (legitimate users being prevented from using the app because they forgot or lost access to their password) but the measure you proposed exposes the application to a new threat (attacker can lock accounts without authentication). Now I would typically task you with an exercise to improve your design so that the password reset mechanism, once triggered by an unauthenticated user ("reset password" is clicked) does not result in locking the legitimate account. After a few minutes, you would likely come up with a new protocol that consists in two steps instead of one: 1. Unknown user triggers the password reset mechanism by submitting an email address to the "reset password" form. 2. Legitimate user receives a password reset link by email. If the link is clicked, the legitimate user is redirected to a prompt to provide new credentials. If the link is never clicked, nothing happens. enjoy Then I would challenge you again with a new threat: "Now we have a new problem. Instead of locking user accounts randomly, the attacker could just write a script that submits the password reset form repeatedly for hours, thus triggering thousands of emails and severely disrupting both our users and our email gateways." You would say "oh! that's a great challenge!" :) And a few minutes later, you would likely come up with the solution to implement a CAPTCHA equivalent in the first stage of the password reset mechanism to reduce the likelihood automation. enjoy Then I few months later, I would challenge you again with a new threat: "It appears that someone has devised a technique to bypass our CAPTCHA mechanism. We need to find something else." You would say "oh! that's a great challenge!" :) And a few minutes later, you would likely come up with the epiphany that no, this part of the challenge is actually not that great because we simply reached the final stage of our analysis that basically requires monitoring the world for new research work that would ultimately cancel the benefits of our CAPTCHA mechanism and force us to find something else. But that part of the challenge is for another team ;)
chucke 4y ago
Devise has not aged well. It's quite complex for the functionality it offers. Does not support json api mode. Only supports email/password. It's account creation flow is too simplistic for what most apps require OOTB.

debarshri 4y ago

I think it really depends. Sometime you want to have control over the process, and if you have experience building authentication before i would recommend doing it yourself rather than working with an abstraction defined by a library. I have seen first hand with tools like fusion auth when you hit the situation which cannot be resolved while adding more complexity to your product, I would rather start building it into the product than increasing the product complexity and working with an abstraction you dont have control over. Again take advice with grain of salt.

bvirb 4y ago
Imagine you want to stop someone from brute-force password attempts on your users. You could add some code to lock a user out after a specific number of attempts within a given time period for that username. But then say it's a real user and they forgot their password and they want to get back in without having to wait. You might then allow them to reset their password (which requires re-verifying access to their email addresses) and immediately reset the lock so they can get back in. But then since that functionality technically allows anyone to have your app send a password reset email to any of your users without authentication you might want to limit the rate at which those resets can be requested. None of that is particularly hard, but it's a lot to build, test, and maintain. Start throwing in more account features you might take for granted elsewhere (MFA, recovery codes, re-enter current password to change your password, allow a user to sign out of all their sessions, etc etc) and you could find yourself spending all your time building your user system instead of your application features. I would guess, for most applications, user systems are standard enough that rolling your own isn't going to be worth the possible additional customization.
- debarshri 4y ago
  I dont think you need these features from day 1. My advice should be taken with grain of salt. If the effort of building these features is alot in your product, then yes you should buy into a library or a service or a product. But you also buy into the complexity these product bring that might not be relevant for the project you are building.
- nokya 4y ago
  You identified the threat correctly (legitimate users being prevented from using the app because they forgot or lost access to their password) but the measure you proposed exposes the application to a new threat (attacker can lock accounts without authentication). Now I would typically task you with an exercise to improve your design so that the password reset mechanism, once triggered by an unauthenticated user ("reset password" is clicked) does not result in locking the legitimate account. After a few minutes, you would likely come up with a new protocol that consists in two steps instead of one: 1. Unknown user triggers the password reset mechanism by submitting an email address to the "reset password" form. 2. Legitimate user receives a password reset link by email. If the link is clicked, the legitimate user is redirected to a prompt to provide new credentials. If the link is never clicked, nothing happens. enjoy Then I would challenge you again with a new threat: "Now we have a new problem. Instead of locking user accounts randomly, the attacker could just write a script that submits the password reset form repeatedly for hours, thus triggering thousands of emails and severely disrupting both our users and our email gateways." You would say "oh! that's a great challenge!" :) And a few minutes later, you would likely come up with the solution to implement a CAPTCHA equivalent in the first stage of the password reset mechanism to reduce the likelihood automation. enjoy Then I few months later, I would challenge you again with a new threat: "It appears that someone has devised a technique to bypass our CAPTCHA mechanism. We need to find something else." You would say "oh! that's a great challenge!" :) And a few minutes later, you would likely come up with the epiphany that no, this part of the challenge is actually not that great because we simply reached the final stage of our analysis that basically requires monitoring the world for new research work that would ultimately cancel the benefits of our CAPTCHA mechanism and force us to find something else. But that part of the challenge is for another team ;)

chucke 4y ago

Devise has not aged well. It's quite complex for the functionality it offers. Does not support json api mode. Only supports email/password. It's account creation flow is too simplistic for what most apps require OOTB.