Schneier on Security

Clive Robinson • April 1, 2022 10:47 AM

@ ALL,

Think carefully on the articles incompleate statment of,

“some forms of MFA are stronger than others, and recent events show that these weaker forms aren’t much of a hurdle for some hackers to clear.”

So Strong-v-Weak but what is not being said about that?

Well the “Strong systems” mostly do not act as a significant invasion of privacy vector, or make other extended ICT attacks easier.

The “Weak systems” however –especially those pushed hard by Silicon Valley Mega-Corps– can be seen to be major vectors for not just invasion of privacy to get ID revealing PPI, but also in the process make the person considerably more vulnerable security wise as it causes unwarranted disclosure both overtly and covertly.

But further “Remote MFA” rather than “Local MFA” systems causes “data aggregation” or the “All the eggs in one basket” security vulnerability to both PPI and service usage. As an attacker the more information you have on an individual the better. Having all an individuals “data in one place” or under a “single idetifier” is in effect a “motherload” for an attacker…

Whilst you can design “Remote Strong MFA” without the overt issues, the question of the covert issues remains open.

Why?

Well Strong MFA is “expensive” in that mostly it involves some kind of technology / token that is a “Tangible Physical Object”(TPO), rather than an “Intangible Information Object”(IIO)[1].

Thus the cost and user inconvenience gets minimized by aggregation, that is if the TPO gets shared for multiple services. So depending on the way the IIO in the TPO works, any “shared secret” can become known to “many” services / third parties, having a significant negative impact on security…

But removing this potential security impact makes the TPO token much more expensive to use, and a lot larger as it needs rather more than one button.

The current solutions to this realy are not good as many try to take the human out of the communications channel, by using USB etc. This is potentially a security disaster, because it open the IIO in the TPO vulnerable to attack by malware on the computer. As has been shown with eye wateringly expensive “Hardware Security Modules”(HSMs) writing software for them is almost as bug ridden as consumer application code…

So MFA has very real issues over and above that which most people realise. And if not for the fact there are few alternatives, MFA would be considered as insecure if not more so than certain “One Time Pass Word/Phrase” Systems.

However the real “hidden issue” or “Elephant in the Room” issue with MFA is humans are not upto transfering enough secure bits, and any electronic communications to easily open to malware on the computer the user uses…

So a PhD level research project or three to find not just a Pass Word/Phrase but MFA replacment…

Oh and “For the love of chosen Deity” do not suggest bio-metrics ever, they are in no way secure as thugs and very young children have demonstrated, and they are very limited in revocation options…

[1] Even though the token is usually a TPO, rather than an IIO, any actual “Remote” usage is only by necescity via the IIO within a TPO device. Thus all those “covert channels” issues of a TPO device arise, and need to be mitigated[2].

[2] The very real necesity to stop or reduce covert channels[1] generaly mandates the token be “used through the human” communications channel. This causes further complications that even further reduce security[3].

[3] The problem with using the “human” communications channel is that it significantly reduces any security margin to about 20bits of real entropy entered by the user. Which entails other Authentication Factors to be required to get upto atleast 60-64 bits equivalent[4] of real entropy (think temporal and geospatial but with significant care to avoid many types of attacks).

[4] The question of “entropy” arises frequently in security but the generation and measurment can be hard. For a “True Random Number Generator”(TRNG) every bit output needs to be,

1, Entirely unbiased.
2, Entirely independent of all other bits.

With physical sources and instrumentation the first is at best difficult, the second very difficult even under favourable conditions.

If that can be achived the communication problem arrises, three digits, gives ~10bits, three upper or lower case gives ~14bits, three fixed case and digits gives ~15bits and three both upper, lower and digits gives close but not quite 18bits. Getting 60-64 bits transfered without a human error is not going to be easy for most as typing in 37digits without error is beyond most as well as extreamly tedious.

Clive Robinson • April 1, 2022 5:10 PM

@ Nick Alcock,

Not so. FIDO2 tokens…

Two things to note,

1, Not all tokens in fact most are not FIDO2 by a very long way.
2, I was talking about tokens in the general sense.

The latter being why I said,

“So depending on the way the IIO in the TPO works, any “shared secret” can become known to “many” services / third parties, having a significant negative impact on security”

Oh and sorry but even the second part of my statment applies to FIDO2 tokens as well… Bcause in high probability they are vulnerable to,

1, Poor software implementation.
2, Covert side channels.

It’s why you realy should not have tokens that are not “energy gapped”. But that’s a tale for another day (or you can look it up in past postings on this blog).

Oh by the way I was extracting secrets out of gambling machines and electronic wallets back in the 1980’s by the use of both passive and active EM EmSec attacks. Look up “EM Fault Injection Attacks” years later –despite the efforts of a certain American– it became a topic of interest, and now even gets in hobbiest and trade electronics magazines. It’s only taken a third of a century but hey slow and steady said the tortoise…

Clive Robinson • April 2, 2022 10:48 PM

Why developers must be proficient lock pickers to have a future.

@ JonKnowsNothing, lurker, SpaceLifeForm, ALL,

With regrds : Banks will automatically log you out…

As an object lesson

And

I don’t think log out means log out anymore….

With HTTP it never had any meaning, it was never ment to transact that way.

In fact HTTP was deliberately designed so it could not have meaning, because it was deliberately made “stateless” for good and proper reasons including those of security.

To enact log-in and log-out implies without doubt state and it’s change or transitions.

State requires storage, with a “statefull service” split across a server and a client, it requires state to be stored at both ends, and importantly,

“A reliable mechanism to ensure synchronisation”

It’s impossible for HTTP to provide such a reliable mechanism as it has no inherant notion of “continuance” be it of “state” or more importantly of “agency” and “communications”.

It’s the price you pay for “Packet Switching” not “Circuit Switching”. At the physical level of IP it is,

“inherently unreliable”

A “fire and forget” “Datagram Service”, which is always probablistic and prone to unexpected events non delivery being just one of very many.

The same problem applies to the older Telnet protocol, and it was from the problems created there that the designers of HTTP knew it MUST BE “stateless” and WITHOUT “continuance”.

It was others, in their cupidity that tried to add state and continuance when neither server or browser, was designed for such.

A case in point, back in the early part of the 1990’s I started studying an MSc in Information Systems Design (MID). Unlike those who taught it and most who studied it I was by several years of training and practice at all levels a “Communications Engineer” of what the University recognised as “Advanced Standing” (effectively the same as already holding a Masters Degree, my intent being to progress it to a PhD in another knowledge domain).

So there we were one evening, at a demonstration of a “research tool” that was in effect an inverted text database of journals and other scholarly works with an advanced search tool abd HTTP front end.

One of the systems first “architects” was demonstrating it in a “Question and Answers” session. He started talking about the multi-server design that alowed what we would years later routienly call “load balancing”. Due to the way HTTP worked load balancing normally whilst not “trivial” at the communications levels was simple at the HTTP level because HTTP was “stateless”.

That was any request you as a user sent off from your browser could be answered by any one of many physical hosts masquerading as a single host to the browser.

However they had added “log-in/log-out” and accounting for the purposes of,

1, Billing
2, Controling service provision.

After several issues they came up with a “token” that would be added to every GET/POST by a “loged-in user”. This would be not just for AuthN, but AuthZ purposes as well.

Thus “state” had not just reared it’s ugly head, like a hydra of the deep those heads could pop up every where at any time and importantly in more than one place simultaneously.

He appeared shocked at how quickly I had worked it out when I said “You’ve based it on Kerberos havent you?” After a momentry pause he said that yes, the token was supposed to act like a Kerberos Server Ticket.

I then smiled and in a slightly amused voice said “You know that won’t work the way you want it to?” To which not just he but about every one else in the room looked very surprised, and he said “Why do you think that?” to which I replied “A couple of reasons, split state and imposible to resolve deadlock”.

Sometimes it’s funny to see every face in a room look “puzzeled beyond comprehension” and effectively dumbfounded, though most times not. As it’s a major indicator of very serious and often very expensive problems ahead, and any sane person would “make like a rat”[1].

For those that do not know “deadlock” is when two things that should not, nevertheless do happen at the same time and the action to be taken can not be determined. It’s usually a very nonlinear and apparently random –actually chaotic– process but the frequency of such events correlates to load, and the number of inputs to a system (you can see it at work in the likes of the memory paging and interupt algorithms used in the kerenel of a multi-tasking OS, and sometimes hear it with disk thrashing).

Whilst more well known these days, back in the early days of the 90’s it was effectively unknown to software developers at all levels. Because the hardware designers had “designed it out” when developing the actual physical systems. Likewise the low level OS designers and developers sorted it out in the kernel. So it was back then very rare to see it[2].

But load balancing with “state” gets right up in your face as a Web Developer. Because it means “multiplexing / switching” of hosts and with “statefulness” which requires synchronisation that can be not just of very high degree of complexity, it can be non-determanistic, thus lead to unresolvable issues hence “deadlock”. Often the trick tried is to put all the state on a single backend server, but as a solution it does not scale very well.

In a telephone system you “circuit switch” which can be treated as a single event that can be made reliable even with split state[3]. Supprisingly to most the resulting state diagram[3] is true for all sequential processes. It forms the most basic step in project managment and it’s how all sequential programs on multitasking operating systems work. Though it’s mostly not seen as the OS and kernel usualy abstracts away all but the “active state”[3:2] from programers. Anyone who starts playing with signals or interprocess communications gets the veil lifted just a little bit but by no means enough to understand all thats required.

It’s one of the reasons most multi-threaded code is inefficient or flaky, and parallel processing which is computings future is seen as a too difficult or impossible task by mostly sequential thinking programmers.

It’s also the root cause of why log-in / log-out causes so many Web based service security issues from split state that is not synchronised and ultimately can not be due to the many issues of packet switching (which a number of network based attacks exploit).

I’ve known this issue fairly intetmately for now well into a sixth decade. It was how I originaly did my “hacking” when it was a “good thing” and not in any way “illegal”. And it all started with insane curiosity about the world that gave rise to “lock picking” for fun long before I was a teenager. An activity where those multiple pins on springs followed their own sequential process in parallel with their adjacent neighbours, and could easily deadlock (bind) or fault (drop) forcing you to start again with a slightly different approach.

Like Matt Blaze, I think all security engineers and in fact all programers should learn how to be proficient lock pickers. Then they would learn at a visceral level things that they would not intellectualy dare approach. So can not just overcome their trepidation, but learn how to build competently with split state and fundemental unreliability thus more securely.

[1] Old english saying “To make like a rat on a sinking ship”. Sailors had noticed long ago that rats could be a “portend of doom” in that they would sometimes unacountably scuttle off ship rather than on. This happening in port shortly before a journy in which a wooden ship foundered. It actually turns out that rats are fairly smart and possesed of good hearing very close to the ships “frames” –structural beams– they scuttled along. Evolutionarily they had learned that certain noise types in trees were not good news. Thus the rats could hear “sick ship syndrom” where the frames had rotted in places where it could not be seen. Thus the rats could “Get the heck out of Dodge” before the inevitable of the frames colapsing and the ship folding up like a soggy cardboard box or worse in high seas.

[2] However “telecommunications engineers” had found out the hard way in the early days of “telegraphs” and later “telephones” when the idea of “shared” or “multiplexed” lines etc came in and “switching” was required that a reliable process was required[3].

[3] Circuit Switching can be made a “statfull process” and is either inactive or active, and active has four basic states,

1, Setup
2, Active
3, Clear down
4, Fault.

The normal transitions are the synchronous order 1,2,3 or asynchronus X,4,3 where X is any of the synchronous states 1,2,3. The asynchronus trigger event causing state 4, which means that state 3 being the terminator state must at all times be reliable. If not trouble will follow as night follows day[4].

[4] For a “clear down” or “terminator state” process[3:3] to be reliable you generally need things to be “atomic” which precludes split state and unreliable communications. Anyone who has played with any database updates at the storage level gets to know some of the problems and imperfect solutions (but rarely the security ones).

Clive Robinson • April 2, 2022 11:51 PM

Why developers must be proficient lock pickers…

@JonKnowsNothing, lurker, SpaceLifeForm, All,

Due to “being held in moderation” and the moderation being very intermitent these days a long reply I made, has not appeared and may not for some time…

So a brief synopsis pending the post getting successfuly moderated.

Re : log-in / log-out on HTTP having no meaning and importantly not being able to ever be reliable.

Back in times past it was mainframes and dumb serial line mechanical teletypes. Later in the end of the 1970’s the first usable Personal Computers appeared, with the Apple ][ arguably being the most successful and widely used. In effect both of these types of computer system were “central processing” units which ment just about everything was “local” “single user” “single task” and could mostly be assumed to be effectively “atomic” as far as the users and software developers were concerned.

Which ment neither “state” or “unreliable” communications were an issue.

But the end of the 1960’s had seen the start of both “multi-tasking”, “multi-user” and local and remote “networking” on the “machines in the middle” the minicomputers like the early Digital PDP machines that had 16 and 32 bit architectures.

This brought both “state” and “communications” into importance.

Many issues arose and different solutions tried but it became clear that,

1, For efficiency communications should be multiplexed / switched.
2, The switching needed to be not by “circuit” but by “packet”.
3, Packet switching was fundamentally unreliable.
4, Packet switching was fundamentally insecure.
5, Packet switching needed “state” at both ends of the unreliable communications.
6, This split state needed to be kept synchronized.

Issues 5&6 are the cause of the problem and they can not actually be solved. As the users of Telnet that had both problems found with significant issues not just for the users client PCs but the servers as well.

Which is why HTTP was originally designed not to have “state”. In essence to the user the Web browser originally appeared “circuit switched” not “packet switched” like Telnet.

Making interactive HTTP sessions are thus plaqued by the same underlying issues Telnet had.

With the result interactive HTTP sessions,

1, Will give users unreliable behaviour.
2, There will be irresolvable security issues.

To see why hopefully my original comment will come out of moderation soon with the answers along with why all software developers and ICTsec practitioners should learn to lock pick…

Clive Robinson • April 3, 2022 8:44 AM

@ lurker,

Oh, you say they’re insisting on using the solution to an unsolvable puzzle…

I see you are taking @SpaceLifeForm’s advice at the end there and “joining the dots” 😉

@ ALL,

Remember in the real world “unsolvable” does not mean “unusable” all it needs is for the problems to be on average sufficiently rare to be traditionaly called “Acts of God” and get written as such into agreement terms.

Thus pass the problems onto someone else in a process we call “Extetnalising Risk”.

The fact that sticking with an “unsolvable” problem in one domain might also alow you to keep reaping in benifits in another much less overt domain…

Of course would not be a reason to hold back on bringing new solutions that are condiderably better into the fore 😉

Maybe looking at who effectively funds,

1, HTML and http.
2, Server development / usage.
3, Browser development.

Might be an interesting excetcise.

Clive Robinson • April 4, 2022 4:47 AM

@ Mr C, ALL,

Last I checked, FIDO2 wasn’t a form of “two-factor authentication,” but rather a “replace the password with a dongle scheme.”

Ahhh that depends on who you ask…

Remember that a company argued and an auditor accrptted for his check list that “username” and “password” were two seperate “something you know” factors…

As I understand some of the blurb about FIDO2 devices, some argue,

1, The device is something you own.
2, The device PIN something you know.

The problem is in reality the pin is a single factor to the device, THEN the device is a single factor to the server. They form a daisy chain of factors.

That is the factors are being used in series not parallel. As the serial use is not “atomic” you have a chain of factors where “the weakest link” security rule applies.

But there is a similar argument that highlights the problem in a different way.

Imagine a Smart device that like most of them are geospatially (GPS) and temporally (RTC) aware.

If you have a security App that needs the Smart device to be “in a given place at a given time” for you to use it are “time” and “place” independent sub factors of “Something you know?”

From my point of view “potentially yes” but you also need to consider,

1, GPS can be “replay attacked”.
2, As GPS is seen as the most accurate clock a Smart Device can access it does get used to “discipline the RTC”

Which means that potentially when seen through GPS they are not independent. That is GPS is a “single point of attack” in the security model.

There are other several other arguments, but… yes,

“We really need to toughen up the definition of Multi-factor Authentication.”

Clive Robinson • April 4, 2022 11:00 AM

@ ALL,

In my “stand in” post above I did not go into too much detail about load balancers and why HTTP can be such a pain with them…

Turns out to save me the trouble, somebody just has,

https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/

If when reading instead of flames and smoke ofca “brain on fire”, your brain gives fog or mist especially red mist. Can I suggest a trip to the kitchen for some strange brew or equivalent 😉

If however if it’s a breeze, can I suggest learning how to multiply floating point numbers using Roman Numerals as a little lite brain train 0:)

Clive Robinson • April 25, 2022 9:15 AM

@ AlanS,

I think you need to reread my post as I made no such claim.

Did you or did you not say,

Well, as noted already by Nick, there is no shared secret.

To which I pointed out there was a shared secret via the two primes PQ even though obscured in the PubKey.

But you went on to say,

The secret never leaves the security key…

What secret are you talking about?

I’ve already shown that atleast on secret has to be shared in some manner or there can be no proof to authenticate against…

You then go on to talk about a signirure counter is that the “secret” you are refering to because, to do what you claim of it, it to must be shared…

Every proof of ID protocol we use, needs a shared secret of some form, it may not be immediately obvious but it is required.

If you think about it you can not prove who you claim to be unless do have a shared secret, because otherwise someone else can impersonate you.

If there is no shared secret / shared hidden knowledge or what ever else you want to call the “root of trust” them proof is not possible, so it defaults to the old “I’m Spartacus” claim problem, hence my closing paragraph.

As a matter of curiosity, why wait over three weeks?