Hacker News Reader

Comment by madmonk | Hacker News Reader

I've been working on a concept where, instead of storing passwords in a manager I use a generator that creates pseudorandom passwords based on a few, easy to remember things. It's essentially a hashing algo created in javascript. You provide a site name, a password length and a pin code and it will consistently generate the same pseudorandom string. Nothing is stored and the generator can be publicly hosted.

https://github.com/madmonk13/keymaster

This is the first time I've publicly shared it and I welcome your feedback.

View on HN

This is great, I used to do a similar thing but all in my head (so obviously not as complex permutations)

In practical use, how do you typically remember whether or not a site allows special characters or has a length requirement? Also do you ever have trouble remembering what you named a particular thing? Might be easy for something with an FQDN, but for an encrypted vault or ssh key may be harder

Edit: on second thought, the use of only a numeric pin (with suggested length of 4) seems not good from a security perspective. For an offline attack against, say, a true crypt partition I could offline attack a fairly large pin space with a number of different names fairly trivially. Even in an online attack, if I assume you’re sticking with a 4-digit pin and using the site name “Facebook” then I have a 1/10000 chance, which drops to 1/2500 if Facebook lets me have 4 attempts. The PIN should be a pass phrase IMO

Edit2: please take these criticisms as genuine feedback, as I think this is an excellent idea and I’d like to use it myself. I’m curious why no true cryptographic hash algorithms were used? I only skimmed the code, but I’m concerned that under a model where 1 or especially 2+ passwords are leaked (inevitable in this day), there would be non-zero leakage of intermediate stages if not the original pin. The other challenge I see is the integrity of the JS - would folks self-host this? Otherwise you could possibly use Subresource integrity to load the JS from an untrusted source, and the user would manually verify the SRI key or something

Sorry for the late response. I lost track of this thread.

> In practical use, how do you typically remember whether or not a site allows special characters or has a length requirement?

Good question, wish I had a good answer. That's one issue I've yet to solve for.

> Also do you ever have trouble remembering what you named a particular thing?

No, I base my names off the domain.

> Edit: on second thought, the use of only a numeric pin (with suggested length of 4) seems not good from a security perspective.

The pin length is unlimited. Also, the open nature of this approach allows you to pad site names however you like. For example, instead of using "amazon" choose to pad your names with 2 z's (not my method) as in "zzamazon".

> I’m curious why no true cryptographic hash algorithms were used?

There were certain requirements I had for the output that I couldn't guarantee from existing hashes, one was each for character only appearing once in the output.

> The other challenge I see is the integrity of the JS - would folks self-host this?

Yes. Users are also free to alter the algo to meet their own needs. A simple way to make it unique to you would be to reorder the characters in the 4 sets.

> please take these criticisms as genuine feedback

I am and I do appreciate it. Like I said, this is the first time I've publicly shared it and want any potential issues brought to my attention. I am not a security/crypto expert, barely a novice, and if I'm barking up the wrong tree with this approach I appreciate someone letting me know.

I've been using https://chriszarate.github.io/supergenpass/mobile/ a similar idea. I'm going to switch to yours though, its designed better. Thanks

Thank you for the feedback. If there's any issues you notice going forward, feel free to reach out.

Before I started using 1Password I used to do the same thing.

Reply on news.ycombinator.com