this post was submitted on 16 Sep 2025
699 points (97.8% liked)
Programmer Humor
26400 readers
1353 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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
Also, what happens if your device with the passkey fails?
Like the drive craps out?
You are supposed to have two redundant ones. Hooked up to every service. One leaves the house with you, the other stays in a safe, and you rotate them periodically
and nobody is gonna fucking do that lol
Mine are USB-A and USB-C so no two computers can use both. One of them randomly quit working (something in the OS dropped support for it maybe?) but then I think started working again?
At an old job I had a lot of control over my own infra and I used my HSM to log in to my forge. I haven't used it daily in years now.
Similar problem with 2FA though
Under passkey implementations, you need to unlock the passkey device with biometrics or passwords. Something you are/know (biometrics/passwords) and something you have (passkey).
It's not impossible to screw it up. Put your passkeys in bitwarden, reuse a password and don't 2fa that.
My workplace doesn't allow Bitwarden because 'it's not secure'.
It's easy enough to enforce 2FA on it.
Most of the other online solutions are about the same.
That sort of thing is the push I need to get entirely off of Github
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.but they require chmod 400 and they're ideally in on an encrypted disk
So the desk drawer is locked and the codes are Luks encrypted.
And for critical stuff, you should also have a password on the key.
If your ssh keys are like a passwords on paper in a drawer, you're doing it wrong.
TIL some people store SSH keys unencrypted
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:
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 have
At the end of .bashrc and
In .ssh/config so that it auto-adds keys I unlock.
I do it.
Every time.
And I keep a wired keyboard for it.
Get a load of Ross Ulbricht ovah here!
Well, the main reason I do it every time is because I'm just too lazy to setup
pinentry.But yeah, for the Bluetooth keyboard, I realise I better get off it.
https://www.tomshardware.com/tech-industry/cyber-security/researchers-snoop-data-from-air-gapped-pcs-ram-sticks-by-monitoring-em-radiation-from-23-feet-away
I get keyboards probably have more range, but i worry privacy was gone a long time ago.
I see they really wanted to fit the acronym to RAMBO, lol.
But it makes sense. Considering, we keep out mobile phones in around a metre's reach, it would be trivial to just get that information just from key sounds. Guess I better get one of those high frequency faraday cages, huh?
There are a few on audio, I saw one where they read HDMI over the air from 60 ft away.
I'd kinda like to see Bluetooth shored up a bit maybe require a tap to bind every day.
Wow! Was that stuff even EMCD compliant?
You can read the cables, you can read the transceivers in the video card, in a lot of the screens you can even read the panel changing itself.
Our ability is to remote sense EMF is absolutely ridiculous these days.
Then there's crap like the espionage where they change fan speeds. Or flash an infrared proximity sensor on a cell phone to exfiltrate data.
I thought that stuff went away with CRTs.
But I guess that makes sense. We could hear CRTs with out ears, now we just need more sensitive equipment.
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 not about encryption/security it’s about creating something that can’t be phished.
We know that 2fa is secure. But if an attacker can trick you into giving them the code, or typing it in a fake box. Then they own you.
Passkeys are made so that there’s nothing to give, nothing to type. You must control the device.
SSH keys are more like passkeys than passwords.
I’d love to see the state of online banking if everyone were to manage their own ssh keys
In all seriousness, they are similar, but not quite in this context.
There’s a good project on how to make ssh key infra more scalable and innately secure. Then you can use passkeys on top if you’d like.
https://github.com/openpubkey/openpubkey
https://github.com/openpubkey/opkssh
I personally use this on all my servers.
Most people couldn't figure out how to download a binary release from a GitHub repo, much less clone it, regardless of HTTP or SSH.
True, not the point though
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.
In practice, they use Face ID, which has privacy implications.
In practice, they either use system authentication if you use the implementation bundled with iOS/Android - and sure, that can be Face ID if setup, or other forms of biometric authentication. Both operating systems have APIs that allow password managers to provide their own implementation of passkeys, and in that case you have to authenticate with your password manager - sure most of them support using system authentication (biometrics) as well, but this could also be a master password or hardware key (which work very similar to passkeys by the way).
I'd argue if you don't assume that whatever system you're using is reasonably secure/private, you probably shouldn't enter any passwords on that system either. This isn't a passkeys vs. passwords problem.
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.
No phishing
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.
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.
It's still more secure than password+sms/email
Barely.