Neat - some ideas about authorizer HOT 11 CLOSED

Hi @wzrdtales
thanks for your feedback. I agree with you that alternative 2FA methods likle u2f or webauthn are very slowly adapting. And now we already get the next fido standard: passkeys.
I have already an Authorizer prototype with u2f and webauthn. So my plan is to have it supporting a lot of different kinds of authentication factors.

But I don't agree with your concerns:
My vision is to have an offline cross-platform solution which is working over well-defined standards (USB, Bluetooth, NFC).
The offline part is rather important that my idea is not having a everyday phone with Authorizer but a proper hardened device which was a phone in its previous life. As it only serves one specific case (credential management), it should be harder to compromise than the system where I need to enter the credentials on.
But in the unlikely event that the Authorizer device is compromised, I'm more concerned about my credentrials than an attack on my other devices.
The second part is cross-platform. Developing browser extensions, drivers or apps and keeping them up to date for any of the client devices takes much more time and efforts and does not really minimize the risks. Depending on the technology, it would increase the risk as new, not well tested interfaces might be developed for this.
Also if I'm in the need to enter credentials on a machine I dont use daily, I don't want to install anything there to have access to my credentials. As well the use-cases would be limited, e.g. a browser extension does not allow me to enter the TOTP in a SSH session in putty.

I hope that makes sense for you.

One question: who is "we" in your text?

from authorizer.

The offline part is rather important that my idea is not having a everyday phone with Authorizer but a proper hardened device which was a phone in its previous life. As it only serves one specific case (credential management), it should be harder to compromise than the system where I need to enter the credentials on.

Well I am coming from practicability standpoint, which is very important in the enterprise context. The fact is: an employee will have always his main (business) phone with him and charged. The same is not guaranteed for a secondary device only used for otps (plus shutting it down to safe electricity would neglect the whole purpose of being able to more quickly access).

from authorizer.

so to be clear your project peaked my interest since it would allow to make otps easier, similar to yubikeys by just touching the needed otp instead of reading and typing against the time counter. Whenever possible we use yubikeys, but there is tons of apps that only have totp as an option.

from authorizer.

The second part is cross-platform. Developing browser extensions, drivers or apps and keeping them up to date for any of the client devices takes much more time and efforts and does not really minimize the risks

Yes I did realize that and mention it already that HID is an easy way to do that of course. I understand that you don't want to invest this amount of effort.

One question: who is "we" in your text?

We, as in our company.

from authorizer.

The offline part is rather important that my idea is not having a everyday phone with Authorizer but a proper hardened device which was a phone in its previous life. As it only serves one specific case (credential management), it should be harder to compromise than the system where I need to enter the credentials on.

Well I am coming from practicability standpoint, which is very important in the enterprise context. The fact is: an employee will have always his main (business) phone with him and charged. The same is not guaranteed for a secondary device only used for otps (plus shutting it down to safe electricity would neglect the whole purpose of being able to more quickly access).

Enterprise usage would need a complete different approach here but is not the scope of Authorizer for the moment. I already thought about how I would implement something similar on that scale and I guess it would be online due to certain use-cases.
So I still can't share your concerns as they focus on something that was not designed for that purpose.

so to be clear your project peaked my interest since it would allow to make otps easier, similar to yubikeys by just touching the needed otp instead of reading and typing against the time counter. Whenever possible we use yubikeys, but there is tons of apps that only have totp as an option.

great - I suggest to use a Pixel phone for that as with GrapheneOS there is a good foundation for hardened Android devices.

The second part is cross-platform. Developing browser extensions, drivers or apps and keeping them up to date for any of the client devices takes much more time and efforts and does not really minimize the risks

Yes I did realize that and mention it already that HID is an easy way to do that of course. I understand that you don't want to invest this amount of effort.

I did not invest in such direction because Authorizer is still over the years a one-man show. I would be happy to extend the vision of Authorizer but I'm not able to do this alone.

from authorizer.

So I still can't share your concerns as they focus on something that was not designed for that purpose.

That's fair enough, never expected that. Again it peaked my interest since it is exactly doing what I was thinking of for a while. I stumbled upon this by accident actually, I really searched for something completely different related to USB security. If it interests you: Was searching if there is already an implementation available that only unlocks (or rather directly blocks when entered wrong) HID devices when typing a certain password sequence (as another method to fight against rubber duckies, also that could be circumvented by intercepting a real HID..., but yeah I guess we can't expect encrypted USB communication as this would suck...).

from authorizer.

So I still can't share your concerns as they focus on something that was not designed for that purpose.

That's fair enough, never expected that. Again it peaked my interest since it is exactly doing what I was thinking of for a while. I stumbled upon this by accident actually, I really searched for something completely different related to USB security. If it interests you: Was searching if there is already an implementation available that only unlocks (or rather directly blocks when entered wrong) HID devices when typing a certain password sequence (as another method to fight against rubber duckies, also that could be circumvented by intercepting a real HID..., but yeah I guess we can't expect encrypted USB communication as this would suck...).

Interessting idea. I guess this is something which needs to be integrated into a custom driver.
At general, operating systems like Windows allows already whitelisting of USB devices.

from authorizer.

@tejado Linux does for looong too. USB Guard, but both windows and linux have still similar problems of how to whitelist a new device. Really dangerous and difficult are keyboard devices, since you lock yourself out if you don't allow them, but open yourself up to attacks if you allow them.

from authorizer.

@tejado Linux does for looong too. USB Guard, but both windows and linux have still similar problems of how to whitelist a new device. Really dangerous and difficult are keyboard devices, since you lock yourself out if you don't allow them, but open yourself up to attacks if you allow them.

https://github.com/robertfisk/USG/wiki

From my perspective, the topic is similar to phishing mails: the users have to be trained and not plugging untrusted USB devices to the computer.
Protection on the OS side, e.g. whitelisting can be circumvented as the device attributes can be changed.

If you see this as a attack vector, any bluetooth devices are also risky or screen sharing remote controls.

from authorizer.

I will close this issue as this is nothing which I see in Authorizer. Feel free to reach out to me if you want to follow up the discussion offline.

from authorizer.

sure 👍

from authorizer.