Autospill vulnerability and deploying password replacement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yes, I get the fact that some people have this weird idea they are going to get rid of passwords with passkeys. But in the real world, passwords are going to be with us for a very long time and even longer if the people promoting the password to passkey transition continue to adopt the exact same tactics as the IPv6 crowd.

It is over 30 years since I first learned about the imminent IPv6 transition and I have been telling to the FIDO folk for well over a decade. Developing a new mousetrap is the easy part, deployment is always the hardest part.


The Android password overspill vulnerability is currently going the rounds. It is a serious but manageable problem. The problem being that managing it requires an industry wide effort to deploy infrastructure that makes use of password managers secure and that is off message right now because all the majors are trying to make passwords obsolete.

Let me make an unwelcome suggestion - the way to achieve global deployment of passkeys is to grease the wheels for deployment of password managers.

I have used passkey a few times now and the problem I find is that passkeys simply don't give me the ability to access my account from any of my devices and no, the QR code thing isn't the solution because every single time I try to use it, my phone is in a different room to my laptop.


Imagine a world in which every application, of which browsers are only one instance, supports a common interface to a password manager that resides IN THE PLATFORM and connects to the password management service of the user's choice. OSX and Windows already have much of the necessary infrastructure to support that already. Call this 'Open Password Manager'

Such a protocol would of course be making heavy use of public key cryptography behind the scenes. (And if you let me write the spec, it will use threshold cryptography so that the password management service has no access to the credentials stored.)

Ubiquitous use of password managers would enable ubiquitous use of long-and-strong passwords. It would also provide the basis for integrating protocols to protect the use of those passwords through use of PAKEs and channel binding. Call this 'Open Password Security'

The goal here is to provide the user with the safest possible authentication technology. Public key is only relevant insofar as it is a technology we can choose to use.

Of course, Public key is the king of authentication tech because I can prove I know the secret without disclosing the secret. And every user we have provisioned with Open Password Manager has the means to use public key in place of passwords and every site we have provisioned with 'Open Password Security' has the means to accept them. Moreover, or password management service can manage passkeys across devices same as passwords. So the limitations that stop me using passkeys right now go away.


So what I am arguing for here is a strategy where instead of looking only at the final end state and designing that, we acknowledge the need for deployment infrastructure and the fact that we might need to fix the thing we want to get rid of as part of the getting rid of it strategy.

Here in Boston, we had this thing called the Big Dig. One of the very expensive and complex parts of the project was the construction of a connector from the old raised highway to the new sunk one. This was built, used for a few years and then demolished.

If we want to get rid of passwords, we don't necessarily have to do it my way but I am certain we have to think about deployment as the biggest part of the problem

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux