I have the following scenario:
If a user has a temporary password, that is been set in the last 24 hours, the user is forced to change the password. If the password has been set more than 24 hours ago, then the user is not able to log in.
If a user has a password that has been set in the last 180 days, the user is able to log in. If the password has been set longer than 180 days ago, the user is forced to reset the password.
The two types of password look different, so I can compare the password by a regular expression to check if it is a temporary password or not.
The problem is that knowing that the password is temporary or not, I have to apply the 24 hour or 180 day expiration time of the policy. So how do I know when the password was last updated?
Initially, I have thought in using a custom attribute to store this value, but I thought that this should be recorded somewhere by default. It makes sense to me that Microsoft wanted to audit this on their side for compliance and security purposes. It also makes sense to me that this could probably be on Graph, but so far, I haven't found this filter exists.
Question is, does this filter exist or I need to go through the custom attribute route?
I tried to reproduce the same in my environment and got the results as below:
To know the when the password of the Azure AD B2C users was last updated, try the below query:
GET https://graph.microsoft.com/v1.0/users?$select=displayName,lastPasswordChangeDateTime
Make sure to consent User.Read.All permission to fetch the lastPasswordChangeDateTime.
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
The steps mentioned at Reset User Password seems a bit confusing to me.
For example, A user normally reset his password because he cannot remember existing one.
Now, the above link mentions that
The refresh token can be retrieved by calling user.token after logging in via Realm.Sync.User
But, as user does not know his current password, how can the app get the refresh token?
I seem to be missing something here, not sure what..
Would be nice if someone could explain the complete steps for password reset by user.
"Password reset" is a bit of a misnomer. The functionality in question is intended for a logged-in user to change their own password (for example, from a "Settings" or "Profile" screen), or for a user with administrative privileges to change an arbitrary user's password.
There is another common use case in which a user who is logged out and does not remember their password wishes to reset it. In many cases this process involves sending them an email with a link which, upon being visited, will allow them to specify a new password. The Realm Object Server doesn't support this sort of password reset out of the box; you may want to file an issue at its issue tracker to request it (since it seems quite important).
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.
I am currently worrying about a password recovery method for users of a web application.
One idea would be to use an E-Mail with a recovery url, only asking the user for his/her user name, but if he/she forgot that too, ask for e-mail address.
Another idea would be to use "secret questions" and then send the password to the user.
Do you know any other, possibly better, options for password recovery? Are there any downsides, besides user frustration, to have a "wrong password limit"?
EDIT:
Yesterday I was told that in some of the older versions, which are still updated and used by some customers, neither E-Mail addresses nor user names have to be unique.
So I'm totally stuck now. The only thing coming to my mind is using a secret question which the user can select after first login. But instead of sending an E-Mail opening the "new password dialog" directly.
Do you have any more ideas?
My opinons:
Assuming you require a user's email address to be unique among all registered users have the password recovery page ask for the user's email address. You can make it "username or email address" but I don't think that little tweak will help enough users to justify your additional backend processing.
For added security do not confirm or deny that the username or email address was found in your database.
An email with a reset password link should work fine. Use a hash (the longer the better; definitely 20 characters or more) so a hacker can't easily guess reset links. For added security specify a time limit after which the reset link will no longer function.
Once the user clicks the link and chooses a new password, do not automatically log them into their account; make them login from scratch. This will make sure they know their new password and will reduce the chances of a bug in your password recovery code letting hackers directly login to accounts.
Remind users to check their spam folder, and provide a window of time in which they can reasonably assume they should receive the reset link (so they know how long to wait before complaining to you).
Security questions are usually a bad idea. First off, users struggle to remember what their answer was. It's like adding something to a user's password but giving the world a hint to what that extra part could be. AND the answers will tend to be case insensitive and only alphabetic or alphanumeric.
Make sure you include a way for the user to contact you if the password recovery system isn't working for them. Be cautious, though, as this could be an avenue for a Social Engineering hack.
Password limits can be frustrating for users. Think long and hard about implementing this, how many attempts you'll allow, and the consequences of exceeding that limit. Most people have variations of a single password. Now, that's not smart from a security standpoint, but it happens. A reasonably acting user could very well try hooper2012, Hooper2012, hooper20121, Hooper20121 in under a minute.
Maybe you could, say, after five failed attempts make the user wait 60 seconds between any future attempts. Double that to 120 seconds after an additional five failed attempts. Continue doubling the wait period every five failed attempts. If you let that continue until, say, 50 consecutive failed attempts the minimum amount of time it'll take to exhaust those 50 attempts will be 1 day 18 hours and 35 minutes. I'd definitely recommend having something in your code to notify you of any accounts with more than 12 consecutive failed attempts in a day.
After 50 consecutive failed attempts temporarily deactivate the account, and require the user to contact your technical support. Again, be wary of social engineering.
Reset the wait period to 0 once the user provides the correct login credentials.