Hacker News Reader

Comment by prophesi | Hacker News Reader

It sounds like to me that there are three types of people:

* Layman who reuses passwords unless a techie friend convinces them to use a PW manager.

* HN user who either uses a SAAS password manager or sets up their own system to solve the issue of syncing a password store across devices.

* Those who actually have state level secrets or living under an oppressive regime and thereby don't trust even the networks they connect to.

Just an observation; not making any statements. But if I were to make one, it's to know your own threat level and find the security vs convenience compromise that works for you, and educate your friends & family.

View on HN

I sort of fall into the second category, except I don't sync passwords across devices or even store them at all. I generate them on the fly with [1].

[1] https://chrome.google.com/webstore/detail/hashpass/gkmegkoip...

Having an algorithm (especially one that is publicly available) to generate passwords is not as secure as unique passwords for each service. For example, we now know that you 1) use this extension, and 2) have a HN account. We can now start brute-forcing your password for HN.

It uses a master password to generate these passwords, so I actually think you wouldn't be brute-forcing their HN password that way but the master password itself. If you crack one entry, that means you've found the password they're using to generate all of the others.

Note that regular password managers also have a master password people can try to brute force, so I actually think this algorithmic method is technically more secure since there's no need to trust a third party to manage the password store, while still having the other flaws that traditional PW managers have.

Does this have an option to use multiple master passwords? For example accounts 0-10 use password x and 10-20 use password y?

Nothing is preventing you from using a different master password for different accounts, but you'd have to keep track of that yourself, since Hashpass doesn't store any state whatsoever. I personally just use a single universal password, which is not as safe but much easier to manage.

How does this work with sites that have absurdly strict password requirements? i.e. 8-16 characters, 3+ letters (1+ of which is upper case), 2+ numbers, 1+ special characters (from their curated list only!) I've seen a few financial related sites have requirements like these, and with a typical password generator I can just click 'generate' until one pops out that meets the reqs, and save it.

For those sites, I usually just add whatever characters are needed to satisfy the requirements to the generated password (e.g., 0). This is annoying, since I have to keep track of which sites required such amendments. Fortunately, the majority of websites I use don't have such annoying requirements. And if I ever forget which sites have "amended" passwords, it's easy to find out simply by attempting to log in and being denied entry (in other words, I can brute force my way in).

Despite this awkwardness, I think this approach is worth it. I only have to memorize one password, and yet I still have a different password for every website. And if the Chrome extension ever gets shut down (*), the algorithm is simple enough to recreate in 4 lines of Python:

    bits = (domain + '/' + universal_password).encode()
    for i in range(2 ** 16):
        bits = hashlib.sha256(bits).digest()
    generated_password = base64.b64encode(bits).decode()[:16]

(*) I am the author of that Chrome extension, so I personally am not worried about it being shut down. But it is perfectly valid for other people to have that concern, of course.

Were the problems with just unconditionally adding small string of all such characters to every password, whether the site needs it or not?

   generated_password = base64.b64encode(bits).decode()[:16] + '0@#Zz'

It's a good idea that I've considered. However, I didn't anticipate the need for this when I originally designed Hashpass in 2014, and adding it now would be a breaking change.

I'm still considering it, but there would need to be a very slow, very careful rollout plan. Probably some transition period where users can opt into the new scheme, then eventually make the new scheme the default but still support the old scheme, and finally remove the old scheme to make things simple again.

Since this is a Chrome extension which collects no information from users, I have no way of contacting users about this. So I would need to wait long enough that users discover it themselves in the UI. All told, I'd guess it would take about a year for the full migration.

Anyone is welcome to discuss things like this with me via GitHub issues: https://github.com/stepchowfun/hashpass

> opt into the new scheme

Checkbox:

  Append common required chars [ ]: @Zz1

The roll out is that this is unchecked by default initially with a warning that the default will be checked. Then eventually it defaults to checked.

Yes, a checkbox is one way to allow users engage with this feature. There are other changes I'm considering as well (e.g., increasing the length of the generated passwords, avoiding characters that look like other characters such as 0 and O, etc.). You have the right idea, but the new experience needs to be designed holistically.

* HN user who doesn't use a password manager and doesn't sync passwords across devices and doesn't reuse passwords (except on throwaway accounts)

Though I would argue that's still setting up your own system to solve the issue of syncing passwords. Whether that be creating your own algorithm to "generate" passwords you can remember or reproduce, keeping them in a notebook, etc.

Reply on news.ycombinator.com