Users tend not to know the exact credentials for ServerXY, but rather the possibilities; should we configure for this in software?
Providing configuration options for what a user actually knows versus what would be proper and correct might be faster for the user, and allow for incremental addition of resources, but may offend users or appear confusing.
Long ago, a toll-free telephone number was connected to a “Hunt Group” or “Hunt Pool”: the incoming call would try to connect on the first number, but if busy, it would move onto the next, then the next, eventually ringing the phone of the first non busy extension. Basically, on failure of “is that line non-busy?”, it would try the next extension, recording the first success, and trying later to connect that call using the details of the success.
Some services make us change our passwords: special “you’re a nuisance” prize to those who make us change our passwords every 30 days to one we haven’t used in the last 8 passwords! In general, we end up with some services using one password, some using another, and when we try to connect to those services, we tend to try the most recent password, then the previous, then the previous, hoping that we have a match before the service says “too many tries; account is deactivated, call our service number between the hours of 10:00am and 2:00pm and wait 45 minutes in a call-in queue to unblock your access”. We basically try a list of possibilities, and hope we have a hit before the system “clamps down” on our attempts.
As an aside, if you know your buddy’s (or ex-girlfriend’s) bank ID, three password failures tends to block their web-banking. Try that with your branch manager.
This same “hunt for a match before the system clamps” is often done when configuring access for dozens of servers: some servers have the new 2011Q4 password, some have the new 2012Q1 password, and some are those old systems with Mike’s password based on a cartoon character that no one remembers to change. The behaviour is the same:
- “all of our servers use username=scott, password=tiger”
- (when some fail) “ok, try username=support, password=Rup3rt”
- (all but a handful work) “ok, try username=admin, password=admin, yeah I know it’s a bad habit”
Look at how we typically ask for the authentication for a list of servers: we ask for 200 lines of a table with individual user/pass pairs for each, when we know that the user will fill in all to be the same “except for those ones over there, they’re old” and when there are failures, a few one-off changes are made.
Additionally, when authentication is not managed by TACACS or OpenID or LDAP, the group that sets/changes passwords may differ from the group that uses them. Failing a login, we just say “Oh, Compliance Group has changed those passwords finally” and we use the new ones.
Why do we even ask for the list of passwords? If the user is just going to play this “try this one, and if it fails, try that one next” game, and the login system never “clamps” on us, then why not just ask for the list of possible user/pass pairs? We’d reduce the keystrokes necessary to enter all the services, we’d have a fallback path if our access suddenly stops (i.e. when “Compliance Group” updates a password and doesn’t tell our users), we could more simply add new services (such as organic growth, failover, or in response to Discovery), and we’d more accurately approximate what the user is doing.
Simple.
It’s strange, and users don’t like to tell us they don’t know.
Two things I learned in Asia: don’t back people into a corner, and don’t make then feel like they’re looking stupid. Chinese are faced with a higher degree of competition in the workplace so are the ones nice enough to correct me on this: all cultures are sensitive to this. No one likes to look stupid, and whether they feel like they’re looking stupid is up to their own perception. If we do something that says “you really don’t know your passwords”, they may be impacted and push-back; by continuing to play this game, we avoid this issue. Perhaps any implementation along this idea of a list of possible names should keep this in mind.
Secondly, it’s strange. It’s not what we’ve done in the past, and no matter how it may approximate what actually happens, you’ll get laughed at for proposing it.
…and no one with any sense of ego likes being laughed at. Only take this road if you’re willing to have to explain it to a number of people who either reject the unusual, or accept it but lack the backbone to explain it to the next guy. The meatware is always an issue, both the brain of the user, and the brain of the developer who avoids looking stupid to his peers.
Recent Comments