I kinda hate the push towards passkeys. If you have two factor Auth, going to passkeys makes you go back to 1 factor, aka less secured.
There’s also more and more 2FA fatigue attacks going on, and they can affect passkeys too, and if you don’t have a 2FA that involves the user writing a code on the 2FA device, passkeys could be quite possibly worse than passwords
Passkeys use public key authentication. This makes them very resistent to phishing attacks. It’s also not possible for a phishing site to request authentication via a passkey created on a the original website.
SSH keys without passphrases are just fancy credential files sitting in your .ssh/ directory, basically like writing your passwords on paper and leaving it in your desk drawer.
Take a look at ssh-agent. It’s bundled with ssh-client and designed to solve this problem.
The quick usage is, create a terminal and run:
eval `ssh-agent`
ssh-add /path/to/your/encrypted/key1
#type in password
ssh-add /path/to/your/encrypted/key2
...
# all commands in this terminal will use the keys above w/o asking you for a password
git clone git@githib.com...
git push...
etc
So, basically you type your credentials once during the life cycle of your terminal.
If you really want to go full power-user, simple run ssh-agent (without the eval) and you’ll see it just sets some env-vars, which can be imported into any terminal/shell you have open.
So, if you put some logic in your shells rc file, you can effectively share a single ash-agent between all your shells, meaning you just need to type your password for your keys once when you log into your system… and your now passwordless for any future terminals you create (this is my setup).
Also, if you’re interested take a peek at the man pages for ash-agent. It has a few interesting features (ie: adding a password lock for your agent, removing keys from the agent, etc).
I had mine on paper for years before i learned about Keepass. I trusted it more than a cloud based manager because someone would have to physically be in my room.
I am a lot more careful these days but that is not beyond the pale for a lot of folks haha
It’s different. It’s still two factors if implemented correctly: 1. Possession of the passkey (better if you have a physical token, but passkey on your phone is passable). 2. Knowledge of your password (or bio authentication if you use face id or w/e).
Note you are not giving your password to the website, and if a hacker gets hold of your password they still can’t do anything without your passkey device.
It’s client specific and my phone requires whatever can unlock the phone and chrome requires either windows hello or a pin if under linux.
Certain implementations do whatever, and as far as the backend is concerned, there’s no way of knowing, unless you want to get into the business of locking down specific vendor keys…
But I say MFA is overrated versus just getting away from generally crappy password factors. Also passkeys are less phish-able than OTP type solutions.
Yes, it’s implementation specific, in this case your phone, or your browser is the passkey “device”. And as long as it’s protected by some form of authentication it’s OK (though I would recommend a hardware token over phones/browsers). If it doesn’t then you shouldn’t be using that “passkey”. Yes, there is no way for the website you are authenticating with to know whether your passkey is safe or not, choosing a secure passkey implementation is (unfortunately) the user’s job. But it’s the same with more traditional 2FAs, e.g. you can store your TOTP secret securely or insecurely, and the website will have no way to know.
Yeah. Passkeys are something I would love if they were a second factor because they are so much better than any other 2fa. And I use my yubikeys as second factors where I can. But why the hell would I not want a password too?
Passkeys are always supposed to be protected by another layer of authentication. e.g. a password should be required to unlock the passkey. If your passkey don’t do that, stop using it.
If I provide passkey support and still require a password, most users will get annoyed and not bother. If I provide it as a replacement for password, then I can get them onboard more often. I’d rather have them using passkey than sticking with password.
I kinda hate the push towards passkeys. If you have two factor Auth, going to passkeys makes you go back to 1 factor, aka less secured.
There’s also more and more 2FA fatigue attacks going on, and they can affect passkeys too, and if you don’t have a 2FA that involves the user writing a code on the 2FA device, passkeys could be quite possibly worse than passwords
Passkeys use public key authentication. This makes them very resistent to phishing attacks. It’s also not possible for a phishing site to request authentication via a passkey created on a the original website.
I think this post is about git CLI, not www.github.com.
SSH keys are very secure and you can still encrypt them with a password if you wish.
SSH keys without passphrases are just fancy credential files sitting in your
.ssh/directory, basically like writing your passwords on paper and leaving it in your desk drawer.Yeah, but who wants to type in a password everytime they push/pull?
Take a look at
ssh-agent. It’s bundled with ssh-client and designed to solve this problem.The quick usage is, create a terminal and run:
eval `ssh-agent` ssh-add /path/to/your/encrypted/key1 #type in password ssh-add /path/to/your/encrypted/key2 ... # all commands in this terminal will use the keys above w/o asking you for a password git clone git@githib.com... git push... etcSo, basically you type your credentials once during the life cycle of your terminal.
If you really want to go full power-user, simple run
ssh-agent(without the eval) and you’ll see it just sets some env-vars, which can be imported into any terminal/shell you have open.So, if you put some logic in your shells rc file, you can effectively share a single ash-agent between all your shells, meaning you just need to type your password for your keys once when you log into your system… and your now passwordless for any future terminals you create (this is my setup).
Also, if you’re interested take a peek at the man pages for ash-agent. It has a few interesting features (ie: adding a password lock for your agent, removing keys from the agent, etc).
I do it.
Every time.
And I keep a wired keyboard for it.
I had mine on paper for years before i learned about Keepass. I trusted it more than a cloud based manager because someone would have to physically be in my room.
I am a lot more careful these days but that is not beyond the pale for a lot of folks haha
It’s different. It’s still two factors if implemented correctly: 1. Possession of the passkey (better if you have a physical token, but passkey on your phone is passable). 2. Knowledge of your password (or bio authentication if you use face id or w/e).
Note you are not giving your password to the website, and if a hacker gets hold of your password they still can’t do anything without your passkey device.
Uh… What password?
Passkey should ask for a password for unlocking. If it doesn’t then it’s not implemented correctly.
It’s client specific and my phone requires whatever can unlock the phone and chrome requires either windows hello or a pin if under linux.
Certain implementations do whatever, and as far as the backend is concerned, there’s no way of knowing, unless you want to get into the business of locking down specific vendor keys…
But I say MFA is overrated versus just getting away from generally crappy password factors. Also passkeys are less phish-able than OTP type solutions.
Yes, it’s implementation specific, in this case your phone, or your browser is the passkey “device”. And as long as it’s protected by some form of authentication it’s OK (though I would recommend a hardware token over phones/browsers). If it doesn’t then you shouldn’t be using that “passkey”. Yes, there is no way for the website you are authenticating with to know whether your passkey is safe or not, choosing a secure passkey implementation is (unfortunately) the user’s job. But it’s the same with more traditional 2FAs, e.g. you can store your TOTP secret securely or insecurely, and the website will have no way to know.
Yeah. Passkeys are something I would love if they were a second factor because they are so much better than any other 2fa. And I use my yubikeys as second factors where I can. But why the hell would I not want a password too?
Passkeys are always supposed to be protected by another layer of authentication. e.g. a password should be required to unlock the passkey. If your passkey don’t do that, stop using it.
If I provide passkey support and still require a password, most users will get annoyed and not bother. If I provide it as a replacement for password, then I can get them onboard more often. I’d rather have them using passkey than sticking with password.