There's significant correlation between adjacent pixels in a natural image and between corresponding pixels in consecutive frames. Using the least significant bits of the raw pixel data is a reasonable source of entropy, but using entire pixels and just concatenating them is probably far less entropy than the length of the generated password would suggest.
"People who have this video," is a reasonable security challenge in some cases/threat models.
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).
So this scheme could be useful as a simple sort of video hashing, at least to meet basic hashing needs. I wouldn't use this as a password generator, though. Anyone can reconstruct the password using the same video, so you would have to protect the video.
I have a clear box of about 50 colorful dice on my desk. I can shake the box anytime I need a strong password. Dicewords.com word lists are an easy way to generate strong passwords completely off-line. If that isn’t a requirement, a SHA256 hash of a photo of the box contents after shaking can easily generate 256 bits of entropy over and over.
> It records a short video of you and then transforms that raw video data into an array of 8-bit unsigned integers. Then it randomly selects an integer from that array and transforms it into its corresponding UTF-16 character. If that character is a lowercase letter, uppercase letter, digit or special character it will be used for your password.
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.