Hacker News Reader

Comment by pja | Hacker News Reader

Rate limiting on password logins ought to be the default, not some optional extra that only the security savvy know to install.

Defaults matter: not implementing rate limiting by default in sshd has left an open door for these people to walk through & attack the net. Sure, you can blame people for choosing poor passwords but, given the reality of the millions of machines out there, as programmers we know that some of them will have poor passwords because people are people. Failing to code with that expectation in mind is doing our users a disservice.

View on HN

Totally agree with your sentiment but in this case I don't see how rate limiting helps, or at least not much.

If you're building a botnet you don't need to crack any specific machine so you can distribute your attempts across more hosts. Eg. rather than hitting one machines with 1,000 pwords/sec you target 1,000 machines at 1 pword/sec each (or whatever rate you're limited too). There's no shortage of badly configured routers.

The number of people that have more than 10 machines at their disposal is much smaller and would have stayed much smaller if it weren't for this poor default in the first place.

I'd go further and just argue that password based login should do a password strength calculation by default and estimate how long it will take you to get cracked.

"You've entered the password this machine will be cracked in roughly 5 days. Would you like to set a different password? (n / Y)"

I agree that defaults are crucial, but it's weak passwords not rate limiting which is the fundamental issue here. Rate limiting doesn't help if you get in with the first try of admin:admin. Passwords should be generated from a secure random source and specified on a label on the device.

I agree with both of your arguments. From my experience ethically cracking accounts, rate limiting, non-default usernames, and non-default passwords should be the #1 priority for Michelle Obama or the next first man/lady. It is a very serious problem.

replying to my own post. Exhibit A.

http://money.cnn.com/2015/09/30/technology/china-opm-hack-us...

One of the first things I was taught in network security was

"When installing SSH always set it to key based login only NO Password login allowed"

Passwords are not to be used here they can be broken by automated distributed attacks, strong cryptographic keys won't.

A lot of things can read ssh key files, including, sometimes, internet ads: http://www.zdnet.com/article/mozilla-urges-users-to-update-f...

Passwords can't really be gotten that easily.

Which is, among other reasons, why you encrypt your key with a passphrase.

Why not just use the passphrase in the first place? Or do you think an offline attack on a key passphrase is going to be more difficult than an online attack to a server with rate limiting configured?

2 simple lines in /etc/ssh/sshd_config fix the problem:

  PermitRootLogin no
  PasswordAuthentication no

I know I am preaching to the choir, but ANY login for any port or protocol should have rate limiting and non-default passwords.

Burp suite can easily crack web logins if you allow hundreds of logins per second for a single user.

I always set up two things on all the servers that I am in charge of: fail2ban and disabling ssh password logins. There are still people who insist on having passwords and using them to access remote hosts, but thankfully there are fewer every year.

I also used to run http://www.symantec.com/connect/articles/slow-down-internet-... on some of my hosts. It was fun for a while but caused me to have one too many lockouts.

IMHO: keys should be the default. Password only used on a factory-reset device, and only usable to set a login key. Period.

To make matters worse, the debian openssh .deb, that i installed to get the client, configured an autostart for sshd, without asking.

Debian's policy is that if you install a service, you intend for it to run by default. Since services aren't installed by default, this is a fairly defensible position, though it's been commented on many times.

It's possible and fairly straightforward to disable autostart of services through either old-school SysV init or, I suspect, systemd.

Upshot: running complex systems isn't entirely trivial.

Yes, a desktop computer is a complex system, that's why I leave these not entirely trivial plumbings to the system programmers. The downside of this is the exploited systems that potentially everyone has to suffer.

This story doesn't check out; I don't see a package named "openssh" (on Jessie), but there is a package "openssh-client" which only installs the client.

But regardless, starting sshd on installation shouldn't matter because proper passwords and firewall should be the first step.

Welp, the metapackage's just called ssh, which is also the name of the command the client provides. Another case of "only two problems in computer science ..."

Due diligence on my part was lacking, agreed.

Rate limiting on everything should be a default.

Why doesn't Linux do it by default, by the way? It wouldn't hurt desktop Linux either.

It does. PAM (which is a central piece of software handling authentication on Linux) makes you wait 1 second after each failed attempt.

Reply on news.ycombinator.com