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
Have you heard of ssh keys?
Barely, I’ve had to set one up for GitHub but I haven’t fully figured out what they are and what they do
ssh is a protocol that is used to log in to a computer remotely. Servers are usually administrated not by plugging a keyboard and monitor into the server, but from another machine via ssh. You can configure ssh to allow login with the same username+password you would use locally, but it is common practice to only allow authentication with an ssh key.
ssh keys allow for much higher entropy like you suggested. They are also asymmetric, and the private key can be password-protected or stored on a smartcard.
If you’re talking about websites, look in to mtls
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.
You can (and should) just use a password manager to generate and store ~64 byte keys which have roughly the same amount of security.
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
Check out TLS client certificates.
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 OATH server that you then host for SSO.
Another one: The UX on browsers for managing password is far more developed, and the services you selfhost are accessed via a web browser.
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).
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
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.
Yep which is why I use oauth2-proxy between these services and casdoor.
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.
- 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?)
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.
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 keep silicon based backup fingerprints in my lockbox at the credit union.
I have 9 backups.
After that I have to resort to crime and cryogenics.
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.
I believe this is what WebAuth Passkeys are.
