Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I still don't care about any of this nonsense for my personal stuff when I can avoid it. Passwords all day for me. 0 security incidents in my lifetime.

Sucks that Github and some other things force SSH keys which are just passwords except always saved to your disk so that anyone who steals your laptop gets access.

It adds insult to injury when you try to capitulate to this malarkey, generate a key in PuTTy's key generator, then Github whines that the default setting isn't overkill enough and you have to make a whole NEW key with some other setting. I miss the good old days.



> Sucks that Github and some other things force SSH keys which are just passwords except always saved to your disk so that anyone who steals your laptop gets access.

This is the reason to encrypt ssh private keys with a passphrase. If the key is leaked it's still protected by the password.

It's a built-in feature of ssh. For an existing key downloaded from a cloud provider, use ssh-keygen -p to add/change the passphrase.


How hard is it to crack these passwords? Since it's local (unlike the github password) I guess you can run brute force attacks etc at full speed ?


Yes it's local, but also can be taken away to run on a cluster. Looks like ssh-keygen is using 16 rounds of bcrypt_pbkdf. My laptop just took 185ms to try a password. So I guess I could run less than 10 passwords per second (per core?).

I don't keep an ssh key on disk though. I use my gpg key on my hardware security token, which gives you 3 attempts before you have to unblock it with a separate management password, which again you get 3 attempts at before the key is entirely locked.


The longer the better. A memorable sentence is a good place to start.

ssh-agent will cache the passphrase in memory, which helps avoid needing to type in a long phrase repeatedly.

But it's worth saying that if any private key is leaked (passphrase or not), it's time to revoke it and generate a new one.

Having a passphrase in place raises the bar from "key leaked, 3rd party has access to everything" to "key leaked, 3rd party has to now attempt to crack the passphrase". It mitigates a very bad scenario and buys time.


Pass phrase not password. You are going for length to protect from brute force.

Soylent Green is NOT people

Was one of my shorter pass phrases


I'm sceptical about the entropy of easy to remember pass phrases, including negations and simple capitalizations. Even when going for something like "correct horse battery staple", which requires a memorization technique to remember, the space of words we are realistically drawing from when prompted by a shell is probably not that large.


That’s what diceware is for: https://theworld.com/~reinhold/diceware.html


How many times a day did you typ that wrong!


That's going to depend on the length of your password. Longer is more entropy and orders of magnitude more difficult to 'brute force' with each character added.


Yes. This is precisely why passphrases are a bad idea - people tend to use their easy-to-remember default password, which gets compromised along the way if an attacker can get their hands on the key file and throw their full processing power at it.

SSH certificates are a solution to that problem.


What mechanism is used to protect the key of the certificate authority?


That’s a different situation - the CA key resides on some high security server, not a developer laptop that may get stolen or compromised by ordinary usage.


sure, but that's why you're using a password manager that lets you generate 24 character mixed everything random passwords and use them easily, right? Right? Guys?


I miss the good old days before passwords were a thing and everyone just trusted others to behave ;-)

You can secure access to Github (and other places) with hardware keys, e.g. from https://www.yubico.com/.


But you add a password to the key, so it's the same.

And not everyone saves it to disk. My ssh key is my gpg key. It's stored on a yubikey and can't ever leave it. If I do a `git pull` then my yubikey flashes and I have to tap it to allow that connection to happen. Steal my yubikey, well you can't unlock it. Hack my laptop and you can't tap the key.


> I still don't care about any of this nonsense for my personal stuff when I can avoid it. Passwords all day for me. 0 security incidents in my lifetime.

Even for personal stuff, why would you want to use passwords? Keys are more secure AND more convenient. Sure you don't need certificates but I don't understand how keys are more 'nonsensical' than passwords.

Keys have more flexibility, you can use SSH Agent, you can do SSH agent forwarding, etc.

> except always saved to your disk so that anyone who steals your laptop gets access.

This is wrong. First of all, your laptop should have disk encryption. Always. I don't care what your threat model is, encrypt the disk. Second, SSH keys can (and SHOULD) have a passphrase.


Ever don't the math on the amount of time spent entering passwords? I have. Stopped using passwords for personal stuff.

I multiplied by cost per min for downtime in professional support and the cost of typing passwords was more than my yearly wage.


This contains several misconceptions.

Keys are not just "passwords saved to disk". My private keys exist in hardware, on Yubikeys. They aren't on disk. The hardware requires authentication to access.

You're typing your passwords zillions of times. I log in to my system once, authenticate to my HSM once, and I can access many hosts via scripts and automated tools. This is impossible to do securely with password auth.

You're also training yourself to manually input the entirety of your authentication credential multiple times per day (or hour). This is bad practice, as anyone stealing it then has the keys (ha) to your kingdom (and they have way more opportunities to steal it!). Even if you just replace password auth with a password-protected key on disk, and don't use a password-caching agent that holds the decrypted key in ram (as would be typical), so that you're still typing your password each and every authentication, you've raised the bar substantially because someone would need to steal your encrypted key from disk in addition to obtaining your password.

Then there's the issue of cycling credentials, and the mental loads involved. I can cycle my keys without changing my workflow or having to type anything differently.

Passwords are not good authentication tools. Use actual cryptography.


not if you encrypt your ssh keys, which is what everyone I know does - then your potentially weak password requires physical access to exploit while things accessible over the internet can't really be brute forced.

further, this is even more convenient when paired with an ssh-agent that will securely hold your private key in memory and not allow anyone to export that key...you could dump the memory but that would require root access, which again should be password protected


My servers expect an environment variable to be sent too, (new sshd and ssh can do this). This gives basic 2fa without typing anything.


The github change also messed up my workflow, which involves pulling/cloning my company's git repo from lots of machines, many of them being short lived or disposable. Now I have to save the password forced on me in a file because I'm unable to memorize it easily and that made our setup less secure. Thanks github...


Passwords are safe if you can memorize them. It is not too hard in my opinion. I also think they should always be an option for any kind of auth. Maybe I want to authenticate against a system but I don't want others to know my ID. For that use case a password is the better solution.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: