SSH Keys - Public Keys Authentication Issues

SSH Keys - Public Keys Authentication Issues

by Hanz Makmur September, 26, 2016

 
With the latest role out of CentOS/Ubuntu on our public machines since Fall 2015, public keys authentication has been disabled for All CS public resources because of issue with private key security.

The main issue here is that the world has changed and username and password are not enough. When large company with big budget security teams can loose private info like Goldman Sachs and Half a Billion Yahoo password breached, we need to move to stronger authentication instead of making it weaker. Essentially, people use private key to avoid using password which lead them to remove passphrase from SSH Key. This resulted in private key without password (passwordless private key), and not to mention many issues with weak keys of which the corresponding private keys could be easily recovered even if they are protected by password.

Private keys are stored in end user's computer where likely hood of malware infections is very high. If users don't put password on their private key when that private key is compromised, the entire system is ompromised easily. When combined with mistakes on mailto:?attach function, which is making it easier for people to steal one's private keys, we can end up in a total disaster when stolen keys is used to login to all the system easily.

With today security issues, we are going the opposite direction where multi factor authentication is recommended. This means after password is entered another pin, token or keys must be supplied to get access. Instead of zero key, now at least 2 keys are required.

The problem with security is that easy access for a user also means easy access for the bad guys. Since our security is as strong as its weakest link, we have to make hard choices between easy or secure. To raise it on another level, there were also discussion to allow Rutgers access only for all our machines and requiring VPN to access our resources. So far we have not gone this way but I doubt they will stay world accessible for long.

All users of CS CentOS/Ubuntu machines now can enable and is encouraged to use Google authenticator to ensure better security on their Linux account. University is also enabling NetID+ which is two factor authentication using Duo Security for all Faculty and Staff and centralizing all Web services authentication using Central Authentication System (CAS).

To enforce more security, University as a whole is centralizing all email for faculty and staff as part of University Strategic Plan. No more ad-hoc email servers anywhere at university. All faculty and staff MUST use Rutgers Connect email system and can not use any other system including Scarletmail for their email.

To be able to read email from mobile devices, All mobile devices regardless who own it, must enroll in mobile device management system where university requires all mobile devices to be locked with password and must be able to wipe your phone remotely along with other privacy info you must surrender to university.

It's interesting world we live in today, Education environment is now treated as corporate environment for security reason. Many of our faculty and staff are not happy with many changes but the order comes straight from the top and understandably so.

The lesson here is, security is important. We certainly can't afford any data lost and get publicized in the news that we get data breached like what happen recently to UC Berkeley. I think DDOS lesson from last 2 years awoken many people at Rutgers that heads will role if such event ever took place. Thus we are in a new "Better safe than sorry at any cost" era. I suspect it will cost more to clean up than to prevent data lost so expect more security changes happening.

Further Reading

  • SANS Security
  • Kreb On Security
  • SecuriTeam