Schneier on Security

Clive Robinson • June 3, 2020 12:33 AM

@ MrC,

I guess the lesson here is that “single sign-on” is just a fundamentally bad idea.

The way many “Single Sign On” (SSO) systems are implemented I would have to agree.

Also what many forget is that with the way SSO works the “spider at the center of the web” gathers a large amount of information about the individual using the service.

Thus anyone at an “upstream router” of thr SSO host gets to see the traffic to and from it (meta-data thus traffic analysis).

Thus the closer the SSO service is to the user potentially the more secure it is with regards the user-SSOserviceHost traffic. Logically this collapses down to a user creating their own equivalent of an SSO when they use it on the same host or behind the user level application in the form of a secure token or piece of paper in their wallet.

From a network centered view a piece of paper in your wallet is more secure because a network based attacker can not get beyond the User Interface of the host the user is using. However as the piece of paper in reality forces a “plaintext password” at the UI the password is not secure.

Thus if implemented correctly a “challange response system” on a Secure Token in the users possession and an adequately provisioned Hardware Security Modual (HSM) at the service the user is attempting to authenticate to is at the authentication level more secure.

But a Secure Token and HSM authentication solution is very expensive per user to implement, thus is unlikely to become available to a service unless either the service owner has sufficient reason or the authentication service owner has another way to finance the service. Which these days almost always means some form of PPI Data gathering.

For what is fundamentally a simple idea authentication has a great many wrinkles, each of which can easly be seen as a gaping security chasam from a an attacker/defender security perspective.

Arguably we don’t have any “secure” authentication systems as the complexity issue you mention is always present and different in each and every implementation. And nobody has sufficient depth and breadth of knowledge, or time to verify the system secure against all currently known attacks. As for as yet unknown attacks to the system, well designers and implementers of authentication systems should remember that often misquoted line from a very early 1970’s film,

“You’ve got to ask yourself one question. Do I feel lucky?”

Clive Robinson • June 3, 2020 4:18 AM

@ Wael,

SSO is needed

That is debatable under any given set of conditions that give rise to a system. Thus whilst the concept is valid under certain limited conditions, any wider requirment is at best an assumption.

As I’ve indicated SSO has issues, one of which is how you do what is assumed to be a basic “two party function” of authentication through or via a “third party”. It’s not just the issues to do with communications security and meta-data giving rise to traffic analysis by an assumed hostile “Eve” or “Mallory”, it’s also a trust issue.

In a secure two party transaction, if something goes wrong you can establish which party is at fault only by examining your own actions. The same is not true of a three party transaction. Worse the other two parties can conspire against you in various ways.

In real life we see this game played out, with the harmed first party getting passed backwards and forwards between the other two parties ad infinitum. The only way to stop this is to make it clear that you only have one relationship with say the second party, and that as they engage the third party they are responisble for any actions or failings of the third party to you. One of the failings of SSO is that trying to establish a chain of responsability / liability is not possible. Thus to misquote and old saying “Whilst their is blaim there can be no claim”. In essence nearly all SSO systems fall into this category. That is you are forced to use SSO as a user but neither the SSO provider or SSO using service have liability towards you. Thus there is a very definate disincentive for either the SSO provider or SSO using service who have “externalised their liability” to fix any security issues, unless they think their reputation might be harmed.

Clive Robinson • June 3, 2020 11:47 AM

@ SwashbucklingCowboy,

Stop focusing on the security of each part and focus more on the security of the whole.

Security is assumed to rest on “The weakest link in the chain” unless you do focus on the security of each part, you will not understand if that part is a weak link or not and importantly in what context.

Security is multifaceted thus context is very important. Whilst you may have an authentication process that can not be fooled, it may not be appropriate to use it if it haemorrhages PPI to anyone who cares to passively listen to it. That is there are applications where strong authentication is not actually required but a high level of confidentiality in network communications is.

Not getting the confidentiality right can and has led to a loss of life in what are euphemisticaly called “sources” by intelligence entities.

Allegedly it was a lack of communications confidentiality in a CIA web app that led to both the Iranian and Chinese security services rounding up and executing or imprisoning twenty or so sources for the CIA in both countries in 2010-2012 (the joint FBI-CIA “mole hunt” investigation was code-named Honey Badger and apparently found nothing of note).

https://www.telegraph.co.uk/technology/2018/11/03/dozens-us-spies-killed-iran-china-uncovered-cia-messaging-service/