Using AD FS 3.0, when a user enters their username or password incorrectly they get a message
'Incorrect user ID or password. Type the correct user ID and password, and try again.'
If the user locks their account with too many failed attempts, they continue to get the exact same message, which is misleading.
Is it possible to inform the user that their account has been locked?
Related
I am using ADFS3.0. Suppose I enter incorrect credentials into ADFS sign-in page it returns error message "The user name or password is incorrect".
If due to some reason I try to log-in to ADFS 3.0 with a locked out account still it returns same message which is I think is not correct.
At this point I want to show a custom message say "Account has been locked-out" in place of "The user name or password is incorrect".
Could anybody help me on it ?
You can customize those messages. (You can explain that the account could be blocked and to try later) / contact IT for assistance, etc.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn280950(v=ws.11)#custom-error-messages
The reason it returns the same message is because of security.
Different messages could give hints as to how best to mount an attack.
To know that an account is locked out, ADFS would have to do an LDAP query to AD and that type of functionality is not available.
I am facing an issue with Keycloak:
When user clicks on Forget password button, he is asked to enter basic details. Once details are entered, the user receives a mail with link to change his password. User Changes his password, and is redirected to Login page of the application.
Users account gets locked. Admin uses application to unlock the account. User gets email, clicks on link, and generates new password. User now sees a message : Your account is successfully updated.
What I want to do is that the second flow should work in same way as the first one. i.e when user has given new password, he'd be redirected to login page.
Can someone guide me about how to proceed with this?
Difference I've noticed in two flows is the URL that I receive in both of them is different.
First flow, I get this in mail: http://[keycloak-host]/auth/realms/[realm]/login-actions/reset-credentials?code=[code]
Second flow, I get this URL: http://[keycloak-host]/auth/realms/[realm]/login-actions/execute-actions?key=[key]
I have used facebook api to fetch details of group members.
using api i can fetch user first name, last name but not able to fetch email address.
this is code
$member_profile = $facebook->api('/group_id/members?fields=id,first_name,last_name,email,gender,birthday');
You either did not authorize with the email permission or the email is not confirmed in the Facebook account - it´s also possible that the user did not login with his email, afaik you can login with a phone number too. In general, you can never be 100% sure to get an email from the user.
Debug your Access Token and make sure the email permission shows up: https://developers.facebook.com/tools/debug/
I've got a decent set of existing users on my website who login via their emailaddress as their username.
I'm setting up Facebook OAuth mechanism to allow new users to sign up more conveniently, but I'm not sure how to handle the scenario when a user who already has an email address registered with our system and now tries to login via Facebook.
Should I consider him the same user?
Should I treat him like a new user?
The situation is more complicated by the fact that I dont validate their email addresses (when they login directly into my system), so i cant assume they are the same user.
How do others resolve this conflict, or do other folks simply treat this user connecting via FB as a new entity?
On your login screen, users can have a choice: you may put
new user: signup using facebook
since this is a totally new user account, then you just need to do your facebook connect + request for email permission, etc.
existing user: login by email
Once they do this, let them login using the old-fashioned way. Then once signed in, prompt them to connect this email address to their facebook account. So the flow is login via email then optional facebook connect.
To do this, I assume you've added a field on your database table for user_accounts, that is facebook_user_id or fb_id or user_id, etc. Then on facebook connect, get the logged-in-email, UPDATE table SET fb_id = xxx WHERE email = xx
I've pondered the same issue. I think we'll go with the verified email (Facebook Connect) getting attached to and logged into the existing account with the same email.
Before we connect and log them in we'll explain that the account exist and ask for their password (they signed up using email and password, so they should know it) to ensure it's the right person.
If you support multiple external authentications (Google OAuth, Facebook etc) then you may not have a password, and in that case it gets slightly trickier.
If you do log them in to the existing account without asking for a password, make sure you clear existing sessions to avoid 'anticipation attacks', where an attacker anticipates that the target signs up, creates an account and keep the session after they've signed up and attached to the attackers existing account.
Many sites implement different methods and I am having a hard time deciding on which method would work best for my site.
My user profiles contain the following data:
username
password (in hash/digest form)
email
I'd like the password reset method to be secure, user-friendly, and efficient.
You should add two fields, reset_code and reset_expiry
This is the process for a secure password reset functionality.
User selects "Forgot password".
User prompted for email/username.
If valid, generates a GUID, and stores it in reset_code and also stores Now()+24 hours in reset_expiry in the database against that particular user.
Then it sends an email to the email address with a link to confirm the password reset. This email would contain a link to your website with the user's username AND reset_code embedded. (This stops a malicious user resetting a third parties password just by knowing their email)
Once the user clicks on the link in the email, they will be directed to your website.
Your website will validate that: the username and reset_code matches, and the current time hasn't exceeded the reset_expiry time.
If all is okay, we can complete the password reset. This can be done by either:
a) Onscreen a new randomly generated password
b) A new randomly generated password via email
c) The ability to enter a password of his/her own choosing
You should not store the passwords of your users, not even in encrypted form. You should only store the hash/digest necessary for authentication. Then, you can't "recover" the password (because you don't know it), you can just reset it, and/or give the user a temporary one-time password that allows him to set a new password.
Update: if you are doing the above, the standard procedure is to have a "require-password-reset" form. The user enters his id (typically his email) and a "token" (eg, a random string) is generated, stored in some table with some expiration date, and sent to his email along with a link to the "password-reset" form. In this form the token is checked, the user is allowed to enter a new password, and instructed to attempt a new login.
Update 2: A small privacy issue might arise: What should we do if the user id (email, user name, or whatever) entered in the request form does not exist in our database? To output a message "User does not exist. Check the id and retry." may be ok, but in some cases it would cause a privacy problem: anyone can check if other someone is registered in your database! If you want to avoid that, you must output the same message ("a mail has been sent with instructions...") even if the user wasnt found (and hence a mail was not actually sent).
Similar privacy issues advise to just output the message "login incorrect : bad user or password" when the user tries to login unsuccessfully - don't disclose if it was an incorrect user or password.
I agree with Leonbloy. Storing the password leads to trouble like the Gawker incident from a few weeks ago (1.5 million userid/pwd combinations were discovered and published).
You should, however, have a "reset password" function that e-mails the new password to the original e-mail address used to open the account.
There should be no provision for changing the e-mail address during the password reset. If the user doesn't have access to the old e-mail account anymore, too bad. Abandon the account and start over.
And use a good Captcha on the reset screen.