[jira] [Updated] (AMBARI-21680) Prevent users from authenticating if they exceed a configured number of login failures
[ https://issues.apache.org/jira/browse/AMBARI-21680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Magyar updated AMBARI-21680: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Prevent users from authenticating if they exceed a configured number of login > failures > -- > > Key: AMBARI-21680 > URL: https://issues.apache.org/jira/browse/AMBARI-21680 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 3.0.0 >Reporter: Attila Magyar >Assignee: Attila Magyar > Fix For: 3.0.0 > > Attachments: AMBARI-21680.patch > > > Prevent users from authenticating if they exceed a configured number of login > failures, which is set as a configuration in the ambari.properties file - > authentication.max.failures. > After a users successfully authenticates, check the value of > org.apache.ambari.server.orm.entities.UserEntity#getConsecutiveFailures. > If it exceeds the value set in authentication.max.failures, then fail > authentication. Else allow authentication to proceed. > If failing authentication due to being "locked out", do not indicate this to > the user; however an Ambari server log message will be useful. > The normal "authentication failed" message should be returned as to not give > away any information about a user's authentication. > If a special "locked out" message is shown, then a hacker will be able to > attempt a brute force attack on a user's account since the returned error > message will be different if they eventually succeed in guessing the password. > To "unlock" the user, a user administrator (a user with the > AMBARI.MANAGE_USERS authorization) needs to reset the user's consecutive > failure count to 0. > By default the authentication.max.failures should be 10; however 0 should > indicate that no lockout is desired. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-21680) Prevent users from authenticating if they exceed a configured number of login failures
[ https://issues.apache.org/jira/browse/AMBARI-21680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Magyar updated AMBARI-21680: --- Status: Patch Available (was: Open) > Prevent users from authenticating if they exceed a configured number of login > failures > -- > > Key: AMBARI-21680 > URL: https://issues.apache.org/jira/browse/AMBARI-21680 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 3.0.0 >Reporter: Attila Magyar >Assignee: Attila Magyar > Fix For: 3.0.0 > > Attachments: AMBARI-21680.patch > > > Prevent users from authenticating if they exceed a configured number of login > failures, which is set as a configuration in the ambari.properties file - > authentication.max.failures. > After a users successfully authenticates, check the value of > org.apache.ambari.server.orm.entities.UserEntity#getConsecutiveFailures. > If it exceeds the value set in authentication.max.failures, then fail > authentication. Else allow authentication to proceed. > If failing authentication due to being "locked out", do not indicate this to > the user; however an Ambari server log message will be useful. > The normal "authentication failed" message should be returned as to not give > away any information about a user's authentication. > If a special "locked out" message is shown, then a hacker will be able to > attempt a brute force attack on a user's account since the returned error > message will be different if they eventually succeed in guessing the password. > To "unlock" the user, a user administrator (a user with the > AMBARI.MANAGE_USERS authorization) needs to reset the user's consecutive > failure count to 0. > By default the authentication.max.failures should be 10; however 0 should > indicate that no lockout is desired. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-21680) Prevent users from authenticating if they exceed a configured number of login failures
[ https://issues.apache.org/jira/browse/AMBARI-21680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Magyar updated AMBARI-21680: --- Attachment: AMBARI-21680.patch > Prevent users from authenticating if they exceed a configured number of login > failures > -- > > Key: AMBARI-21680 > URL: https://issues.apache.org/jira/browse/AMBARI-21680 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 3.0.0 >Reporter: Attila Magyar >Assignee: Attila Magyar > Fix For: 3.0.0 > > Attachments: AMBARI-21680.patch > > > Prevent users from authenticating if they exceed a configured number of login > failures, which is set as a configuration in the ambari.properties file - > authentication.max.failures. > After a users successfully authenticates, check the value of > org.apache.ambari.server.orm.entities.UserEntity#getConsecutiveFailures. > If it exceeds the value set in authentication.max.failures, then fail > authentication. Else allow authentication to proceed. > If failing authentication due to being "locked out", do not indicate this to > the user; however an Ambari server log message will be useful. > The normal "authentication failed" message should be returned as to not give > away any information about a user's authentication. > If a special "locked out" message is shown, then a hacker will be able to > attempt a brute force attack on a user's account since the returned error > message will be different if they eventually succeed in guessing the password. > To "unlock" the user, a user administrator (a user with the > AMBARI.MANAGE_USERS authorization) needs to reset the user's consecutive > failure count to 0. > By default the authentication.max.failures should be 10; however 0 should > indicate that no lockout is desired. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-21680) Prevent users from authenticating if they exceed a configured number of login failures
[ https://issues.apache.org/jira/browse/AMBARI-21680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Magyar updated AMBARI-21680: --- Description: Prevent users from authenticating if they exceed a configured number of login failures, which is set as a configuration in the ambari.properties file - authentication.max.failures. After a users successfully authenticates, check the value of org.apache.ambari.server.orm.entities.UserEntity#getConsecutiveFailures. If it exceeds the value set in authentication.max.failures, then fail authentication. Else allow authentication to proceed. If failing authentication due to being "locked out", do not indicate this to the user; however an Ambari server log message will be useful. The normal "authentication failed" message should be returned as to not give away any information about a user's authentication. If a special "locked out" message is shown, then a hacker will be able to attempt a brute force attack on a user's account since the returned error message will be different if they eventually succeed in guessing the password. To "unlock" the user, a user administrator (a user with the AMBARI.MANAGE_USERS authorization) needs to reset the user's consecutive failure count to 0. By default the authentication.max.failures should be 10; however 0 should indicate that no lockout is desired. was: Prevent users from authenticating if they exceed a configured number of login failures, which is set as a configuration in the ambari.properties file - authentication.max.failures. After a users successfully authenticates, check the value of org.apache.ambari.server.orm.entities.UserEntity#getConsecutiveFailures. If it exceeds the value set in authentication.max.failures, then fail authentication. Else allow authentication to proceed. If failing authentication due to being "locked out", do not indicate this to the user; however an Ambari server log message will be useful. The normal "authentication failed" message should be returned as to not give away any information about a user's authentication. If a special "locked out" message is shown, then a hacker will be able to attempt a brute force attack on a user's account since the returned error message will be different if they eventually succeed in guessing the password. To "unlock" the user, a user administrator (a user with the AMBARI.MANAGE_USERS authorization) needs to reset the user's consecutive failure count to 0. By default the authentication.max.failures should be 10; however 0 should indicate that no lockout is desired. > Prevent users from authenticating if they exceed a configured number of login > failures > -- > > Key: AMBARI-21680 > URL: https://issues.apache.org/jira/browse/AMBARI-21680 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 3.0.0 >Reporter: Attila Magyar >Assignee: Attila Magyar > Fix For: 3.0.0 > > > Prevent users from authenticating if they exceed a configured number of login > failures, which is set as a configuration in the ambari.properties file - > authentication.max.failures. > After a users successfully authenticates, check the value of > org.apache.ambari.server.orm.entities.UserEntity#getConsecutiveFailures. > If it exceeds the value set in authentication.max.failures, then fail > authentication. Else allow authentication to proceed. > If failing authentication due to being "locked out", do not indicate this to > the user; however an Ambari server log message will be useful. > The normal "authentication failed" message should be returned as to not give > away any information about a user's authentication. > If a special "locked out" message is shown, then a hacker will be able to > attempt a brute force attack on a user's account since the returned error > message will be different if they eventually succeed in guessing the password. > To "unlock" the user, a user administrator (a user with the > AMBARI.MANAGE_USERS authorization) needs to reset the user's consecutive > failure count to 0. > By default the authentication.max.failures should be 10; however 0 should > indicate that no lockout is desired. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
