John, You tend to 'crap' on the product line on a regular basis...and I don't typically respond, because you are usually 'correct'...if a bit mean spirited about most of the comments you make...but on this one, I can't agree.
While it might only take 10 min's with a single if statement to check to see if the disabled flag is set...there is WAY more than that to look at in this situation. Lets walk through a scenario: john.doe is a user in the system, has a fixed license, and various permissions to various objects in the system, and is disabled. so...what does Disabled mean...does it mean that the user cannot connect in any way? What if the system allows guest users, even though this user is disabled, should they allow the user 'in', but as a guest? There was a change made a few years back because of security concerns...you used to get a different error message when you provided an incorrect password than you would if you provided an incorrect user, this gave a clue to the person logging on what they did wrong, but it also provided a clue to a hacker as to if they have a good user account, but just a bad password...so it was generalized to protect the integrity of the system. In the case of Disabled, what sort of message do you give? Do you only specify that it's disabled if you provide a valid account name AND password, or do you say the account is disabled before checking a password. What if the system is set to AREA, and the password is blank, thus allowing authentication externally...but the disabled flag is set...do you let them in or stop them. I know what I would answer to some of these questions...but they are all questions that must be asked and considered and answered with proper thought. I'm not saying that these questions shouldn't be discussed, answered, and a strategy put in place regarding the Disabled user...but it's NOT as easy as a 10 minute fix as you suggest. On Thu, Jan 30, 2014 at 2:15 PM, John Baker <[email protected]>wrote: > Fred: Sadly, setting a predictable password isn't going to stop a slow > 'drip drip' process enumerating passwords. > > John: The core problem, as is the case with much of AR System, is an > unwillingness to tackle design changes in the correct place. You are > correct that security should happen in the server, hence it should check > the disabled user radio. How much effort is that - about ten minutes > with an if statement? > > I firmly believe in getting the core product right. I think I'm in a > minority. :) > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
