I am making an app, and in that app, users login and I am storing their information; however, I have noticed that I don't have a users' password information after they register. Is it a good idea to store users' password when they register through Firebase? And is there a point where I will need their passwords? I want to make sure before I proceed further. Thanks!
You do not do that.
Use the (awesome, amazing) Firebase authentication system.
Click right here:
on the left, to see all the users - click "Authentication".
You never see / you cannot see their passwords.
You don't handle or touch the passwords at all.
In the Android or iOS app, you get the userid - and that's it.
The answer by #PeterHaddad shows perfectly how to do that.
That's the first and most basic step in any Firebase ios/droid app.
In your data you'll have a "table" called probably "userData/" and that's where you keep all data about the user. (For example, you may store their address, real name, shoe size .. whatever is relevant in your app.)
Note - FBase is so amazing, your users can also connect with other methods (phone, etc). For your reference in the future, that is explained here
You don't need to store the password in the firebase database, after you authenticate the user using createUserWithEmailAndPassword the email and other info will be stored in the authentication console. So you do not need the password in the database, all you need is the userid to connect auth with database.
FirebaseUser user=FirebaseAuth.getInstance().getCurrentUser();
String useruid=user.getUid();
Related
My firebase database looks like below:
Suppose I have 50 users and I want to give access to node code-1 to user 1-20, code-2 to user 21-40 and code-3 to user 41-50. I have some problem and I don't want to use firebase authentication. Is there any way to do so? like sending data from user to firebase and then complete checking in Realtime database rules section and then grant permission.
Two options come to mind:
Security through obscurity: Rename code-1 to something unguessable like c17357345db9 and rename code-2 to 64af7b679319. Then share a link to an app that gives access to c17357345db9 to users 1-20, then share a different link for 64af7b679319 to users 21-40.
Create an API Server: Don't allow direct access to the RTDB but instead create a Cloud Function that acts as a REST API to retrieve the data based on the user's ID.
Neither are optimal and user 3 could easily share access with user 30 if they wanted to.
I am creating an application that would allow users to access data on their phones. Examples would be progress scores/test results.
I can upload the data to Firebase with an email address as the user link.
Is there a way that I can link this already loaded data to a user (with the same email address) once they have registered? Ideally using the email address in a rule to search up that data and use that reference point in the app.
Ideally I would like to pre-upload the users in bulk, but I know that Firebase only allows one user to be added at a time.
Any help would be appreciated.
After a user sign in to the app through the Firebase auth you can get its email through this call:
FirebaseAuth.getInstance().getCurrentUser().getEmail()
If you want to import data into your database, you should first make a json out of your data (list of users by email) and then use Firebase-Import to put it in your datastore.
It appears that when someone authenticates via oAuth, Firebase creates a uid that looks something like google:111413554342829501512, for example.
In Firebase rules, you can do (read and/or write):
".read": "root.child('users').child(auth.uid).child('isAdmin').val() == true"
Is it assumed that I can't read the message by sniffing the network because of the use of HTTPS? Is this how it works - the UID is a shared key used by Firebase rules?
I see that UID in firebase:session::ack in Local Storage in my browser once authenticated.
Knowing someones user id is not a security risk.
For example, I know that your Stack Overflow user id is 4797603. That fact alone allows me to potentially find you on Stack Overflow.
But it does not in any way allow me to pretend that I am Ron Royston. To do the latter I'd need to know the username and password (and any other factor) that you use to sign-in.
The same applies to Firebase. If you know that my uid in some Firebase-backed application is google:105913491982570113897, you cannot suddenly pretend to be me. The Firebase servers verify that the auth.uid value is based on the actual credentials of that user. The only way to do is by signing in as me, which in this case requires you to know my Google credentials.
I advise to use custom ID along side with UID. When your app grows, you do not want to share the UID or pass it around. Also when setting firebase-rules, you'll be referring to UID, which should be kept private.
generate a random string for the ID.
And for sensitive user data, set a rule in firestore, to only allow reading of the document if request.auth.uid == user.uid. This will prevent unwanted access. Read up a bit more on firestore rules, might be relevant for your use case.
I'm creating an android app which requires a login process. My issue is with implementing a "remember me" function in the app. There are several questions surrounding this issue already on the internet, but I was wondering if there is an easier way than creating public keys for the app or using OAuth (disclaimer: novice developer).
I read the existing questions like How do I implement a 'Remember me' function in an Android Activity? and Security: How should I store ("Remember") a user's username and password for future use? but they suggest two methods of password storage: plaintext in SharedPreferences, or hashed in SharedPreferences. However, the answers go on to say that these can be compromised if someone has access to the phone.
As a preliminary question, I would ask whether it is necessary to maintain security once someone has root access to the device/the hashed password, considering that cracking the password may give the intruder access to other accounts the user has made. If so, would it be beneficial to implement a system which performs this function but without ever storing the user's password (plaintext or hashed) on the phone.
I was thinking of a method which works using three steps:
When a user successfully logs in AND has checked the "remember me" checkbox, store their username in a SharedPreferences file.
Store a boolean value in the database indicating whether the user has checked the "remember me" box.
When the app starts in future, it automatically checks the SharedPreferences file for a username. If a username is found, and the database value for that username is true, the user is logged into the app under that user name.
This way, the user's password is never stored on the app (either in cleartext or in hashed form). Would this be a secure way of implementing the "remember me" function, or should I use another method?
Apologies if this question is not specific enough/too open-ended.
As you do not store password in phone I think it's a secured way of implementing a "Remember Me" function. But, In your 3rd step you haven't mentioned how you will get the username to compare with the SharedPreferences. If users have to provide the username again it won't be a good method.
I have a simple RESTful backend and I am using HTTP Basic over HTTPS for authentication. It works fine, but I am looking for a appropriate solution to store the credentials (username + password).
There are a lot of examples out there and the majority suggest to use the Account Manager to store passwords. AFAIK the account manager stores only OAUTH (and similar) accounts and automatically generates tokens etc. But how can I use it to store and fetch the original passwords? Is it even possible?
Others suggest to store it as a hashed value, but this doesn't make sense to me (At the end of the day I will need to have access to the original string).
Sorry for another How to use HTTP basic and android question, but I was not able to find a suitable answer so far and to store the data within the local sqlite db as plaintext doesn't seem to be appropriate.
I have a few thoughts concerning your project/style of usrmanagement.
Why do you want to save the password on the device?
Why don't you work with auth tokens
Why not workig with the good old sharedPreferences.
I would suggest to do it like this.
At first register(no password and username are neccessary, it creates a user "Guest123") or login to the server with a password (hashed by the device, getting from a normal edittext from the user).
Then check for correctness on the server, if valid, send back an auth token and a time to live for that token.
Store this in the sharedpreferences.
Send the token with every request you make to the server, if this token is not valid (because time is over, logged in on another device...), tell the user.
There are couple of tweaks which could be done here, but for the beginning it shoul help ou on your project.
Of course you can use the Account Manager to store password as well. This is the method:
addAccountExplicitly (Account account, String password, Bundle userdata)
and you can get the password using this method:
getPassword(Account account)