7 ms·
I wrote this; happy to answer questions.
by lvh 8y ago
I wrote this; happy to answer questions.
- pvg 8y agoBeside compatibility, is there any reason not to use Ed25519 keys for everything?
- tptacek 8y agoNo, you should use Ed25519 keys wherever you can.
- lvh 8y agoNope! Ed25519 is great and honestly I think the compatibility concerns are overblown. It was introduced in 2014. If you are running four year old SSH you have other problems, like probably RHEL or some nonsense. That said: Ed25519 is a local optimum: the bigger win is to not have long-held credentials at all, and instead use an SSH CA or something like Gravitational Teleport. Doesn't work for GitHub though.
- jakobdabo 8y agoRHEL 7 (and derivatives) do support Ed25519 keys.
- glenjamin 8y agoIn a world where you don’t have long held credentials - how do you get the short term credentials?
- guelo 8y agoYou could have a key rotation process where you use the old key to install the new key and delete the old key. But it seems sketchy because if you don't rotate in time the old key expires and you're locked out. I think in practice you'll always end up with a super-duper secret, rarely used, long term key. Or have some other backdoor like root password, LDAP/Kerberos, ADFS, etc.
- cbhl 8y agoIf I understand correctly: with long-held credentials. Basically, you use long-held credentials to generate short-term credentials, and then use the short-term credentials themselves to access whatever server or service you need.
- deleted 8y ago[deleted]
- xyzzy123 8y agoWe do this: Master user records in an identity/SSO system. We use ADFS. Use a protocol which provides a portable “signed”, temporary credential. We use SAML but OIDC also works. Have a command-line client which auths to the SSO and then relays an identity proof to a trusted component (lambda, cloud function, dedicated instance, whatever your policy says is ok). The identity proof is just a saml assertion or oidc token. Have trusted component validate the identity proof from SSO and generate time limited credentials (we issue ssh, kube and iam). Our client then auto-xfers those creds up to jumpbox but you could drop them on workstation instead if your policy allows.
- tptacek 8y agoThis is roughly what I'm talking about when I bring up SSH CA short-lived credential workflows.
- wvh 8y agoI currently work in academic environments and I don't have much faith in the SSO systems. I thought about this, but often the SSO credentials are also the email password – the one password that gets entered and stored just about everywhere for the average user. I'm not willing to bet the security on a user's main login/email password, which seems to be a common setup. With that password or even just access to a user's main mailbox, a smart attacker might get through multiple layers of security by simply convincing services or staff to reset credentials. Though it might work with a second, more limited (not-so-)SSO system for specific users and environments.
- lvh 8y agoYou're right that shitty systems train users to be phishable -- by typing their password all over the place -- all the time, not even counting the poor default password hygiene most users have. This is one of the reasons U2F/WebAuthn is so incredibly valuable.
- amaccuish 8y agoI love SAML (not the XML part), it gives me one place where I can concentrate. My SSO first tries kerberos (if they've logged into their Windows machine using AD), x509 for smartcards, and if all that fails, username+password+totp. Password login is blocked without a TOTP token provisioned. Also it's one place I can stick fail2ban rules.
- leonlag 8y agoThe only thing I can think of is that no smartcard/usb-key that I know of support them. Please if someone knows of any, let me know.
- wahern 8y agoI think some OpenPGP smartcards like the GnuK might support it, but no PIV mode cards AFAIK. And I don't know if the components higher up the stack (gpg-agent, ssh-agent, PKCS#11 drivers, etc) can make use of those keys. Each new key type requires protocol support up and down the stack.
- amaccuish 8y agoThe OpenPGP 3.3 card has ECC but not Ed25519 :( FYI it supports [0]: ansix9p256r1, ansix9p384r1, ansix9p521r1 and brainpoolP256r1, brainpoolP384r1, brainpoolP512r1 [0] https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.3.pdf https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3...
- garmaine 8y agoYes, Ed25519/Curve25519 has weird cryptographic choices that make it difficult to do certain things. I wouldn't use it for anything other than the specific use case it was designed for: key agreement and single signature authorization/verification.
- tatersolid 8y agoElaborate? I thought Ed25519 was a general deterministic signature scheme, and Curve25519 a general key agreement scheme.
- garmaine 8y agoAnd yet people have used it for ring signature authorization schemes (CryptoNote/Monero) which has directly led to inflation bugs (permitted double-spends) and an inability to have key derivation for secure long lived wallets. That’s due to Curve25519 having a non-unit co factor. There’s a half dozen other weird properties of the curve chosen for smal efficiency gains or whatnot which also might lead to security holes in any application which is not the single signer or 2 party key agreement use case.
- wazoox 8y agoMay I suggest that you change your blog colors? Light grey on dark beige is close to unreadable at any size without resorting to Firefox reading mode...
- jwilk 8y agoWhy the .singles TLD?
- lvh 8y ago‘tqbf is responsible for that one :)
- maerF0x0 8y agoAm I correct in my understanding that the vulnerability depends firstly on the leaking of the private RSA key? (as a rogue NPM module could do...) How can I tell if my file is vulnerable once leaked?
- lvh 8y agoYep; this is an attack on the password-encrypted file. You can't tell if it's leaked or not unless osmeone starts using it. You can tell if it's in the safe format right now by looking at the first few lines of the file.
- angry_octet 8y agoDid you use a simple password? It's vulnerable. If its semi-hard, and if you can't easily roll the key, try to crack it. Unless the attacker is targeting you specifically, they will give up after $x of cracking. Switch to the newer format, roll your keys regularly, improve your logging, honeypot with the old keys, put AppArmor/SELinux controls on the .ssh directory.
- ascar 8y agoCould you maybe elaborate why this would make attacks better than pw brute-force feasible? I get that this isn't a good practice, but plain brute-forcing a 20 character pw (~120 bits of entropy as alphanumeric, same as md5 hash size) is still impracticle even if it's a low cost md5 calculation.
- lvh 8y agoI’m not sure I understand the question: most places where you try a password you don’t get an offline MD5-speed oracle. So two ways: it’s faster than say cracking a PBKDF2 dump, and it’s offline, unlike, I dunno, a web password prompt. You’re right that you can imagine passwords that you still can’t enumerate. But suggesting that people have a non-reused memorized 120 bit password is, uh, optimistic.
- Dylan16807 8y agoThe chances are a lot better among the list of people that actually use SSH keys. And this should be one of the top priority passwords, so it's not too hard to imagine it being in a password manager or using a similar quality.
- pvg 8y agoOr it's just their local password with keychain-integrated ssh-agent so they never type anything. I think the chances of that (which is sort of the premise of this post) are much, much higher.
- lvh 8y agoI'm not saying it is literally impossible for this to be safe. I'm saying in pratcie, most of the time, it is not. A 120 bit password is not normal.
- Dylan16807 8y agoA password manager is not 'normal' but it's common enough that you shouldn't be classifying it as negligible to conclude that these passwords are worse than nothing. Also the 120 bits was an example and a good amount more than necessary. A 12 character password isn't exactly standard but it's not ridiculous to expect. Once you exclude the passwords that are so bad even bcrypt can't save them, the number of users where the password algorithm makes a difference starts to look a lot smaller than 100%.