Padlock Cloud is a cloud storage service for the Padlock app implemented in Go. It provides a (mostly) RESTful api for storing and retrieving user data. Padlock Cloud does NOT implement any kind of diffing algorithm, nor does it attempt to provide any kind of cryptographic functionality. Any encryption, decryption and data consolidation should happen on the client side. Padlock Cloud merely provides a cloud-based storage for encrypted user data.

The padlock-cloud command provides commands for starting Padlock Cloud server and managing accounts. It can be configured through various flags and environment variables.

Note that global flags have to be specified before the command and command-specific flags after the command but before any positional arguments.

padlock-cloud [global options] command [command options] [arguments...]

For a list of available commands and global options, run.

padlock-cloud --help

For information about a specific command, including command-specific options, run

padlock-cloud command --help

Execute schema.sql in your padlock database.

Starts a Padlock Cloud server instance

Commands for managing accounts.

List existing accounts.

Create new account.

Display account.

Delete account.

Generate random 32 byte secret.

This image provides multiple options to configure the application.

The precedence for flag value sources is as follows (highest to lowest):

1. Command line flag value from user
2. Environment variable (if specified)
3. Configuration file (if specified)
4. Default defined on the flag

The provided file should be in the YAML format. Here is an example configuration file:

server:
  assets_path: assets
  port: 5555
  tls_cert: cert.crt
  tls_key: cert.key
  base_url: https://cloud.padlock.io
  cors: false
leveldb:
  path: "postgres://user:pass@localhost:5432/padlock?sslmode=require&application_name=padlock_cloud",
email:
  server: smtp.gmail.com
  port: "587"
  user: mail_user
  password: secret
  from: [email protected]
log:
  log_file: LOG.txt
  err_file: ERR.txt
  notify_errors: [email protected]

NOTE: As padlock is build upon chrome we need a valid certificate issued by a trusted source. For now let us assume we have a certificate named cert.pem and a key named key.pem in the directory ./ssl/.

NOTE: The email-settings can be found out by searching for [email-provider] smtp login.

docker run -p 443:8443 -v ssl:/opt/padlock-cloud/ssl -e PC_PORT=8443 \
-e PC_BASE_URL=[base-url] -e PC_EMAIL_SERVER=smtp.googlemail.com \
-e PC_EMAIL_PORT=587 -e [email protected] \
-e PC_EMAIL_PASSWORD=userpassword1234 \
-e PC_TLS_CERT=/opt/padlock-cloud/ssl/cert.pem \
-e PC_TLS_KEY=/opt/padlock-cloud/ssl/key.pem padlock/padlock-cloud

This image can be used like the cli. Just prepend docker run.

NOTE: This image uses a user padlock-cloud with uid 1000 and group padlock-cloud with gid 1000 to run padlock-cloud. You should check your permission before mounting a volume.
NOTE: This image will try to change the ownership of it's WORKDIR to 1000:1000. This won't work when mounting a volume from Windows.

This image contains 4 volumes.

Contains assets used by padlock-cloud to render the frontend and the emails.

Contains the data stored in the cloud.

Contains the logs.

Contains the certificate and key.

This image exposes ports 8080 and 8443, because this image uses a non-root user. By default the padlock-cloud listens at port 8080, because it doesn't use SSL by default. It is highly suggested to provide a TLS-Certificate and Key to enable SSL and listen at 8443. This could be done by setting PC_PORT to 8443.

This image uses a user padlock-cloud with uid 1000 and group padlock-cloud with gid 1000 to run padlock-cloud.
It will try to change the ownership of your mounted volumes to 1000:1000.

First, you'll need to have Go installed on your system. Then simply run

go get github.com/giansalex/padlock-cloud-pg

This will download the source code into your $GOPATH and automatically build and install the padlock-cloud binary into $GOPATH/bin. Assuming you have $GOPATH/bin added to your path, you should be the be able to simply run the padlock-cloud command from anywhere.

It goes without saying that user data should never be transmitted over the internet over a non-secure connection. If no --tls-cert and --tls-key options are provided to the runserver command, the server will be addressable through plain http. You should make sure that in this case the server does not listen on a public port and that any reverse proxies that handle outgoing connections are protected via TLS.

Padlock Cloud frequently uses confirmation links for things like activating authentication tokens, confirmation for deleting an account etc. They usually contain some sort of unique token. For example, the link for activating an authentication token looks like this:

https://hostname:port/activate/?v=1&t=cdB6iEdL4o5PfhLey30Rrg

These links are sent out to a users email address and serve as a form of authentication. Only users that actually have control over the email account associated with their Padlock Cloud account may access the corresponding data.

Now the hostname and port portion of the URL will obviously differ based on the environment. By default, the app will simply use the value provided by the Host header of the incoming request. But the Host header can easily be faked and unless the server is running behind a reverse proxy that sets it to the correct value, this opens the app up to a vulnerability we call 'link spoofing'. Let's say an attacker sends an authentication request to our server using a targets email address, but changes the Host header to a server that he or she controls. The email that is sent to the target will now contain a link that points to the attacker's server instead of our own and once the user clicks the link the attacker is in possession of the activation token which can in turn be used to activate the authentication token he or she already has. There is a simple solution for this: Explicitly provide a base URL to be used for constructing links when starting up the server. The runserver command provides the --base-url flag for this. It is recommended to use this option in production environments at all times!

When trying to connect to a custom server instance, the Chrome app fails with the error message "Failed to connect to Padlock Cloud. Please check your internet and try again!". This is due to the same-origin policy in Chrome preventing requests to domains other than cloud.padlock.io that do not implement Cross-Origin Resource Sharing. While it's not enabled by default, Padlock Cloud does come with built-in CORS support. In order to enable it, simple use the cors option. E.g.:

padlock-cloud runserver --cors

NOTE: CORS is enabled by default when using the docker image.

2016/09/01 21:40:59 open some/path/activate-auth-token-email.txt: no such file or directory

The Padlock Cloud server requires various assets like templates for rendering emails, web pages etc. These are included in this repository under the assets folder. When you're running padlock-cloud you'll have to make sure that it knows where to find these assets. You can do this via the --assets-path option. By default, the server will look for the templates under $GOPATH/src/github.com/giansalex/padlock-cloud-pg/assets/templates which is where they will usually be if you installed padlock-cloud via go get.

Original Source