Hi, can someone really well versed in security tell me if this is feasible on Bubble:
I’m trying to build an entirely anonymous login, without any personally identifying information leaving clientside. My first question is, when you use md5/sha256 hashing functions, does that happen client side? If so, can we do the following:
Grab navigator info, using js or modernizr or some lib to that effect, viewport width, and any other device info available with js
hash the email/phone number salted with the device info
if sign up, store the token, create an account for someone else, etc etc.
If login, call the api to check for the existence of that token against all users (how performant would this be, when would it start to break?) - if the token is found, generate a magic login link for that user, and return the link
nav to that link using the go to an external page workflow/ or show that the device isn’t recognized
if the user is looking to log in on a new device, how would you go about that if you don’t have any PID? I am thinking something ilke they must have the old one open and have a “link accounts” section that while open allows them to generate a qr, which is is a new magic link, asks them to confirm their email/phone number on the new device, and which would then store that salted with new device info then hashed as a new device under the same account.
Would this work in theory? Where might there be trouble?
Generally speaking, unless you enjoy working on academic ideas or just like being different, I assume you have a reason why you are keeping all information client side, and I’m going to go out on a limb and assume that reason is compliance (HIPPA or the like).
If my presumptions are correct, then your proposed idea simply doesn’t work (unfort you don’t get compliance points for creativity or effort ).
If you aren’t concerned about compliance, be aware of the security issues you are creating by doing everything client-side (I mention a few points down).
It can, but can you hash without any identifier? (Idk but asking because then why would my hash of that into be different than yours.)
How would you call the API without an API key and without enabling this to be run without authorization?
How would you return the link?
You seem to be overlooking a common reason why users don’t have the old device open: because they don’t have it in their possession and functioning. In that case, did the user lose their account forever?
In simple terms, are you trying to obfuscate the database in bubble so it’s non human readable for PII? or just simply not connect the data saved to a real human?
Most importantly, is this a matter of compliance? because if it is you’re wasting your time… you’re not gonna get a BAA, can’t use device info etc etc.
I know. that’s my point → that’s making its way to back -end.
This would do both of those things. I am asking about a “magic link integration” without the actual magic link step, if I structure it in a way that it should securely auth without leaving the platform. There’s a reason why it’s not done this way - and I’m starting to think it’s a UX-security tradeoff, but I’m trying to figure out a way it can be done.
@duke.severn Brain’s overloaded with a big rollout that is about to ship but I’m missing how you can use an API without logging in and from client side.
And if you won’t answer my Q because my assumption is right, you will not outsmart HIPPA (plus Bubble does the favor of revealing your DB schema to all law firms looking for such layup violations), you will get sued and your approach won’t make it compliant - not to put on my lawyer hat but them’s the facts.
That was my question: is using the hashing function provided on bubble done client side? You said it can - if it is, and my understanding is correct, the device info to make the unique hash could stay client side, only the token would be sent to Bubble server. My understanding is that this is already how passwords work on Bubble (and elsewhere).
I am hoping my understanding of the bubble’s API architecture used with the API connector is correct: maybe you can confirm.
Then both the headers and the body (bubble’s api key, and the token you just generated from the “PII” and from the device info is encrypted in transit correct? And - you can use the API without logging in? What did you mean “without logging in”?
Then Bubble’s workflow api can return a response which would be the magic link you just created for the user in your API workflow. Using the API connector’s plugin “Action” type, you retrieve and it when it hits the client you can take “result of step” to retrieve the link and navigate there. I was quite certain that’s how it worked but you have me second-guessing myself - thanks for your help on this.
No, device biometric harvesting to confirm pw is already a thing. For example on fb you can log in with the correct user email and pw, but if your device is “too safe” (location is off/spoofed, if you’re blocking fingerprinting, etc.) you will get kicked with the “incorrect password message” even if it’s 100% the correct email and pw.
I’m looking into how to package that into a passwordless experience that works well but is safe.
I don’t know hashes well enough to know the answer to what you’re asking but will try to dig in later.
But the reason I keep asking what your goal was is because that makes all the difference. for a safe passwordless experience, why not just use the hash as the password (or something similar)? That way, you can send user names, email , phone etc to back-end and log users in seamlessly, and have the ability to reset password if user is using a new device by emailing / texting them and not have to deal with the admin of a guardian device.
).
