Sign Up Using Phone and password

I’m trying to figure this out.

I’ve been working on this and maybe I’m overlooking something.

On my Signup page I have this:

I know a couple of the icons are not official and need to be changed, but…

it’s a work in progress right now.

Everything works good, but I have a question with the phone ‘signup’

When someone clicks on ‘signup with phone’ they get this:

Screenshot 2024-09-27 9.37.55 AM

There is a password field that is hidden:

Screenshot 2024-09-27 9.39.18 AM

The UI needs work, but right now I’m focusing on getting it to work.

So, the password field has an initial content set to that of the phone field…but it accepts it as the password when submit is clicked?

I’ve tested it and everything seems to work fine.

When the user clicks signup, they’re sent a text with a 6-digit code that they need to fill in on another group.

My question is this:

since the password is the phone number…but, only a person with access to that phone can get the code and submit it, does anyone see a problem with this?

I may be overlooking something here and maybe my mind isn’t thinking clearly.

Would appreciate any feedback you have.

1 Like

At first glance this doesn’t seem secure :sweat_smile:

Keep in mind that anything on the frontend can be manipulated - doesn’t matter if you hide it, doesn’t matter if you make it unclickable, doesn’t matter if you make it trasnparent. Conditionals are just a UX feature, not a security feature.

The server is the only thing that guarantees safety - some page workflows do run server-side so it’s not always super clear if something is set up safely or not.

Does the user sign up immediately after pressing the Signup button or after confirming their code? How does the correct code get enforced? With a conditional?

What’s your login routine? Whats stopping somebody from just logging in using somebody’s phone number as password?

2 Likes

Thanks for your feedback.

The text is sent to a specific number.

Only a person with that phone can get the code.

1 Like

Sadly that’s not automatically true.

I’ve seen so many instances of ‘secure’ codes being generated on the page and then sent via API to an SMS/Email provider. If the code is generated on the page then you don’t need access to the phone/email its being sent to - you can just inspect Dev Tools and see the code - its literally right there.

So how are you generating and checking the code exactly?

If you are routing the Workflow through the backend (and both generating and verifying the code in the backend), or if you are using an external service like Twillio Verify, then the code is not accessible from the frontend, and you will actually need access to the phone to get the code. If not, it’s not secure.

5 Likes

Ok, I see what you’re saying.

I’ll look into that.

Thank you.

I did some quick research when it comes to Bubble…

and from what I can figure out, the threat is there with email also…whether it’s sendgrid, postmark, etc.

So, I understand what you’re saying, but, I think the same rules apply regardless of if you’re also using email to sign a user up?

Bubble authenticate is not easy to work-around typically. At least with their built-in cookie/session system.

You ideally want a workflow/api that will search for users with that phone number. It’s best to keep a list of key/values somewhere with this information so you don’t have to search ALL YOUR USERS each time someone signs up, it can just refer to the KEY/VALUE pairs you have somewhere (With privacy). Be sure you track those key/value pairs when a user is create/removed/edited

You’ll need to make it so when a user wants to use phone, they select “sign in with phone” and you give them a field to enter their phone number in. Then have a submit button that searches for the key/value pair on that specific number (on the backend) and then match the correct email with their phone number.

In my opinion, it would be better to just email/message them their login link rather than a password be used at all :wink:

I have created my own auth system from scratch (no libraries).

cpR4VY9JZX
This uses some of the same principals, but I’m handling all authentication from CSRF to their session and cookies. Since I’m not using Bubble in this case, I can handle the tokens much easier via HTTP. This example doesn’t demonstrate the phone functionality (yet) but it’s implemented in the back-end.

2 Likes

Nice.

That looks really good!

Thanks also for the advice.

I actually worked a few more hours on this today and changed a lot of things based on all the advice.

Once I get it done I’ll show what I did to make it better.

If a user who does sign up with phone, are you later asking for email address to actually create the account?

1 Like

No, I create the account with their phone number.

My thinking is if the user didn’t want to sign up with an email then they don’t want to be bothered with emails.

1 Like

So are you inputting the phone as the email address of the user, so something like 5555555555@phone.com?

1 Like

Yes.

For the append I put @ my domain dot com

1 Like

This is bad practice.

You do not want to save their accounts as phone numbers.

Get their email initially, then let them link their phone number. Otherwise contact/communication will be limited as a phone number isn’t always the best for transactional messages, notifications, etc. Not to mention security.

You then want to make an API that can “link” (search and get their email) a phone number to that users email, then get back the email from the API and use that to sign in when they login with their phone. Very simple.

1 Like