[freehunter]

"Common knowledge" is a big problem in the security industry, like you mentioned. It's common knowledge that you need a 32 character randomly generated password with special characters and numbers and mixed case, right? But actually that's less secure, and now security folks have to work overtime to convince people otherwise.

And it's common knowledge that passwords are super insecure and should be replaced, but oftentimes the people replacing them don't understand that it's possible to replace passwords with a less secure system, and don't have the skills necessary to judge that risk.

Key-based systems do have their risks. If I compromise your dev machine (probably using a simple password), I now have free access to all the machines your key unlocks.

Defense-in-depth is important, as well as a strong IAM system. You need physical security to protect your dev workstation, coupled with a strong login system to your machine, hopefully a VPN (locked with a physical token) or local network requirement to get onto your production servers, and then break-the-glass methods to check out permission to escalate your privileges when needed, followed with a keylogger for your admin session and attestation that your break-the-glass in production was necessary.

That being said, if you're looking for a replacement for logging into your production machines over the Internet with a simple password... key-based authentication is lightyears ahead of what you're doing. Passwords are far too easy to guess or brute force.

[briffle]

the part that gets me is that key based authentication is much, much more secure, as long as you have a passphrase. How many 'howtos' and other sites on the internet say to just create a key with no passphrase? Its right up there with the number of guides I see for deploying things on Redhat, that first have you disable selinux.

[freehunter]

Yeah as someone who works in the security industry, the ubiquity of security awareness targeted at end users is both a blessing and a curse. It's a blessing because now many more people know what key-based authentication is. It's a curse because now people get mad when my report has a finding that their no-passcode single key authentication system is worse than the "use your RSA token to check out the constantly-revolving root password" system they just replaced.

Like when people use the phrase "two-factor authentication" without knowing what the three factors actually are and why they matter.

[icebraining]

If you compromise my dev machine, you'll install a keylogger and sniff all my passwords. The only way I see that even passphrase-less keys are worse than passwords is if I physically lose the machine (and don't use full disk encryption).

[anfilt]

I am sorry but your example of 32 character password chosen at random is not less secure to brute force. There are 95 type-able characters on qwerty keyboard. That's 95^32 possible possible passwords or about 2^210. Compare that to an AES-128 key. That's only 2^128 possible keys. So a truly random password of such length is harder to brute force than AES-128.

The real reason is passwords are weaker is first and fore most people. People reuse passwords or choose ones that are too short or simple that brute force becomes possible. If passwords where chosen at random and of proper of length they can be equally as strong as a key. Further, passwords basically functions the same as a key symmetric cryptography. People just don't like to memorize long random strings. (Although many apply key stretching since passwords may be of lower entropy).

Second when it comes HTTP it really only supports basic and digest authentication which is based on MD5, and further is susceptible to offline brute force attacks, and a down grade attacks to basic without TLS.

Thusly, most websites just send your password over TLS. However, because each site basically can handle passwords however they want they can store them in plain text. Secondly, if your TLS sessions is compromised you sent the password over over that connection it can be compromised. Sadly, the browsers don't support J-PAKE which by the way has an RFC.

https://en.wikipedia.org/wiki/Password_Authenticated_Key_Exc...

I guess my point is password authentication can be just as secure, and really they are just shared secret crypto-systems. Problem is people choose low entropy passwords first and foremost. So just generating a key and saving locally avoids that issue.

Websites (HTTP) can use client X509 side certs as authentication and this gets rid users choosing bad passwords. However, if browsers implemented J-PAKE you don't have to worry about accidentally visiting the site via plain text will comprise your password or a comprised certificate authority. You could always validate the certificate yourself since we don't have something like J-PAKE in place.

For SSH long passwords can be just as strong, but you must verify the fingerprint matches your servers else you may get MITMed. Although if people see a server with SSH using password logins. They may try to brute force the password which may be annoying for the system admin. So the system admin enables key based authentication stop people from trying. Even though you have a high entropy password and your not worried about a brute force attack. The attacker does not know that so they will try anyways.