Show HN: Be Your Own Password Generator(hachibu.github.io)
hachibu.github.io
Show HN: Be Your Own Password Generator
https://hachibu.github.io/be-your-own-password-generator/
15 comments
This is great breakdown. I think doing an entropy test would be a great idea for a followup blog post.
I don't know how to run an entropy test. Do you know how I could do that?
I don't know how to run an entropy test. Do you know how I could do that?
The search term you are looking for is Shannon Entropy [0]. That should set you in the right direction.
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.
[0] https://planetcalc.com/2476/
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.
[0] https://planetcalc.com/2476/
Thank you, I'll try it out.
> Do you know how I could do that?
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.
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.
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.
Yeah, I should figure out how to test the entropy of this and add that to the site.
"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).
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's a cool concept. I'd love to try it.
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.
Ah yes, I understand what you're saying. The videos aren't being stored anywhere. It's all happening inside the browser. The video disappears as soon as you refresh or close the browser.
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.
Wouldn't a good psuedorandom number generator that takes measures from different sources in the computer and ambient room noise from the mic, mouse movements, etc be plenty of entropy while being much easier than having to shake a physical box and take a photo?
That would be a lot harder to recreate and reverse engineer than getting a copy of the photo of the dice.
That would be a lot harder to recreate and reverse engineer than getting a copy of the photo of the dice.
Yes, you might be right.
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.
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.
That's awesome. It would be cool to somehow automate the shaking of the box, taking a picture and making a SHA hash.
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.