How do I make that Firebase will logout from all accounts when the user is change its Password.
So if user have 2 devices that are connected to the same account, and one device change the password of the account, the other device will disconnect. The idea behind it is that if user's account is hacked, they can change their password and disconnected the hacker from their account.
You have to logout and login regularly to check if the credentials save on the device are still valid. Depending on your security requirements you have to decide how often you do this. The most restrictive way would be before every Firebase call, the least restrictive would be when your app becomes active. I would:
introduce a last password check Date entry in UserDefaults
introduce a timeoutconstant (5 minutes)
save Date() when logging in
write a wrapper around calls, that compares the time interval in between now and last password check with timeout
if timeinterval > timeout, re-login
Related
We have created an Identity server 4 application for single sign-on in Asp.net core 2.0. We use the Microsft Identity framework for login and account related pages.
The client applications are created using .net FW 4.7.1 in MVC 5 which are then connect to identity server for single sign-on purposes (used Identity server 3 in client application).
We have a requirement wherein allow users to log in to the application only from a single device at a time. To achieve this, on user login, we create a unique LoginSessionId and store it in DB. On logout, we just make this session-id null.
If someone else tries to login with the same user on another device, we just check if the LoginSessionId has value. If yes, then we give a message informing the user that he's already logged in on another device and if he wants to kill the other session. If he says yes, we let him login and reset the LoginSessionId with a new one. As for the first device login, we have a check-in place to log out that user if his current LoginSessionId does not match the one in DB, so he gets logged out.
We have also set the AccessTokenLifetime and IdentityTokenLifetime of the identity server-client application to 24 hours. Here is the problem we're facing:
When the 24 hours are up after user login, the user gets logged out since the Token must have expired. But the LoginSessionId mentioned earlier is not reset. Thus when a user tries to log back in, we end up showing the message of another user logged in, which is not really the case. Question is,
Is there is any way to raise the token expiry event so that we can clear the LoginSessionId there?
Is there any common place where we can identify the various reasons due to which user gets logged out. Like was it due to token expiry, or because he was idle for a long time (sliding expiry I think), or if he clicked logout himself etc.
What is the max value that we can set for AccessTokenLifetime and IdentityTokenLifetime.
One needs to implement IEventService and IEventSink in Identity Server 4 to get those evnts.
for more details, you can refer to this link.
link
I'm using firebase authentication for my app and I have the users sign up, login, and log out all set up and going. However, I'm a little confused on how to manage the state of the users login status. Currently, if a user is logged into the app, but doesn't use the app for an extended period of time, firebase doesn't recognize them as logged in. I'm looking at the documentation and the approach is a bit unclear.
Should I be storing a FIRAuthCredential every time the user logs in, and then call reauthenticateWithCredential using that credential?
Firebase Auth only requires recent sign-in for sensitive operations like: deleting a user, changing a user's email or password. These are for obvious reasons. You want to make sure it is the same user before making such sensitive changes. Otherwise, the user is considered signed in indefinitely by the Firebase Auth backend (your assumption that "firebase doesn't recognize them as logged in" is not correct). Of course, a developer may also require re-auth before other operations like updating credit card, shipping address, etc. A developer would check the auth_time on the Firebase ID token. Only in such cases would you re-auth. You should never store credentials such as password on the client to avoid prompting the user to reauthenticate. It is needed to protect the user's account.
yes I think that is going to be right approach or second approach you can try is like when a user press login button instead of directly calling Authenticate User put a check in which last login timestamp value will be stored when user login compare timestamp value and then perform selected operation as you want . NOTE - you will be required to check weather user exist or not , but I think first approach will be better as if you had noticed in many Social apps like kik it ask for reauthentication after a long period of time but first it authenticate user instead of displaying home screen it take to reAuthenticate screen
I cant find any help around on this topic because I am being told how to implement it rather than how it actually works.
All I know is two-factor authentication is authenticating users through an email and a phone number.
Here are my set of questions :
Does it authenticate users by verifying their email and phone number at the time of registration?
Does it authenticate users by verifying their email and phone number on every login?
Why is it that every user can set two-factor authentication enabled or disabled for their account? Isn't this an admin thing which should not be decided by the user?
I'll see if I can help clarify for you.
It works as an extra level of security. Traditionally you would have a username/email and password to get into a site. If the password is compromised then so is the account. Adding a phone number to your account will mean that only someone with access to that phone can get past the extra level of security and access your data.
When the user logs in with another 'step' is added before they get through. A token (usually a number with a short expiry - i.e. seconds) is tied to the user logging in and sent to their phone. They fill in the form and submit. The device the user is logging in with (laptop/phone/desktop browser) can then be tied to their account (see point 2 below).
This can be the case but if you take Google as an example you can select to 'Trust' the device logging in for 30 days. This ties the device to a trusted list (perhaps stored in a database for instance) for a set amount of time before asking at the point of login again.
Common practice is that it is the user's choice as to whether they have this extra level of security. They may not have access to a phone...what happens then? They may like the convenience of just using a username/email and strong password....it doesn't mean to say you can't force it by design in your system though.
OK...so I have a swift app that connects to a PHP backend. The user logs in, it stores a session on the server and sets an encrypted cookie in the cookieStorage on the app (I also store that cookie in keychain since cookieStorage can be volatile from what I'm told). I also store the username and password in keychain as well.
The session on the server expires after a time of non-use (let's say 30 days), but if the user comes back, the session renews itself if it's under 30 days old. So for example...lets say I don't come back for 15 days...my session is now reset to 1 day old and again has 30 days to expiration...however, if I come back on day 31, I have to re-login on the web app.
There are several viewcontrollers in this app that require the user to be logged in (a couple are uiwebviews that use the cookie to access the data on the server...those aren't a problem as they handle the sessions like a champ by default). The native views (tableview, etc) that require the user be logged in however are a different story.
Currently, on login, I set a switch in NSUserDefaults that the user is logged in...in didFinishLaunchingWithOptions, I just check to make sure the user is logged in...if they are logged in, we move them into the "private" area of the app, if they aren't logged in, we move them to the login screen (or signup screen).
All of this is fine and good...but with the sessions expiring on the server, I was wondering what is an appropriate way of handling this in an iOS app? I want them to stay logged in until they choose otherwise, but if the app stays closed for 31 days, the session on the server will no longer be valid. I was thinking that I could set a date in UserDefaults (last time app was opened) or something like that, and if they haven't opened the app in over 30 days, then I could just use the username and password stored in keychain to re-log them into the PHP backend and refresh their session and reset the stored login date (if the password is no longer valid, I would of course redirect to login view).
Is there a more appropriate way to handle this in an iOS app or does that sound like a valid approach? Should the date/session check be in didFinishLaunchingWithOptions and also in applicationDidBecomeActive ?
First, don't store anything that has to do with the login state in the userDefaults it's not secure.
Second, since you are storing the username and password in the keychain, why don't you just check the keychain and log the user in every time they open the app. This will give the user a persistent login until they log out then you can clear the keychain. Also this will give you another analytic point you can store in your database so you know every time the user opens your app.
Is there a reason you want to have a 30 day expiration?
I am unable to revoke application access by a user via either a password reset or by explicitly clearing app keys in user management. The latter method gives a reply indicating that access has been revoked, but when the user hits the tool, they are not re-prompted to approve access to their information.
There are number of possibilities here:
It's possible that there is latency between the declared revocation of keys and the cleanup task that goes through the database and actually cleans them up; I believe that at one point, such a latency existed, was identified, and fixed through service packs and subsequent releases. Accordingly, you may address this issue by ensuring that your back-end service is up-to-date with its available service packs.
It's possible that what's being revoked is the keys, and the necessity to authenticate to rebuild keys, but not the confirmation step that would appear to the user asking for access permission (assuming the user once authenticated, and checked the "don't prompt me to ask for permission again") dialog.
Can you confirm if the request for user tokens by the client application actually does get back tokens? Or is it just that the authentication step happens with no notice of client confirmation to access?
Note that the re-authentication might appear to happen silently; if the client application's request for user tokens happens through a user's browser context where the back-end service can determine that the user is already logged in to the LMS, then the request for tokens could succeed automatically:
The user is assumed to have already authenticated in order to have an active web session, so there's no need to re-gather a username/password (or whatever user auth step the LMS uses) to re-confirm identity.
The user may already have confirmed access for the application and dismissed the confirmation step with "don't ask me again". If the user has confirmed access with "don't ask me again" this choice will get remembered, even if the user tokens get expired due to password change or access revocation by an admin.
If you explicitly log a user out of their LMS session, and then test the client app, this should indicate to you visibly whether the re-authentication step is actually taking place (the user's browser will then get directed to the login process for the back-end service).
Note that, although a user password change or access revocation by an admin can remove the recorded user Id/Key pair associated with an application, it does not remove the record of the confirmation form having been dismissed with "don't ask again". Currently our system does not expose a way to reset that confirmation state.
If after considering these points you feel you still have an issue, I would encourage you to open a support incident through your organization's approved support contact, or your account or partner manager. Desire2Learn takes security related reports quite seriously, and if you've uncovered an issue that hasn't yet been addressed, I would encourage you to report it as a defect.