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
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.
This is how ssh works.
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 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
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 askimg about?
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 with one of the many passwordless methods, which includes: entering a username and uploading a cert file.
But most selfhosted services only have username/password logins (if any).
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 sounds like a Passkey
It does sound like one, but it isn’t. Ignoring the differences in UX:
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
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.
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.
After that I have to resort to crime and cryogenics.
I keep silicon based backup fingerprints in my lockbox at the credit union.
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.
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.
I believe this is what WebAuth Passkeys are.
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.
A CA can be an encrypted volume on a live USB stick. It’s mostly for the CRLs you might want something online. A static HTTP server where you manually dump revocations is enough for that.
Unless you do TOFU (which some do and btw how often do you actually verify the github.com ssh fingerprint when connecting from a new host?), you need to add the trust root in some way, just as with any other method discussed. But that’s no more work than doing the same with individual host keys.
And what’s the alternative? Are you saying it’s less painful to log in and manually change passwords for every single server/service when you need to rotate?
Check out TLS client certificates.
