Show HN: Be Your Own Password Generator
hachibu.github.io
hachibu.github.io
This is an interesting idea but have you conducted any entropy tests by generating a class of passwords from a family of videos and seeing how different they really are (e.g. character freq)? Without any hard numbers I can pretty confidently assume that the colors (8 bit unsigned perhaps mean R, G, and B pixel values) in a video are not uniformly/randomly distributed in the color space and subsequent frames of the video are also highly correlated. Not to mention you specifically throw away any non ascii character so a large portion of the UTF-16 space is not even allowed). Unless by chance, those you throw away happen to also be the super common int values, I feel that it's likely the entropy of these passwords is going to be surprisingly low.
What do you think? The entropy test would make a great blog post.
I don't know how to run an entropy test. Do you know how I could do that?
Put in layman terms - your best possible entropy is a case where every allowed character appears with roughly the same chance (i.e. there is no super common or super rare characters). The most extreme low entropy case is where only one character appears all the time so the password is completely predictable if you know how long it is.
I would recommend you run two tests. One with the same video over and over video and one with 5 or so videos filmed under similar conditions to measure how much of the randomness actually comes from different videos vs. your algorithm. For your videos genererate 100k+ passwords and count the number of times each character appears to get the probability of each character. Then use what you learned about Shannon Entropy (using the probability of each letter) to determine how much entropy your passwords have.
Dieharder or TestU01 are considered the gold standards of statistical tests for randomness by many (my claim only, randomness is provably unprovable)
You can try the nist one too if you want to go down the corporate route but these tests go further.
It reminds me that I've been very slowly experimenting with an idea I've been calling "avatar auth" for a Secure Scuttlebutt-like P2P social media (or possibly just directly with SSB). The idea is that the raw original image file used to build an avatar acts as the hash/input to a key derivation function so that the raw avatar image itself is the "password" to the account. You force a lossy series of steps between the raw image and the final avatar (crop, shrink, corner rounding, maybe some simple filters) so someone can't just copy an avatar as they see it on the service itself to log in. You can't entirely eliminate "copy-cat" avatars (but they'd have different keys/account numbers), and you have some difficulties with avatar migration, but overall it's a really simple login system idea (choose your avatar image file and go).
That would be a lot harder to recreate and reverse engineer than getting a copy of the photo of the dice.
I don't do top secret work, but I do want to protect my personal, business, banking, etc. information so I fiddle around with various approaches to generating passwords.
I actually bought a small, very cheap, PC that I run Linux on expressly for the purpose of managing passwords. It never connects to a network and has software for generating gpg keys, certificates and passwords. I use it infrequently enough that each time I do it takes a lot of work to remember how I decided best to use it.
What I use more than anything for 95% of my passwords is Apple's Keychain app. The information is backed up in the cloud and is available on my Apple computers, iPad, and iPhone. It's been a very helpful application, and I like how it's integrated into Apple's software. For important passwords I resort to the box of dice or my air-gaped little linux laptop.