Rendered at 21:45:54 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Grombobulous 2 hours ago [-]
I wished for the article to tell us how to set it up at least from a bi high level.
I also think SSH certificate authentication mostly solves the “key comes from anywhere” problem by automatically expiring certificates.
This isn’t as immune to this type of attack as Secure Enclave, but you do get a benefit where the user has to get the correct certificate periodically in order to maintain access.
If I pass my credentials and certificates to someone else or someone steals them, they’ll eventually expire.
The impracticalities of Secure Enclave are obvious to all of us: recent Apple devices only.
analog_daddy 26 minutes ago [-]
Not sure if this completely helps with the full setup aspect, however, I got introduced to secure enclave when i was researching a git app for iOS. The following app has, as one of its paid features that you can utilize secure enclave. Pretty cool app and pretty cool technology!
https://workingcopy.app/
The setup was a breeze! Did not try it with a server yet, but i don’t think anything would be radically different.
Bender 4 hours ago [-]
A copied key works from anywhere, silently. There's no "is the real owner here right now?" check.
The server can have restrictions on where SSH keys are valid from. Furthermore the server side public SSH keys can be moved under /etc/ssh/keys so they are harder to tamper with vs a users .ssh dir in $HOME. This can significantly reduce the blast radius of a leaked key. Furthermore the server side file should be set immutable and read-only and something like Tripwire or OSSEC should be monitoring for changes to anything in /etc. Additionally one can limit access to SSH over a VPN such as Wireguard unless this is a public SFTP server.
now imagine they move these to physical devices. It gets much worse, but there really arn't any super secure means to secure, identify and prevent impersonation and unwarranted access.
Likely, sufficiently complex passwords will continue to be the frontline defense.
I also think SSH certificate authentication mostly solves the “key comes from anywhere” problem by automatically expiring certificates.
This isn’t as immune to this type of attack as Secure Enclave, but you do get a benefit where the user has to get the correct certificate periodically in order to maintain access.
If I pass my credentials and certificates to someone else or someone steals them, they’ll eventually expire.
The impracticalities of Secure Enclave are obvious to all of us: recent Apple devices only.
The setup was a breeze! Did not try it with a server yet, but i don’t think anything would be radically different.
The server can have restrictions on where SSH keys are valid from. Furthermore the server side public SSH keys can be moved under /etc/ssh/keys so they are harder to tamper with vs a users .ssh dir in $HOME. This can significantly reduce the blast radius of a leaked key. Furthermore the server side file should be set immutable and read-only and something like Tripwire or OSSEC should be monitoring for changes to anything in /etc. Additionally one can limit access to SSH over a VPN such as Wireguard unless this is a public SFTP server.
Likely, sufficiently complex passwords will continue to be the frontline defense.