It’s the first idea I had when it came to making sure login on my server is secure. Instead of having a small password that relies on my fallinble memory and may be also guessed in a not-completely-rodiculous amount of time.
Meanwhile a fairly small file, something like a 512 byte “user.key”, to be uploaded along with your username, or even just having your username built-in, seems much safer.
I wanted to do some math but I could only find limited calculators for doing calculations with such big numbers so have the amount of possible combinations the file may have:
256^512
1,044,388,881,413,152,506,691,752,710,716,624,382,579,964,249,047,383,780,384,233,483,283,953,907,971,557,456,848,826,811,934,997,558,340,890,106,714,439,262,837,987,573,438,185,793,607,263,236,087,851,365,277,945,956,976,543,709,998,340,361,590,134,383,718,314,428,070,011,855,946,226,376,318,839,397,712,745,672,334,684,344,586,617,496,807,908,705,803,704,071,284,048,740,118,609,114,467,977,783,598,029,006,686,938,976,881,787,785,946,905,630,190,260,940,599,579,453,432,823,469,303,026,696,443,059,025,015,972,399,867,714,215,541,693,835,559,885,291,486,318,237,914,434,496,734,087,811,872,639,496,475,100,189,041,349,008,417,061,675,093,668,333,850,551,032,972,088,269,550,769,983,616,369,411,933,015,213,796,825,837,188,091,833,656,751,221,318,492,846,368,125,550,225,998,300,412,344,784,862,595,674,492,194,617,023,806,505,913,245,610,825,731,835,380,087,608,622,102,834,270,197,698,202,313,169,017,678,006,675,195,485,079,921,636,419,370,285,375,124,784,014,907,159,135,459,982,790,513,399,611,551,794,271,106,831,134,090,584,272,884,279,791,554,849,782,954,323,534,517,065,223,269,061,394,905,987,693,002,122,963,395,687,782,878,948,440,616,007,412,945,674,919,823,050,571,642,377,154,816,321,380,631,045,902,916,136,926,708,342,856,440,730,447,899,971,901,781,465,763,473,223,850,267,253,059,899,795,996,090,799,469,201,774,624,817,718,449,867,455,659,250,178,329,070,473,119,433,165,550,807,568,221,846,571,746,373,296,884,912,819,520,317,457,002,440,926,616,910,874,148,385,078,411,929,804,522,981,857,338,977,648,103,126,085,903,001,302,413,467,189,726,673,216,491,511,131,602,920,781,738,033,436,090,243,804,708,340,403,154,190,336
What am I missing? I assume I’m missing something, because the idea of something like this going over a lot of smart programmers and developers’ heads does not sound right
If you’re talking about websites, look in to mtls
Another one: The UX on browsers for managing password is far more developed, and the services you selfhost are accessed via a web browser.
This is how ssh works.
I think you are looking for SSH certificates.
I think OP is talking about auth in services that you selfhost.
For example elster.de forces you to sign in by entering a username and uploading a cert file.
But mostbselfhosted services only have username/password logins.
That sounds like aPasskey
It does sound like one, but it isn’t.
Passkey
- Per-service key pair, unique per domain, Identity bound only to that specific account on that site
- Challengeresponse via WebAuthn
- Trust anchored only in the target service (no external CA)
- Private key sealed in OS / secure hardware keystore
Certificate login
- Single global identity usable across many services
- TLS client authentication with certificates
- Trust established via certificate authorities and chain validation
- Private key stored in exportable file or smartcard
Thanks for the explanation!
If a service doesnt offer Oidc, just dont self host it. The SSO service can then be properly secured and even if its only a password, at least its not reused.
Just put everything that doesn’t have OIDC behind forward auth. OIDC is overrated for selfhosting.
That’s what SSH keys are essentially.
Or using a hardware key for physical logins.
Both of those basically make your credentials a small encrypted key file instead of password.
Usernames and passwords really only exist as a “convenience”……both for lazy users and bad actors.
Congratulations, now your „password” (the 512-byte random key file) is stored as plaintext on your machine :)
With rate-limiting, non-trivial passwords are not viable to be brute-forced, so making them larger just doesn’t give you much.
If this is inside the threat model, you put a passphrase on that key and load it in an external process like ssh-agent or gpg-agent. Maybe even move it to a separate physical device like HSMs or crypto hardware wallets (many of which can be used for this purpose btw).
This is also neat: https://doc.qubes-os.org/en/latest/user/security-in-qubes/split-gpg-2.html#notes-about-split-gpg-2
I’m an admin and using an SSH key is the most common way we log into servers.
Also the most common way I log in to self-hosted servers.
SSH keys are so nice
I’ve got mine hooked into my password manager so it’s as easy as scanning my fingerprint to use (password manager locks on sleep and after a timeout).
What do you do when you need to change your fingerprints?
I have 9 backups.
I keep silicon based backup fingerprints in my lockbox at the credit union.
- You need the file everywhere. So when lunch time on work I can’t login, it is not my computer but the company machine. Yes, i have my smartphone with me I dont want to send that file to work.
- Easier with password. Easy to setup and to reuse a long password that you already have.
- My ssh server is not reachable easily. Ip restrictions goes a long way and Wireguard is good.
- Congratulations, now your work computer has access to the password (you are not as guillible to think work computer is not recording everything for the stakeholders, are you?)
mTLS (mutual TLS) is actually quite common out there. And SSH certificates moreso than public keys.
So clients get issued certificates that they can authenticate with. TLS for HTTPS but both ways. It sounds like this is what you’re asking about?
You can (and should) just use a password manager to generate and store ~64 byte keys which have roughly the same amount of security.
I have no servers that accept external password-login. All use SSH keys.
If you mean the apps you run on the servers, many can use an OAUTH server that you then host for SSO.
I think because there are ways to protect your entire systems with cryptographic keys - there’s no need for individual applications to do that themselves. You can either only make your network accessible via an SSH tunnel (which would then use SSH-Keys), use a VPN or use mTLS which would require you to install a cert into your browsers key storage.
There’s many good solutions to this problem - no need for individual applications to do it themselves.
As others have mentioned there are ssh keys and generally you can and should of course use a password manager.
However there is IMHO a huge blindspot of people using only SSH keys to long in, and that is that your day-to-day dev PC is actually more likely to be compromised in some way than the server that only runs specific, relatively well defined applications and overall just has less attack surface. And the ssh keys on your dev PC are really not very securely stored and thus quite easily compromised.
Hardware keys are of course a better solution, but I would personally recommend to use a 2FA solution that prevents access even when one factor (ssh keys or passwords) is compromised.
Passphrase-protected SSH keys are definetely more secure than passwords.
It’s a pain to manage. If you want to change it, you have to go to each server and update it manually, if you don’t already have automation. If you do have automation, that’s another thing you have to set up and manage. And all that for not much gain.
Not if you use certificates signed by your own internal CA and trust the CA instead of straight up trusting the public keys explicitly.
This way you can generate new SSH or TLS keys trusted across a bunch of machines without having to touch those machines directly for every key, since they are signed by your trusted authority. If you configure CRLs properly you can also revoke them centrally.
If you do have automation, that’s another thing you have to set up and manage.
Hosting a CA is a whole additional service to set up, as is enabling trust for said CA on every server you’re running.
Check out TLS client certificates.
