LISA’10 – Passwords

Print Friendly, PDF & Email

The current high risk vulnerabilities in password cracking are; keylogging, phising and password leaks. So it’s no longer the strength of the password that matters because if anyone was to get your password in the above methods it doesn’t matter if it’s “password” or “P%c9%jh32d1Ydlog3uurLK};LJcd”! It’s important to remember that “users are not the enemy” (AM Sasse) so don’t make them suffer for security weaknesses by making them remember massive complex passwords that follow impossible rituals of complication. Must have a minimum of 8-10 characters, must have at least 1 special character, number, capital letter, must not contain spaces, etc, etc…

Recommended reading/viewing on password security concepts, Cormac Herley.

For more secure but memorable password/passphrase pick something dictionary based but a friend/colleague can’t guess or that someone watching won’t get from watching you type.

Call for less painful account lockouts

  • typing the same wrong pass twice should be counted as 1 try.
  • allow a trusted user to vouch for you when you forget.
  • lock in increasing increments of time.
  • remind of rules when attempting.

Use rsa softkey devices to generate keys from a small question or code. Some banks use these and you can even get an app for that!

The login process should be more pleasant to type.

Gather word lists and randomly selected words builds higher entropy but friendly passwords. use for creating fun passwords

Alternative authentication ideas

  • password pictures – select the picture which is your password
  • password faces – same but faces are easier to remember
  • pick a random computer picture
  • draw secret – is appearing on recent smart phones
  • blur pics
  • passmaps – zoom in on a place and the location which is your password
    • using mandlebrot set instead?
  • pass-authentication
    • obfuscation. (indicator and wipe-off.)
    • challenge-response that you work out in your head ()

Recommendations for password management

  • have multiple passwords for different levels of security, usage and importance.
  • pam_tally2
  • ban inquisitive ip addresses (honey pot)
  • build a secure authentication server
  • use public authn servers (e.g. OpenID)
  • make user names harder to guess
  • disable password authn on SSH simple dict attacks over!
  • multi-factor authn (e.g. certificate, password and biometric)
  • pass-phrase locked SSH keys

How to apply this at work

  • remove pwd auth in SSH
  • disallow standard users to SSH between servers. Only allow it from desktops and deployment servers
  • disallow key based auth between servers (except for certain managed accounts)
  • automatically remove passwordless keys from servers (except for certain managed accounts)
  • force commands and sanitise input in authorized_keys files and register all commands that are run remotely
  • use a distributed job scheduler, network shared drives to remove need for passwordless keys

There are some inherent security risks with deploying to production environments using fabric (possible fixes on second indent)

  • Developers use their own accounts sometimes with a passwordless ssh key to deploy site structure.
    • use a dedicated account for deployment which is not an individual and lock it down
    • Use a central deployment server
  • There is no input sanitisation on the remote end that these commands should be run.
    • Add a script on the remote end that checks all the commands that are allowed in the scripts. Would mean that all commands would need to be checked in the fabric scripts which could be time consuming
  • In some cases the scripts would use elevated privileges to create files for the service.
    • See first answers
    • do not require sudo to make changes
    • use bcfg2 for all root access
  • The scripts access multiple servers in fast succession which increases the risk on other services.
    • increase monitoring and auditing of use.
    • use service based accounts and not UoB users which can be tracked and locked down to the servers which are related to the project
    • harden access to the source deployment server

There are some risks deploying with bcfg2 similarly

  • ssh with a passwordless key (although it is protected to only run one command) to remotely trigger a svn update on the bcfg2 repo.
    • change to a timed pull (cron check for a trigger file over http which causes the update)
  • fabric is used to push client updates out, this same script allows for arbitrary commands to be run.
    • remove need to run extra commands
    • push updates via job scheduler or CI server
  • clients authenticate with a password which can easily be obtained.
    • change to per client certificates (see SSLCA plugin)
    • … or per client passwords (in clients.xml)
  • various sensitive data is held in the repo (such as SSL certificates and root shadow passwords)
    • move to external management service, such as a certificate safe or LDAP (doesn’t work if network down)
    • secure access to parts of the code repository
    • have base root configuration repo paths with insecure content in a separate repo overlay