opensecret Build Status

opensecret | Install and Configure

opensecret stashes uncrackable secrets into your Git, S3, DropBox, Google Drive and filesystems backends. You interface with its intuitive Linux, Windows, iOS front ends and it offers SDKs and plugins for Ruby, Python, Go, Java, Jenkins, CodeShip, Ansible, Terraform, Puppet and Chef. Soon, support will be added for database and keystore backends such as MySQL, MongoDB, PostgreSQL, Redis, Memcached and etcd.

opensecret never accesses the cloud. It can operate on a wee non-networked laptop if you so wish. opensecret takes a fresh approach to security and challenges common misconceptions - in order to deliver a simple, highly secure credentials management system.

opensecret | Install It

$ gem install opensecret

opensecret | Configure It

$ opensecret safe  /path/to/usb/key/safe
$ opensecret email [email protected]
$ opensecret store https://www.eco-platform.co.uk/crypt/lecturers.git
$ opensecret init

These directives tell opensecret where, who and which - the order doesn't matter.

  • keydir » best practise is a usb key drive with your actual keys
  • name » single word lowercase and short - how your peers call you
  • email » email address (validation scheduled for end of March 2018)
  • domain » joe@home if single or a team like [email protected]
  • store » a Git project URL to hold your encrypted secret material

opensecret | Create Keys

Init(ialize) creates an uncrackable 8192 bit private/public key pair, locked down with an amalgamated (human and machine generated) password.

$ opensecret init

Or you can enter the password on the command line.

$ opensecret init --password="seeKr33t-p4ssw0RD@x"

opensecret | All Done!

opensecret is configured! Before locking and unlocking sensitive data let's ask "How can Susan steal Joe's secrets? Well, she would need to

  • acquire his USB drive key
  • requisition his laptop, crack the disk encryption and assail the login password
  • convince Joe that **revealing his password is the painless route, then
  • break into the backend store (AWS S3, GitHub, Google Drive, SSH)

It's simple for Joe but nigh impossible for Susan. That's why you need a USB key drive, an offsite storage solution and an encrypted drive.

Your ability to access your own secrets (even after disaster scenarios) is as important as preventing the secrets being accessed. This is why opensecret piggy backs off your (already configured) redundancy and backup solutions.

opensecret | Lock and Unlock

Joe wants to lock away his wifi password.

$ opensecret init

opensecret | moving to anoter computer

On computer where it is all working you do

$ opensecret copy config

Then you take out the USB key and (many hours or even days later) you put it back into another computer you do

$ opensecret paste config

One Lock | Two Keys

With suitcases, the key that locks the suitcase also opens it.

In cryptography - you have two keys. You give out your public key and anyone can lock any suitcase (of goodies) with your public key. Once done, that suitcase can only be opened with the other key, your private key. opensecret creates an 8192 bit private key which is simply uncrackable.

The safest place to put your private key is on a USB key drive which you carry around with your real keys. And to top it all - a password that only you know is used to lock your private key.

For scripts that cannot stop and wait for user input - keys can optionally be created with a password given at the command line.

$ opensecret init --password="p455w0rd.!0NDUN"

The Encryption Strategy

opensecret uses a symmetric key to perform the initial encryption of the data, followed by an asymmetric public key that encrypts the result.

The encryption key itself is then locked down by the public key which is then thrown away. The file on the backend store is the doubly encrypted secret.

A corresponding file appears on the front end (usb drive) store afer encryption by the master public key. This bundle (decryptable by the master private key) is an amalgamation of the

  • private key (to unlock the first layer of 1 secret and its encryption key)
  • the encrypted encryption key (unlockable by the aforementioned private key)
  • technical specification of the encryption algorithm plus settings

The benefits of this strategy can now be assessed. First off, is the 3 isolated stores that are created.

The 3 Isolated (Worthless) Stores

There is a grand design behind this mesh of keys, cipher text and symmetricity. The theoretical underpinning of opensecret is predicated on a tri-store security solution.

What is tri-store? Use opensecret and you get 3 isolated (and individually worthless) information stores.

  • a backend store of doubly encrypted secrets
  • a middle store of doubly encrypted keys
  • a front end of encrypted master key (on USB), human password (in brain) and encrypted machine password (in machine)

You can think of opensecret as a reference open source implementation of the tri-store concept.

Sending a Wifi Password

With the one password culture, just one password gives you access to everything. I can't send a Wifi password (which is gold dust to hackers) securely. I have to login (potentially exposing every secret) - copy and paste the Wifi password and then email it - even if I encrypt it I am still sending the ciphertext and then they key.

benefits of a tri-store solution

Think of your doubly encrypted ciphertext as the backend, the doubly encrypted keys as the middle and then the logical group of the master key (on USB), human password (in brain) and encrypted machine password (on machine).

  • you can transport and/or share secrets by sending the keys (not the backend material)
  • you can rotate your master key and passwords (again - no touching or accessing the backend)
  • you can (and should) assign separate (off-machine) stores for the middle and backend
  • you can select different local or cloud based storage locations for middle and backend stores
  • you can safely backup stores - and with Git you get this (and rollbacks) for no extra effort
  • you can invalidate, expire and revoke secrets by interacting with just the middle tier
  • when a secret is read - it is locked up again with new keys giving you a read audit trail

the no-go no-clouds mantra

opensecret is designed to operate in highly secure locked down environments in which external access is not just constrained - it is non-existent.

opensecret does not contact nor talk to anything external. It never asks (nor needs to know) the credentials for accessing your stores - this means it compliments your storage security be it S3, Google Drive, databases, VPN, Git and even email/pop3 solutions.

the encrypted at rest mantra

The ability to read data from drives (after the fact and) after deletion means nothing unencrypted should be put on any drive (including usb keys).

easy adoption of new algorithms

You can configure the algorithm (or algorithms) and implementation used and this information is encrypted within the middle tier store.

Attacks usually target particular algorithms so putting this information away (or even randomly selecting from a pool of algorithms) - all adds to the worthlessness of the backend cipher text store.

Algorithms can also be selected based on encryption targets like

  • binary files
  • large text files or
  • small 4 digit keys (like pin numbers)

Not only do no two pieces of encrypted material share encryption keys, they also need not share encryption algorithms (and remember - they are doubly encrypted).

opensecret configuration

Aside from your private keys, opensecret keeps a small amount of configuration within the .opensecret folder off your home directory. A typically opensecret.ini file within that folder looks like

[[email protected]]
type    = user
id      = joe
keydir  = /media/joe/usb_drive
domains = [ lecturers@harvard ]
default = true
printx  = asdfasdfas65as87d76fa97ds6f57as6d5f87a
printy  = asdfasdfas65as87d76fbbbasdfas0asd09080
printz  = adsfasdflkajhsdfasdf87987987asd9f87987

[lecturers@harvard]
type    = domain
store   = git
url     = https://www.eco-platform.co.uk/crypt/lecturers.git

Backend Storage Options

The planned list of backend storage systems (each onlined with a plugin), is

  • Git (including GitHub, GitLab, BitBucket, OpenGit and private Git installations).
  • S3 Buckets from the Amazon Web Services (AWS) cloud.
  • SSH, SCP, SFTP connected file-systems
  • network storage including Samba, NFS, VMWare vSAN and
  • GoogleDrive (only Windows has suitable synchronized support).

Access management is configured EXTERNAL to opensecret. Opensecret simply piggybacks the network transport if authorization is granted.

How to Join a Domain

  • opensecret will loop encrypting your public key's fingerprint with the public keys of present members
  • when they interact opensecret will ask if they trust the new id/email and key
  • if they say yes the fingerprint is imported and held with id/name
  • ongoing domainwide checks flag up public key / fingerprint mismatches
  • if keys are removed or updated similar questions are asked.

Why Beg for Secrets?

Why beg for a secret - why not just tell someone it?

It is much more secure to beg for a secret than just have someone reveal it. When you beg for a secret - you are sending an encryption key to a single person who must possess the private key and they send back the secret encrypted with both your specific public key and the encryption key that originated from you.

Any hijacker will need access to a great many things and be very precise with their timing in order to serrupticiously subvert the system.

Git | S3 or ... | Which Backend Storage?

If you have a choice and would like to know the pros and cons of one of the many backend storage options then visit the opensecret.io website.

opensecret | Summary

You can use opensecret alone or you can use it to share secrets with colleagues, friends and family, even machines.

opensecret is simple and holistically secure. Simple means less mistakes, less confusion and more peer reviews from internet security experts.

Every domain is tied to backend storage which is accessible by you and others in your domain. You can use Git, S3, a networked filesystem or shared drive, a SSH accessible filesystem and soon, free storage from opensecret.io

Development

After checking out the repo, run bin/setup to install dependencies. Then, run rake test to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to rubygems.org.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/opensecret. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.

License

MIT License Copyright (c) 2006 - 2014

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Code of Conduct

Everyone interacting in the OpenSecret project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.