[Please Upvote: https://bubble.io/ideaboard?idea=1675483720960x783112719269101600]
Bubblers often need to implement more-stringent login flows than a simple email/password combination, or even the built-in two-factor authentication. For example, the user may need to enter a secret pass-phrase, input a custom PIN, or even utilize a FIDO Compliant Security Key (here’s the plugin we built for the latter [still very early in beta, will update in next few days for a full working version]: FIDO Security Key Plugin | Bubble).
In order to build these options securely and effectively, we–the programmers–need to first ensure that the username and password is correct. However, we do not want to log the user in at this point, as we have yet to utilize our custom, enhanced security protocols (such as those mentioned above).
Enter the “Check a user’s password without logging in” workflow action. This action would allow us to verify that an email address and password exists, without logging the user in. If this action resulted in a “true”/“yes” value, we could then trigger our enhanced security (such as prompting for a passphrase or inputting a PIN). If these enhanced measures succeed, we would then utilize the existing login action with the email and password that has already been entered.
1 Like
The login action at its most primitive level is literally just a check on the provided user inputs. Pass = proceed, fail = stop. If a user successfully inputs their credentials, you move on to the next authentication piece before allowing said user access to more sensitive information. You’re really overthinking it. And it’s just not really necessary.
I disagree, and you’re also drastically over-simplifying what the login action does on the front end. It does not simply check the username and password. It also, if the credentials are correct, creates a new session and stores that session in the user’s browser. This session gives them full access as a logged in user.
MFA as I describe requires that a session isn’t created until after the verification method is confirmed.
I’m not sure how you think the login action works, but it does a lot more than you think it does.
2 Likes
A session is going to get created as the very first thing that happens when someone lands on your app. Then, a user can authenticate and get identified as a User or remain a cookie. 
Hence why I do not want them to be able to authenticate (by using the log in action) until I can verify the MFA!
The login action just helps identify who the current session belongs to. If the user who has been identified can’t pass the MFA then log them out, send an email to the account holder notifying them and terminate the workflow. This seems to me, a much easier solution than completely re-engineering how bubble identifies users. But I’m often mistaken, and I’m probably mistaken here. And so I’ll give you an upvote in the name of security.
@doug.burden no harm done man! Our main concern is that once the login action occurs, let’s say that the user has another page in our application bookmarked. If the user is not logged in, we would redirect them to our login screen; if they are logged in, we let them remain.
Expected Flow (under current Bubble setup):
(1) user logs in
(2) we run the “log in” action (user is technically logged in and could view the protected resource now)
(3) we redirect the user to the MFA screen
(4) user passes MFA => redirect to private resource
(5) user fails MFA => log them out
Security Vulnerability (under current Bubble setup):
(1) user logs in
(2) we run the “log in” action (user is technically logged in and could view the protected resource now)
(3) we redirect the user to the MFA screen
(4) user clicks bookmarked link to protected resource, without ever interacting with the MFA
(5) user never completes MFA, but views the resource
We could play around with things like “MFA Last Authenticated Time” as a date saved on the user, and if that date is in the past, redirect them, but this is re-engineering Bubble’s User session. It would be cleaner and a lot safer to just be able to verify a user is who they say that they are without the “Current User is logged in” becoming true, doing MFA, logging the user in if the MFA passes (and only at this point would we log the user in and accordingly only at this point does “Current user is logged in” become true)
Security vulnerability number 4 I hadn’t thought about. But perhaps each page loaded could contain a conditional of whether the User’s sessions_verified = yes. I know I use this now for my flow. Even so, the user could have a glimpse of data before being redirected if session_verified = no.
I upvoted. Seems like a good idea to me.
1 Like
