I have a question about Agent password storage in the Logger database.
I found this on Security best practices guide for UCCE 11.0 -
"User and Agent Passwords Unified ICM/Unified CCE systems are highly distributed applications composed of many node and server applications. The system stores application user and contact center agent passwords in the Logger and the Distributor databases as an RSA Data Security, Inc. MD5 Message-Digest Algorithm hash. When passed from one server node to another, such as from a PG to a Router, The system passes the passwords as MD5 hashes."
Are there any plans to offer an alternate encryption mechanism for password storage ? A couple of big customers security teams raised concerns about MD5 algorithm Hash usage and would prefer to have AES 256 encryption algorithm for agent password storage.
Is there a way to do that now ? Or will this be addressed in the future release/s ?
Thank you !
I work on the product, but I don't own the backlog and so can't provide a commitment. You would need to follow up with Jim Lundy or Piyush Khanna to get a feature commitment.
So the short answer is yes, we're looking at moving agent password hashing off of MD5 to an appropriate secure encryption, but no, we don't have anything committed.
Today, the customers running v11.5 have the secure option to implement SSO with ADFS which will eliminate the need for these MD5 passwords all together.
We would like all of our customers to move to SSO. This is the most secure solution.
We recognize that not all customers will jump to SSO as there is some overhead to setup ADFS and the IdS configuration. Also, not all are on v11.5, yet.
Is there a subset of customers that will never move to SSO? I think probably. There are some shops with rapid turnover that are looking for a lightweight way to maintain agent credentials.
Do they want more secure authentication for non-sso agents? Yes. Does it stop at MD5? No. There's many parts to secure authentication that we would like to add, like options for password aging, strength checking, etc... So we're looking at it from a holistic view. Do we patch up what we have re-inventing the wheel each step of the way, or do we transition authentication to some 3rd party mechanism like Active Directory. We already support AD for admins in all cases, and for supervisors on CUIC. The main question is whether it would be too costly overhead for seasonal transitions when adding a couple of hundred agents for the holidays? Would it be good enough to to have some "dummy" entries in AD reserved for temporary agents where "user" is just the agent ID?
Honestly, I'm looking for some field feedback to help inform our decision on which way to go.
Option 1- Fix MD5, but leave other secure authentication requirements incomplete for non-SSO.
Option 2 - Do a native authentication build out on what's there to add the other 5 or 6 authentication requirements we're not including.
Option 3 - Move agent authentication to AD for non-SSO.
Ultimately, it's not up to me, but I have some amount amount of input. So what do you think?
Please keep the non SSO option in the future, some customers want to go with the more simple solution and not add in the extra complexity, even if it does have some benefits.
Thanks for this feedback Bill. That aligns with what I was thinking.
I'm curious whether there's a way to make it cheaper for customers to set up dummy agent accounts in AD or some other authorization server. Like if they set up some dummy accounts based on agent ID as the userid, and users had very limited privileges to do the minimum necessary for an agent.
Single-sign on has a huge downside when testing / rolling out a contact center. I am right in the middle of this and have approx 300 agents across three PGs (NA, EMEA, APAC). I tested every agent's Finesse login a couple of weeks ago - and I could do that because the agent IDs and passwords match.
During the phased roll out, we select a number of real agents in the business(s) we are rolling out that weekend, across each of the PGs, and log in as them, choosing agents with the correct PQ attributes, and we test call delivery. This sort of validation with single sign on would not be possible and you would be relying on test agents.
I am not a fan of SSO - I like the lightweight approach. I have to ask myself, what are people worrying about? InfoSEC is like a God at some companies. If someone can guess a contact center agent's Finesse credentials, what then? What important and confidential secrets they discover this way and offer to Wikileaks?
Thank you David for the detailed feedback.
Agreed that it needs to be looked at from holistic view and I guess there cannot be one solution that will satisfy all customers.
I like the idea of Active directory integration without a need to move to SSO. Would be good if we provide an option of third party integration and also update the existing mechanism of storing passwords internally using more secured mechanism with password aging, strength etc.
Also exposing some APIs to do the admin configurations will also be a nice to have enhancement. Some of the customers have the requirements of updating passwords every 30 days and at present they manually update the passwords. Would be good to have API for managing ID/Password so agent set up, password update etc can be done programmatically.
Thanks for your feedback. If we went to AD as an authorization server for non-sso, I expect it would have the mechanism for agents to update their own passwords.