Can't agree more. My favourite recent example was when I had to change bank due to my existing bank pulling out of the country. Somewhere along the way, I provided feedback or made a complaint to the new bank (companies don't advertise options for "constructive feedback"). Some time later I received a cold call reporting to be from the bank and asked me to authenticate who I was. I refused on the basis that my feedback had been because of this exact scenario. They eventually wrote to me to explain their couldn't pursue the matter because I refused to engage via cold calls in which I couldn't authenticate the caller. There are solutions to these problems but they aren't used very often. :/
One example of SecurityDoneRight (but with a strictly limited scope) is Google's ALTS (Application Layer Transport Security) which seems to be a descendant of LOAS (Low-Overhead Authentication System) -- that if one server is compromised, other servers are still secure. Programmers don't have to do anything to use this; it's Just There.
Another example I can think of is Google's internal tool connecting to a server for debugging when I was working there -- the programmer had to have a job running on that machine (with all its authentication credentials) plus the the remote access was chroot-ed to only that task's files. But, most importantly, it was almost never necessary to ssh to a server because the necessary information was usually available by other - and better - means.
Both of these were designed by and managed by best-in-the-world security people. And those people weren't able to develop a product that made it easy to use OAuth or OpenID. (I wonder how Passkeys will work out ...)
Can't agree more. My favourite recent example was when I had to change bank due to my existing bank pulling out of the country. Somewhere along the way, I provided feedback or made a complaint to the new bank (companies don't advertise options for "constructive feedback"). Some time later I received a cold call reporting to be from the bank and asked me to authenticate who I was. I refused on the basis that my feedback had been because of this exact scenario. They eventually wrote to me to explain their couldn't pursue the matter because I refused to engage via cold calls in which I couldn't authenticate the caller. There are solutions to these problems but they aren't used very often. :/
Exactly! Isn't that the worst!?
This is such a good post it should be mandatory reading.
One example of SecurityDoneRight (but with a strictly limited scope) is Google's ALTS (Application Layer Transport Security) which seems to be a descendant of LOAS (Low-Overhead Authentication System) -- that if one server is compromised, other servers are still secure. Programmers don't have to do anything to use this; it's Just There.
Another example I can think of is Google's internal tool connecting to a server for debugging when I was working there -- the programmer had to have a job running on that machine (with all its authentication credentials) plus the the remote access was chroot-ed to only that task's files. But, most importantly, it was almost never necessary to ssh to a server because the necessary information was usually available by other - and better - means.
Both of these were designed by and managed by best-in-the-world security people. And those people weren't able to develop a product that made it easy to use OAuth or OpenID. (I wonder how Passkeys will work out ...)