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:
There is a password field that is hidden:
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.
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?
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.
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
I have created my own auth system from scratch (no libraries).
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.
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.