A simple, fault-tolerant, and easy-to-audit password manager. Only ONE dependency: Stanford Javascript Crypto Library https://pwm.sequentialread.com

forest johnson d5f3bfe116 3 years ago
static d6fdbfa190 fix bug where onKeyDown would trigger a file to save even if the contents did not change 3 years ago
.gitignore 5d6bb51376 add docker build 3 years ago
Dockerfile 5d6bb51376 add docker build 3 years ago
LICENSE bdf23dcaa3 add MIT license 3 years ago
ReadMe.md 59526c5253 update readme, fine-tune the secret length disclaimer on the app, and update the screenshot 3 years ago
build.sh d6fdbfa190 fix bug where onKeyDown would trigger a file to save even if the contents did not change 3 years ago
index.appcache.gotemplate e25ed0dcee Got S3 working 3 years ago
index.html.gotemplate c2fe00b4a5 make encryption seed field be a password field when user is typing into it, put accept headers on requests for json 3 years ago
screenshot.png 59526c5253 update readme, fine-tune the secret length disclaimer on the app, and update the screenshot 3 years ago
server.go d2329e1540 make s3 bucket name and region configurable 3 years ago


SequentialRead Password Manager

This is a Golang / HTML5 / vanilla JavaScript web-application which stores encrypted text files in three places:

  • localStorage in the browser
  • on disk next to the HTTP server binary
  • in an Amazon S3 bucket


Try it! (https://pwm.sequentialread.com)

OR run it yourself in docker:

docker run \
  -p 8073:8073 \
  -v "/Users/exampleUser/Desktop/encrypted-passwords:/data" \
  -e SEQUENTIAL_READ_PWM_S3_BUCKET_NAME=my-encrypted-password-bucket \

See "Hosting it yourself" for more information.


First and foremost, the application is easy to audit since it has only one dependency: sjcl.js, AKA the Stanford JavaScript Crypto Library.

There is nothing that pulls in dependencies, no bundling step, etc. There is only one place where XMLHttpRequest is created, and the request body is encrypted in the same place. Same goes for localStorage.

It was designed that way to strengthen the claim that "everything it sends out from the javascript VM is AES encrypted with the key you chose".

High Avaliability by Design

It uses the HTML5 Application Cache to ensure that even if my server goes down, the app still loads.

It also has its own AWS Credential with access to the bucket, so you can still access S3 if my server goes down.

It will also work even if your device has no internet connection, of course any changes will not be sent to my server or to S3 until you can connect again.

It uses a naive approach to keep all 3 data stores in sync: When writing, it will attempt to write to all 3 and tolerate failures. When reading, it will compare the lastUpdated timestamps on all versions that it received, and if they don't match or if one is missing, it will issue a PUT with the most up-to-date version.

That means if you happen to make conflicting changes, there is no real conflict resolution. The latest one wins.

Encryption Key User Interface Disclaimer

You are allowed to use whatever seed you want for your AES key. If you pick a weak seed and get hacked, that is your fault. The application warned you about it. It was even red, bold and underlined!

The application includes a timestamp + mouse-movement + SHA256 based entropy generator to create a secure ~128 bit key, encoded in base 10,000. It will appear as a collection of a few english words/phrases. An example:

bedrooms confirmation decor generic wondering temperatures bm retreat beer

Assuming the attacker had access to the ciphertext and could use top-of-the-line hardware (A Bitmain Antminer S9 in this case), how long would it take to guess every possible combination of words? A very, VERY long time

For comparison, under the same scenario, a key with only 4 words would be cracked within 10 Minutes.

Does that mean a key with 4 words is not secure enough? It might depend on the situation.

Casual remote attackers probably won't have access to the ciphertext since they would have to look at your localstorage or guess a gazzillion things over HTTP. I just put a scary disclaimer on the app since I don't want to be holding people's weakly encrypted data.


This software is provided "AS-IS" under the MIT license. For more information see the LICENSE file.

Hosting it yourself

You should create a separate IAM user in AWS which only has access to the bucket. This is the policy I used for that user:

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "Action": [
            "Resource": "arn:aws:s3:::sequentialread-pwm"
            "Effect": "Allow",
            "Action": [
            "Resource": "arn:aws:s3:::sequentialread-pwm/*"

You will also need to configure CORS on the bucket. This is the CORS configuration I used on the bucket:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">