Are custom states secure?

I am trying to build my own 2FA authentication system since it’s unacceptable to have to pay for the Growth plan to offer 2FA to users…

The workflow is like this:

WF 1:
log user in → log user out → generate a random string of 7 numbers and set it as a custom state of the page → send an email to the user with that string

WF 2:
log user in (conditional state: only if the value of the input is equal to the custom state of the page that contains the code)

Since the code is stored as a custom state of the page, would it be possible to inspect the browser and find it?

While I’ll leave it to someone with more experience in security to answer your question, I’d just like to point out this would be a UX nightmare on mobile.

As custom states reset on page load, if you have a user who is trying to login on a mobile/tablet device, they could open a new tab to go to their email and retrieve the code. When they switch back to the the Bubble app tab, sometimes the page will reload.

This will result in a loop nightmare.

I have experienced this many times myself.

I don’t pretend to be a security expert, but I definitely wouldn’t use a custom state to implement a 2FA feature, and you can refer to this post from Sam at Bubble for details.

Could you use a magic login link instead? I mean, the user would still have to have access to the email account to which the link is sent, so it essentially accomplishes the same thing.


No, magic links require the user to open the email from the computer whereas a simple code is enough to be seen on the phone and copied over on the PC.

If they are not so secure, I will implement the same thing but instead saving the code temporary in the database using the temporary user feature. Do you see any security problems with this?

If the user can get the 2FA code from an email on their phone, I would think they could click a magic login link on their phone, too.

Anyway, as long as you protect the data type/field where you are storing the code with privacy rules, then I believe it would be as secure as you can make it.

Sure you are right. What I meant is that if the user clicks on the link from his phone then he will access the app from the phone and not from the pc (which is where he wanted to log in).

1 Like

Yes this can be made secure. It’s a method I’ve used. On page load > Calculate RandomString:Length of characters:6:Use numbers = checked.

On your app, you might have a login page where you’ll want to redirect the user to in your corresponding email.
So what you’d do then is, create the link to send the user to and append a querystring of this code and use it in the email. Here’s how that would look.'s code state

When the user tries to login and gives the code they’ve received, you’ll grab this code from the url and match the Input field for the verification.

Want to send a text instead?
You’ll need their phone number and their carrier’s gateway. Let’s assume ATT.

Your email will be sent to which will send a text message.

Gateway’s to send free texts via email

  1. AT&T: (SMS), (MMS)
  2. Verizon: (SMS), (MMS)
  3. T-Mobile: (SMS & MMS)
  4. Sprint: (SMS), (MMS)
  5. Xfinity Mobile: (SMS)
  6. Virgin Mobile: (SMS), (MMS)
  7. Tracfone: (MMS)
  8. Metro PCS: (SMS & MMS)
  9. Boost Mobile: (SMS), (MMS)
  10. Cricket: (SMS), (MMS)
  11. U.S. Cellular: (SMS), (MMS)
1 Like

Just clarifying, so the code the user inputs will be matched to a parameter in the URL?

1 Like

Yea, assuming part of the login workflow is having them enter the code they received via email and matching the param in url.

I like this, never thought about it that way!

Most users aren’t savvy enough to notice these things but there are those that might. Maybe a simple encryption or mathematical equation to hide the code will be safer.

Can use some Javascript for basic encrytion/decryption or something simple like numerical code X current date:formatted as yymmdd will be passed through the URL then verified by division. Since you’re using yymmdd, the code automatically has a 24 hour expiry. You can even add additional parameters as part of the equation.

What am I missing, @doug.burden? @hoke asked about using a custom state, and I don’t see a reference to a custom state in your write-up. I’m not saying it’s not a good way to go, but again, the question was whether or not implementing 2FA via a custom state is secure.

@mikeloc On page load of generating a random string, that’s what you’d set this state to. And then you’ll also notice I referenced this state in the url in the email. I also answered that it is in fact secure. I ALSO provided free advice on how to send free text messages to users via email. All that would be required is a little extra data extraction from user upon sign up such as inputting their phone, and their carrier.

Ah, okay. Well, I said I don’t pretend to be a security expert. Sorry for muddying the waters, @hoke, but it looks like a custom state can be a secure way to go (even though Sam’s post appears to say the opposite, which is why I replied with that link). Thanks for clueing me in, @doug.burden… much appreciated.

There’s little to no room that a code generated on page load for a workflow that dissolves the current session on specific page, since user has to be redirected to a new page and this state doesn’t exist anymore. Not to mention if you add the fact you could go thru the effort of encrypt and decrypt as @ihsanzainal84 has mentioned. But f me right? @mikeloc

I’m not sure what that’s about… I was genuinely thanking you.


@mikeloc Bubba, I’m not gonna sit here and pretend you didn’t try to backhand compliment me. I hope you have a good day and a better tomorrow. I love you, we out here.

what exactly is the purpose of a code generated from the page for 2fa?
The page is loaded after the first auth method. If you create the code there the user has access to it without need to receive an email or a text and the whole purpose of a second auth is lost.
There is a reason why the magic link is not available to use in frontend actions.


Yeah, agreed. The point is to make sure they have current access to that second method of authentication. If you generate the code in the browser there’s a chance of it being exposed to someone who knows what they are looking for.

@hoke I’d recommend looking at Twilio Verify to manage this. It’s a super simple and secure API for sending and verifying codes.


Generate the code from the backend and email.

1 Like

And super expensive compared to being able to do this natively.