I created a password manager in flutter, which stores password encrypted passwords in an db. I access this db via the backend, which is written in python. As a user in the app, you are able to set a master password, which after each login is passed to the backend, to encrypt the data. I now want to add sign in with google functionality (firebase authentication), so that you don't need to type in your master password every time. Is it possible to receive something like a key or a token from firebase after each successful google-login which you can use instead of the master password?
I noticed already that there is this uid in the firebase user class (which i receive from FirebaseAuth.instance.signInWithCredencial(google_sign_in_credencial) in the google registration progress) which is unique for every user, but i dont think that this is secure enough to replace this sensitive master password. I also heard from JWT Authorization, but i am not sure, if it's the right thing for that.
Related
I want to replace the login to the app from username and password to fingerprint in flutter, so the user when have successful fingerprint he will see his information in the application (this information send from server).
How I can manage that I want some thing to make this fingerprint connected with this user to get correct data from server ?.
I use local_auth for fingerprint authentication but I have no idea to tell server this fingerprint is associated for this user.
I read some thing like this to handle this:
when application installed for first time ask the user to enter (username and password) then save them is shared preference. (this page will appear only once).
after that show screen that ask the user to login using fingerprint if it exist or ask him to create one if not exist.
each time the user run the application only fingerprint is required if authenticated then get data from server by sending userId saved in shared preference to get data.
is there is any way better this way ?
Fingerprint is a User biometric data located in a secure place in the User phone. You cannot access these binary data. To send user data to your server, you must prompt them to manually enter their info. You can then protect their privacy in your app by protecting the app usage by Fingerprint or any other method you want
Actually i want do it in this way when user sign up with fake email. user can't verify this email.So the email should automatically deleted from firebase authentication after fixed time.
There is nothing built into Firebase Authentication to auto-delete accounts like that. I'd also consider what you actually gain by such functionality, as the user can just recreate their Firebase Authentication account by calling the same API again.
You'll typically either want to:
disable their account, which prevents them from signing in/signing up with it. This can be done through the Firebase Admin SDK, by first getting a list of all users, and then disabling the relevant ones.
only grant them access to your back-end services if they've verified their email address (within a certain amount of time). How to do this depends on your backend services though.
I want to do the following
User signs up to IOS app and provides username and password
Make a server call and store password in server database
When user logs in in the future, retrieve that password and check against the password that the user entered.
How can I do this in the most secure way possible? I was thinking of encrypting the password when storing in the db. When the user logsin, use the same encryption algorithm and compare against the db encrypted password.
NEVER ever store user credentials in encrypted (reversible) form. Currently best known way for checking user credentials is slow salted hash
for what and why please read https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
However, don’t try to invent your own algorithm for repeated hashing.
Choose one of these three well-known ones: PBKDF2, bcrypt or scrypt.
As already commented you may outsource the user authentication to some reliable service (google, fb, aws cognito, ibm appid,...)
Have you tried looking into databases? I know that Firebase has an authentication component of their database for ios development, and you might want to try to look into it or other databases. Check out firebase at: https://firebase.google.com/
I have a Raspberry Pi and want to send data from it to my Firebase database.
To do this, I created an user account with email and password in my database and I store them on the Pi.
The problem/idea:
I take a measurement and want to send the data to my database using the specific user account.
I get a token for the credentials (email&password) in Bash or Python.
I use the token to send the data, e.g. using the REST API.
I do not want to store the admin/service account secret on the Pi.
How could I achieve this? I did not find any way to get the user token in Bash/Python without the account secret.
I don't understand the point of having access token in authentication. Below is a paragraph of explanation I took but I still confused. Since every api call still go to the db look for the token, what's the different check for the username and password for every http request?
Instead of forcing clients to send username and password with every
request you can have a "get_access_token" function in your RESTful
service that takes the username and password and responds with a
token, which is some sort of cryptographic hash that is unique and has
some expiration date associated with it. These tokens are stored in
the database with each user. Then the client sends the access token in
subsequent requests. The access token will then be validated against
the database instead of the username and password.
Using the access token limits the amount of time the username and password are being used and sent across the wire.
How many times do you want your username and password, SSN, or other sensitive data do you want being stored and transmitted? Do you want that on every request?
First of all, access tokens are typically validated by checking the digital signature, which does not require the receiving service to talk to the issuing server. The client gets an access token once and uses it until it expires.
But even if the token had to be checked against the database on every call (when using reference tokens for example), tokens are still preferred over sending username and password on each call. They remove the need for the client to keep the password in memory (or elsewhere), where it can easily be stolen.
(1) Access token is less sensitive than your password. Access tokens typically expire after a short time (this is a requirement in the Oauth threat model), whereas passwords tends to be long term. If somebody grabs your access token, there is limited damage they can do. If they grab your password, then there is a lot of damage that they can do. Especially if you use the same or related passwords on multiple sites.
(2) If the server implemented password verification securely, then they should be using a slow function like PBKDF2, bcrypt, or scrypt to validate your passwords. These functions are designed to be slow so that if somebody gets access to the database, they will not be able to reverse many passwords: see Our password hashing has no clothes. Given that password checking is supposed to be slow, we don't want to be doing it often! Validation of access tokens is much quicker however.
(3) The system that grants you access to a resource ("resource provider") might not be the same as the system that checks your identity ("identity provider"). For example, many websites including StackOverflow allow you go login with your gmail account. In this case, Google is the identity provider and StackOverflow is the resource provider. Would you really want to provide your gmail password to StackOverflow? I hope not.