7 ms·
From my experince as an attacker -- - Is it better to use a different passphrase on each key, or does using the same one not matter much? - How much less
by dsl 10y ago
From my experince as an attacker --
- Is it better to use a different passphrase on each key, or does using the same one not matter much?
- How much less secure is it to not use a passphrase on a key?
- Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?
None of these things really matter that much. Make sure you use full disk encryption and never stand up from your machine without locking it, and make sure you keep your local machine patched. If I get code execution on your machine, I am going to use whatever keys are loaded in your ssh-agent to pivot, hijack your existing open sessions, or modify your ssh client to dump the keys I need.
- Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?
Key length is a protection against the future, and against state level actors. Right now, key length doesn't matter much to me because I'm more focused on just stealing your keys from you regardless of length.
- berdario 10y agoIndeed, I have FDE enabled and a passphrase, but I reckon that the passphrase is not buying me much. OTOH, it's defense in depth, and there are some vulnerabilities which could allow to exfiltrate keys without non-sandboxed-RCE https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/ https://blog.mozilla.org/security/2015/08/06/firefox-exploit... I reckon that a passphrase protected key would be safe from this attack (modulo offline brute-forcing)
- regecks 10y ago> OTOH, it's defense in depth Yup. IMO not using a passphrase is nuts, considering there is practically no convenience loss (ssh-agent, OS X keychain, pageant) and fairly significant benefit. Protects against: - accidentally exposing the private key (it happens, accidental wildcard in the shell), and - attacks that aren't after your keys specifically, e.g. your home directory gets stolen.
- eropple 10y agoIn general I agree with you, with the caveat that there are a number of products that don't give a toss about security (lookin' at you, Hashicorp) that actually and unironically require you to have your keys unencrypted on disk. I have since discarded these products (and others should too), but they do exist.
- carlesfe 10y agoNobody seemed to answer this question, and neither did the original blog post (besides "trust me and do it"), so maybe you can shed more light on the main point: Why are ED25519 keys better than RSA, how compatible are they with different systems, and are they worth the hassle and risk of generating and using a new one?
- arca_vorago 10y agoED25519 keys are cryptographically more secure, and are more politically secure if you want to call it that due to the undermining of NIST the NSA was/is doing. (plus it comes from djb, all hail djb!) OpenSSH already has support built in, as does Mosh, and therefore, I do think it's worth it. I do sometimes disagree with using keys though, despite everyone pushing it so hard, there are cases where I think passwords are the way to go, but thats a long post for another time. Also, I really like usin pam auth mods, such as yubikeys or google auth for two factor. That combined with regular hardening, and yes Ill admit it, non standard ports (reduces log alert fatique) does a pretty good job.
- effie 10y ago> I do sometimes disagree with using keys though That sounds interesting, could you elaborate on that?
- lisper 10y ago> Why are ED25519 keys better than RSA Two reasons: 1) they are a lot shorter for the same level of security and 2) any random number can be an Ed25519 key. To generate an RSA you have to generate two large random primes, and the code that does this is complicated an so can more easily be (and in the past has been) compromised to generate weak keys.
- carlesfe 10y agoIf I understood it correctly, you're saying that RSA requires the two numbers to be big AND random, otherwise the algorithm isn't strong? Therefore Ed25519 is better because it's strong regardless of the key? What I don't get then is how can a short key be secure, that goes against what I was taught in college. Aren't shorter keys more prone to collisions and bruteforce attacks?
- maquetaurie 10y agoIn your experience what difference does full disk encryption vs home encryption have in this context? We've been debating this a lot at work.
- spydum 10y agoFDE leaves very few if any opportunities for accidentally spilling cleartext secrets onto the disk. If by home encryption, I assume you mean some encrypted container (or encrypted document). Consider what you "DO" with the decrypted contents.. often you are copying them out to perform some action (authentication, etc).. Are you certain the apps you use and your clipboard won't be paged to disk temporarily? If secrets are in memory, then get paged to disk, is your swap encrypted? It is more likely you are still protected if using FDE (depends on your setup). All that being said, thats a certain level of paranoia which i dont think is productive.. but perhaps for targets of the state or what have you, I'd rather not chance it.
- michaelt 10y agoThe default encryption on Ubuntu, if you select 'Encrypt my home folder' during setup, uses ecryptfs on your home folder, and cryptswap for swap. For some reason, /tmp/ isn't encrypted by default as far as I can tell. AFAIK the main benefit is: if you want to run a multi-user or headless system, you need the network stack brought up before a password is entered - which home directory encryption provides and FDE can't.
- majewsky 10y ago> For some reason, /tmp/ isn't encrypted by default as far as I can tell. It does not give any extra benefit because tmpfs only resides in RAM, and disk encryption typically only concerns data at rest. If you come to a point where you want to have /tmp/ encrypted, you would rather encrypt the whole RAM. (Does anyone actually do that?)
- ytjohn 10y agoI think in this case, "home" encryption is what I use. Most Linux systems when you install will offer to encrypt your home folder. When you login, your password unlocks a key which ecryptfs uses to virtually mount a directory filled with encrypted files to be your home directory. As long as you are logged in, the home directory contents are available (transparently). When you logout, the virtual mount is destroyed, leaving behind only the encrypted files. To put it in perspective, if you were logged out completely and tried to login remotely, you would be forced to use a password login initially. If it was more like my desktop where I'm logged in and the screen in locked, the home folder is unlocked, so I can remotely ssh in using just my keys.