Cloudreach Secrets: Planning App Modernisation
Sharing secrets with non-technical users is challenging. Asking a non-technical user to generate a key pair, send the public key, and encrypt the secret so they can decrypt the response with their private key can be a bit too much to ask for. Many don’t know where to begin, whether they are allowed to install relevant tools on their machines after being given instructions, and are likely to make mistakes along the way adding further salt to the wound.
Not only is finding a good process challenging, but then making sure secrets are shared securely can also be a pain. Do I send a secret via SMS, send an encrypted message over email, or generate a one time password and place it somewhere only accessible by the recipient?
However you choose to share your secrets, practical and secure don’t often go hand in hand.
A great example of this is complex passwords. It has been reported that complex passwords have proved to be less secure. If the password is too complex it ends up written down and soon forgotten introducing large management overheads, ultimately driving insecurity.
So how James Bond do you need to be to share secrets safely?
It turns out, not very. Cloudreach Secrets was born which operates on the principle that using a soon-to-be-expiring link to retrieve sensitive information is better than having the sensitive information persist in email, chat, etc… This was created a few years ago by a employee and ended up being used by various Cloudreachers as it found the right balance for security vs convenience.
The Original Application
Cloudreach Secrets is based on PHPasswordPusher, a PHP port of the PasswordPusher project.
A user will enter the sensitive information (password, etc.) into the pwlink script, set a view and time limit, and receive a link. That link is communicated to the intended recipient, who then can retrieve the sensitive information until the view or time limits are breached.
An option is available to generate a random password. You can set its length and complexity so you don’t have to worry about coming up with a secured password. Just click the button, and use the result. You can then send it through the Get Link option.
This application was created as a side project back in 2012, and was made for limited uses. In order to modernise this app, here’s some things we wanted to address:
- It’s a typical LAMP stack, built in AWS using AWS EC2 + Autoscaling + RDS – a very traditional infra / code implementation. In 2012, it seemed embracing of cloud technology, but over time, it has proved expensive (compared to recent serverless paradigms) to run and time consuming to maintain.
- Its 100% GUI based, A CLI of some kind, or API to call would make my life much easier. Especially when onboarding many users into a system where lots of passwords need be generated and shared (ideally programmatically, let’s have a script do it for me?)
- It works reasonably well for authenticated users sharing secrets with non authenticated users, but how can I extend the system to allow any user to share secrets with any other user securely? (making it useful to the world and not just us)
- Such a setup leaves the system open to guessing links, afterall, you are just sharing a URL with a secrets ID in it. It feels like a temporary security by obscurity implementation, which I definitely do not want to rely on for working with the most highly sensitive clients (even if password changes are forced there is a interception potential of my secrets)
We figured it’s in need of a refresh. So how would this be done?
Stay tuned for a follow up!