I came across this post - Structuring user data by email address or by user ID. I am using a custom SQL backend where I use email Id to identify a user. As explained in this document - https://firebase.google.com/docs/auth/admin/verify-id-tokens I am verifying the Id token and extracting the email id, INSTEAD of UID. I don't see any real need for using the UID to identify a user. Any thoughts on why to use UID in my case?
Email addresses change over the lifetime of a user. Think of email addresses you had and don't use anymore, such as your email address in college, or the one with parts in it that would come across rather immature when you'd mail a potential employer from it.
If you think none of these apply to your use-case, you can of course use the email address as a unique identifier for the user. But in practice I've often seen developers revert from that over time.
Emails are changable in firebase authentication, a user can change their email id but never their user id, so it's better to use the user id, so no matter what the user changes they can always stay linked to their data.
Related
I have a list of people with all their personal information (name, first name, date of birth, email, etc.). I created an account for each of these people in my database. I'm using Firebase.
Since I already have all my user's info, I don't want them to type it again when signing up to my website.
So I created a system using a custom token for authentication. I send them as a parameter of an URL to every one of my users.
When the user clicks on the link for the first time: he gets redirected to the signup page with all the fields pre-filled (name, date of birth, email, etc) except for the password. He types the password he wants and gets signed up.
When the user clicks on the link every other time: he gets redirected to the login page. A simple email + password interface with the email field already pre-filled. He types his password and gets logged in.
This is working great BUT I'm wondering: is this bad practice to do so?
Is this insecure to let anyone who gets the email create an account in the name of my user? Should I assume that someone, other than my user, may have total access to my user email account? Should I be prepared for this eventuality?
Since I already have all my user's info, I don't want them to type it again when signing up to my website.
If you already have the user's information, and you are allowed to process it, then it's a good practice to not let the user do something that it's already done.
is this bad practice to do so?
Not at all. That seems to me like a practice that is present almost everywhere. If you want to edit the profile data, you always have the existing data already pre-filled. The user has just to verify it or change it if needed.
Is this insecure to let anyone who gets the email create an account in the name of my user?
That sounds not like the best option if someone else can use that URL and create an account on behalf of the user. Most likely you should consider letting the user create the account only if it can validate the data through an SMS, or any other service that is specific to that user in particular.
Should I assume that someone, other than my user, may have total access to my user email account? Should I be prepared for this eventuality?
Yes indeed. You should always prepare for that. Never trust the users. There's not a perfect world out there.
I use createUserWithEmailAndPassword(string, string) in flutter, but I noticed if the user used a fake email address, like making us some random Gmail or yahoo account that doesn't exist, the user would still be registered, is there a solution to this
Or some logic that checks if the email account is real, then I can use the result in an if else statement to create the account
If you are looking for a solution that doesn't involve blocking the user experience, you'll be disappointed. We could come up with a new solution for checking whether an email exists or not, but this doesn't guarantee you anything. The user may use an existing email that doesn't belong to him/her.
The best you can do is send a verification email to your user, which is supported by Firebase. However, the user experience is going to be blocked until the user verifies the email.
Update
Check here how to send the user the verification email and here how to see if the email has been verified.
Is it safe to share a user's ID that Firebase creates when a new user is created? I'd like to use it as an easy way to find other people on my platform.
I don't see why it should not be safe, so if it is. Please enlighten me :)
I am not too familiar with your system or how Nintendo does this (not really a gamer) but you can build something like this:
You can display the list of users (using uid, displayName and photoURL which can be obtained using the Admin SDK or by a list you maintain in the Firebase Database, Firestore, etc) to an authenticated user.
Let's say that user wants to add a connection or friend, you can get that user's ID token, the friend's uid and then add that user's uid to that authenticated user's pending connection list after you verify their ID token.
On the other end, you want the other user to accept the connection request (assuming this how your people finder feature works in your app). You would show the list of pending requests. When the user accepts the request, they would send their ID token and once that's verified, you can consider the connection completed.
To summarize, you still need an ID token to confirm the user sending the request and the one confirming it. Otherwise, if you just solely rely on uids, any user can get the uid of other users and try to add them to each other's friends list, etc.
Hopefully this points you in the right direction.
my friend and I were thinking of a Web idea and ran into an issue:
We can't allow the email address to be sitting in a database with its associated data, in the case of a hacker obtaining the database. We'd like to ensure the email address and its associated data can never be linked, but then on the other hand we also need to keep them linked somehow so we can send users email notifications E.T.C
Can anyone think or know of a way around this? (.NET, Umbraco)
Thanks!
Have 2 databases, one with users + data + user id, another with user id + email. Secure them both, if one gets discovered, the other one might not be.
In any case you are asking us to prove falsity. ^^
I can't think of a way to link user data with emails without actually linking user data with emails. However, it would be possible to not have the email address stored and linked in a database if you could live with only having their email address when the user is logged in.
You could require users to log in using their email address and password as many sites do, but you could store a one way hash of the email address (such as sha1(email+password) ) rather than the address itself. When the user logs in successfully, you can store their email address in their session without ever having to get it from the database. You could then send them emails until you destroy their session. This would prevent an attacker from connecting their data to their email without brute forcing the hashes or grabbing the session information from memory or user cookies depending on how you store it.
Unfortunately, this wouldn't allow you to send notification emails.
I am working on a project where I need to design the logic for a Verified user. This means that a user (based on negative feedback) is not able to delete their account and start a new account under a different email id.
Currently, to create an account, a user enters :
desired userID,
email address (yahoo, gmail etc),
Address,
City,
State,
Zip,
Phone
How can I ensure if a user does close their account and start a new account, that the application can track this?
One option suggested was to send a secure code to the user's cell phone;
Unless they use the same details you can't. The only thing you can reliably compare is the e-mail address and everyone has several of these already and it's easy to get more.
You will have to be careful if you only allow one sign up per address as this will prevent members of the same family signing up to your service.
There's no reliable way of doing this, unfortunatelly. Unless, of course, you'd ask user for an SSN number and then validate it somehow.
Given that the combination of data you collect is open ended and their are virtually infinite possibilities for each value, I'm not sure you can prevent this, unless each user is tied to another device, such as a hardware key token or some other non user provided hardware based out of band authentication.