User Security

From Security Wiki
Jump to navigationJump to search

SDSC's User Security Guidelines The following are recommended guidelines for securing your account from unauthorized access. Following these guidelines will not guarantee your account will not be compromised, but are useful in reducing your risk.


  • Your passwords in one administrative domain (your home site) should be different than your password at other administrative demands including different administrative domains within your own organization. Also, for passwords at the different administrative domains, do not use easy permutations of the original passwords.

Pick passwords that are not easily guessed by password guessing programs like "crack". We recommend the passphrase be 8 characters or longer with mixed case and at least one special character ($, %, ^, etc.). This should be implemented at the program that let's you pick the password, if possible.

  • DO NOT set your password to a previously used password. Having password history implemented by your sysadmin is recommended, if possible.
  • If you use a home computer or laptop, use two factor authentication for logging in to a remote computer. One way to do this is to create ssh keys with a passphrase. It is recommend the passphrase be 8 characters or longer with mixed case and at least one special character ($, %, ^, etc.).

DO NOT make this password the same as any other of your SDSC passwords.

Two factor authentication is something you know (the passphrase) and something you have (the private key you generated). The private key should be protected and not be distributed to any other machine except the laptop or home computer. If you believe the keys have been compromised, generate new keys.

THE ABOVE DOES NOT APPLY TO READING YOUR EMAIL. Just remote login to resources using Secure Shell (ssh).

  • DO NOT use ssh keys with no password. The ssh key generation mechanism allows you to set the passphrase to an empty string. This allows logins with only one factor authentication (the private key). This is not strong authentication and should be avoided at all costs.
  • DO NOT put your password in any file to automate some login process. We have seen users use tools like "expect" and put their username and password in a readable shell script or perl program. This is highly discouraged and in the opinion of many security professionals, including SDSC Security Technologies group, having this constitutes a compromised account.
  • DO NOT send any password in unencrypted email. Bad people can be reading your email with stolen passwords or network sniffing tools.
  • Be alert in using any utility at other sites that obtains your username and password in order to access SDSC resources.

A known intruder behaviour was to compromise a computer and install a trojaned Secure Shell client at a number of sites where collaborative relationships exist. Capturing usernames and passwords can lead to user account compromises onto new hosts for the intruder and to possible host compromises.

  • When logged into computers at other sites, IF POSSIBLE, do not use Secure Shell client commands (scp, sftp, etc.) from these sites to your home site. The risk here is other sites may have a trojaned ssh client that can steal your home site password. IF POSSIBLE, it is much more desirable, to perform the function from your home site (a known site) to the external site, ESPECIALLY, if your starting place originates at SDSC. This is not fool-proof, however. Your Secure Shell client (ssh) could be trojaned as well. :(
  • If your sites has kerberos, use kerberos to login to remote sites. This password is not crackable, but is vulnerable to keystroke loggers and trojaned kerberos clients.