Maybe some sort of simple USB dongle (like a yubikey) could be fed by the phone via bluetooth or nfc to do this?
Instead, the better solution would be, you point your phone to a QR code on the computer screen, press “confirm”, the computer is magically logged in, until you then press “log out” on your phone and the computer is logged out.
They initially rolled it out as a 2FA option, then as an optional for 1FA.
So while you are logged in, the attacker can do anything they want.
That would require each site to implement server-side components to talk to Clef, and most sites have been ice age slow to implement basic TOTP never mind yet another method.
Now, if the big existing OAuth sites, your Google, Facebook, Okta, etc implemented a QR code method like Clef then it might work.
Whoever logged in first would invalidate the hexhexhex token and the second person would need to start another browser session.
Login would be:
* scan QR code, sees https:/ /megacorp.com/login?session=hexhexhex
* Password manager asks that you want to log in with account X.
* Negotiates with auth service
* Website recieves your confirmed token via websocket
* You're logged in.
And, of course, if you don't have an account, the password manager can get you started creating one.
Unfortunately I don't see the need to actually fill and type passwords going away any time soon.
I'm mostly complaining about having to either:
1) Install the password manager on a computer to fill in passwords. You end up typing the password manager's password into the computer which could compromise the entire database as well as give the computer other information about your accounts and website usage.
2) Otherwise you have a password manager on your phone. You have to view the password and type it into a keyboard. Typing complex passwords is a pain in the butt. It would be nice if the password manager on my phone could just somehow type it for me. Then the only thing that goes into the computer is the exact password I'm trying to use.
I also tried kicking the android driver and just using (iirc) usbfs or what is was called so you could implement HID in userspace and repurpose old phones while kicking android. But the vendor kernel stopped compiling :/
This woul imo be a really interesting application to repurpose old android phones.
Or patch the android stuff to add HID support: https://github.com/pelya/android-keyboard-gadget
Your grandpa could use it to secure his crypto wallet.
For a certain sense of "secure". Because fingerprints aren't. Not just because you leave them everywhere, but because the way we examine fingerprints doesn't have a result that is particularly unique.
Not even at the criminal case-law level [0][1].
That fingerprints are unique is an assumption, but it doesn't match our reality. They're useful for eliminating from a known small pool, not matching against a large group.
Many of the elements we match against run in families.
[0] https://mccoll-law.com/attorney-profile/37-general/38-finger...
[1] https://www.telegraph.co.uk/science/2016/03/14/why-your-fing...
It wouldn't be hard to add encrypted password storage to the EspUSB firmware. The difficulty is that you need to know the keyboard layout of the destination computer.
Keyboards don't send a letter "A", they send "shift" + "a". If your computer's language setting is French, or German, or Chinese, etc - things get complicated fast.
To make it worse, passwords need to use special characters (not just a-z). Sure, it's not unreasonable to ask you to change the keyboard layout, because you're on Hacker News and are therefore pretty good with computers. But this would limit an average user.
The other problem is that it types the password as plain text, which is a bit insecure. If I have to carry a dongle and change settings on the client, why not make the dongle do some sophisticated key pair exchange with the client app?
It's a good idea for another EspUSB demo app, but I worry that it couldn't find mass market adoption as a product. Without sales of over 10,000 devices, it's not possible to pay off the FCC certification lab, and I haven't got a solution for that.
I kinda prefer simplicity. What if the dongle breaks, gets lost, or some change in the environment makes it impossible to run the client or perform this sophisticated key pair exchange? Locked out, fun.
My keyboard can generate passwords, but I could generate the same passwords on paper (or, more likely, using a piece of software running on some other device) without ever connecting to the device where I'm going to enter that password.
The kinds of things that people get put on watchlist for, like where to buy industrial quantities of hydrofluoric acid.
EDIT: If you're on an untrusted device, should you really be putting secrets into it? Maybe not!
Unless they're using Excel functions to generate password{n++} . That'd be clever and yet horrid at the same time.