Show HN: Pashword – Hashed Password Calculator
pashword.app
pashword.app
Passwords generated here still have the exact same entropy as the input secret. In fact, you might even decrease entropy based on the length selected.
Entering a website, username and length doesn't increase the actual entropy, because you should consider these as known.
If users go about and use the same (basic) secret, which I imagine is a common practice, all their hashed generated passwords can be considered the same.
Users must ideally choose a different secret for every account, in which case a tool like this becomes obsolete.
Doing a large number of hash rounds has zero effect on actual security here.
What to do then? Generate a true random password for each instance. You can store those in a proper password manager.
But it gives you no good way to rotate an individual password if it gets leaked, and no good way to systematically rotate the secret if that gets leaked, since you’ll have to remember every site you used it on.
Contrast that with a password manager, where rotating a single password is trivial, and rotating your entire vault is painful but straightforward.
The only way to derive the secret from a leaked password is to brute force possible secrets. The number of hash rounds increases the required computations.
But even with only one round of hashing brute force will fail if the secret is sufficiently random (good luck brute forcing random 20 char strings).
The only problems this scheme has (apart from a very weak secret) are password rotations and a leak of the main secret.
Anyway, passwords should've died long time ago. Asymmetric private keys (derivable from secrets) should be a standard for user authentication.
Pros:
- you don't have to store/transfer the encrypted vault (usually few kB in size)
Cons:
- can't rotate passwords if service needs you to change it (leak, periodic rotation etc.)
- it can't support two factor auth (for the manager itself)
- it does not support auto-fill (but theoretically can, through a browser extension)
- it's web only (harder to trust)
- if one of your passwords leak, it's as if your whole password vault leaked -- the attacker can just brute force "master passwords" until they arrive at the same password, after which they can generate all of your other passwords
In other words, the security still hinges on the secret key, except you're not directly using the password Secr3tKey#website.example, but its hash. If everyone used this, the password strength would still be only dependent on the secret key strength, and wouldn't provide an easier avenue to a preimage (i.e. can't find the key otherwise than bruteforce; even though the explanation has some worrying confusion between hashing and encryption). Fairly straightforward, except some opsec concerns (e.g. "domain name lapses in a few years and Evil Operator starts logging the secret keys", or "site is unavailable for initial load, even though it does work offline afterwards")
Notice how traditional password managers don't have this problem at all. If a password leaks, it tells you absolutely nothing about the other passwords.
I'll just stick with passwordstore.org and bitwarden/vaultwarden
I built this webapp a few months ago because I forgot my bank account password and got locked out. A few days later, my friend complained to me about the same problem, he forgot his password and couldn't login.
This was a fun way to learn more about cryptography and hashing in detail and it was a lot of fun creating something that I would personally use.
I am well aware of the pitfalls and shortcomings of using such a tool but to be honest, I like Pashword because it suits my threat model and it's very convenient for me to use as well.
Would love to know what HN thinks about it and if there's anything I could do to improve it as well :)
1. If I have to change my password for any reason, I would have to come up with a new secret key since the site/username would never change. Suddenly I'm stuck having to remember multiple secret keys.
2. Poor control over the length of the passwords - you only provide 3 options, and 20 characters is pretty low.
3. You can't exclude certain certain characters - yes, it's stupid for companies to not allow certain characters in the password, but many sites still do so.
4. If I try to just put in an app name, you tell me to use a real URL.
5. It was SLOW. Maybe it's just busy, but I'd rather not have to generate the password every time.
6. Even people experienced in cryptography and hashing make mistakes. A product made by someone learning about them is... Suspect.
A password manager is 100% the better choice every time. For the people in my life who don't want to learn how to use a password manager, then a notebook at their desk at home is the second best option.
Yep, just like you would with a normal password. Pashword is not a password manager replacement, it's just a helper for when you wanna generate strong passwords that you re-generate anytime.
> 2. Poor control over the length of the passwords - you only provide 3 options, and 20 characters is pretty low.
The point is to not remember the password length for each website, hence the 3 options.
> You can't exclude certain certain characters - yes, it's stupid for companies to not allow certain characters in the password, but many sites still do so.
You can, actually. Just press the 'Not working?' button :)
> 4. If I try to just put in an app name, you tell me to use a real URL.
Oh right, that's a valid point. I'll remove the domain requirement.
> 5. It was SLOW. Maybe it's just busy, but I'd rather not have to generate the password every time.
The algorithm is pretty computation heavy, to avoid brute force attacks even with ASICs. If you use Bromite, the privacy settings can cause issues with the website's cryptography algorithms.
> 6. Even people experienced in cryptography and hashing make mistakes. A product made by someone learning about them is... Suspect.
That's why it's open source and uses standard algorithms like Scrypt, SHA256, SHAKE256 to derive passwords. Pashword is a simple PKBDF algorithm at the end of the day.
> A password manager is 100% the better choice every time. For the people in my life who don't want to learn how to use a password manager, then a notebook at their desk at home is the second best option.
I agree that password managers are better but the second one is not a good advice. I'd argue Pashword is a much better choice.
I'm not clear on how this works. It sounds like this submits a request to change the rules for the website in question. But what happens in the meantime when you want to get your password? Do you have to click that button and fill out the form each time, remembering the rules you submitted?
What happens if multiple people submit that form, but choose slightly different options, i.e. I say "length 15", but someone else says "length 14". Presumably, the site now generates the wrong password for one of those users, and they have to either reset their password, or remember what length they used and keep going through this dialog.
> The algorithm is pretty computation heavy, to avoid brute force attacks even with ASICs. If you use Bromite, the privacy settings can cause issues with the website's cryptography algorithms.
Couldn't you just derive a base key once, and keep it cached in memory for as long as the app is open? That is, do the slow thing to generate <expanded secret>, and then when you want the password for a given website, you just compute SHA-512("<expanded secret> news.ycombinator.com johndoe") to derive the password. It'd still be slow on first launch, but not if you're keeping the app open while you browse.
The tool uses scrypt to make it hard to figure out the secret key from the generated password.
I used to use this ten years ago, but switched to Bitwarden because of this problem.
You also can use this with a password manager, that can remember your secret keys for you.
I have written the same in the FAQ at the bottom.
To really make Pashword be capable of rotation, I'd have to involve accounts and login services, which would kinda defeat the purpose of having a hashed password.
I'm wondering, can't you just vary the password length for that?
Scrypt for password stretching seems good. I see you're using CPU cost of 2^15. When storing a password hash you'd want to use 2^17 (with agility to change algorithm or increase cost in the future) [1]. Since you're not storing the result, I suspect the lower number is reasonable.
I don't like simple concatenation when building a salt from two variable length fields. You'll get the same salt for `"foo" + "bar"` and `"foob" + "ar"`, but the salt should be unique. Although I don't think that's an issue for this project since the first is a website.
Using the website in the salt has some issues when there are multiple domains that use the same password. Do I use mail.google.com, auth.google.com, or google.com? trello.com or atlassian.net? What if the website it bought and the new owner changes the domain name? With a password manager, I can just look in my vault to figure out the old domain name.
Phishing is a major way passwords are stolen and this project doesn't seem to do anything to protect against that. A browser extension (and mobile app), that checks the domain name before showing/filling the password could help.
The secret key field let me use `1234` as the key, although the color of the field was red. I think this should either prevent obviously weak passphrases or show a much more obvious warning if when one is used. Using a password found in a breach is also a bad idea (even it the password looks strong). You don't have a way to check HIBP, so users will be vulnerable if they make that mistake. It's too easy to make a critical mistake with the current design.
A bug: I filled out the form but forgot to enable JavaScript. The form posted my passphrase back to the server (https://pashword.app/?website=google.com&username=me&passphr...). I'd recommend changing the form so the submit button doesn't do anything when JS isn't loaded, otherwise the server will learn users passphrases. This is also a good place to remember that the user fully trusts that you wont steal their info (I'm not sure why anyone should trust that).
Also check out other similar projects, lots of discussion which likely applies here as well. I believe one of these supports uses a counter to support password rotation. You'd just need to remember the counter value for each site.
* LessPass - https://news.ycombinator.com/item?id=12889807
* Forgiva - https://news.ycombinator.com/item?id=12621655
Another big risk of implementing this as a website: if the website goes offline, then you can't log in. Forgiva seems defunct, for example. I'd recommend anyone who uses this to fork the git repo to have a backup.
Personally, I think there's a niche use case where this is an OK idea. I don't think the usability of this tool is right to replace 1password/bitwarden/browser saved passwords for most people. I think the FAQ could try to list out reasons why you shouldn't use this tool, the current text seems overly optimistic which may confuse someone who isn't able to evaluate the security on their own. I don't think you're making money from this tool, so you don't need to oversell it.
[1] https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
> Using the website in the salt has some issues when there are multiple domains that use the same password. Do I use mail.google.com, auth.google.com, or google.com? trello.com or atlassian.net? What if the website it bought and the new owner changes the domain name? With a password manager, I can just look in my vault to figure out the old domain name.
That's true. It is an issue. I have resorted to using just the main domain for now but yes, I acknowledge the flaw.
> A browser extension (and mobile app), that checks the domain name before showing/filling the password could help.
Yes, that's what I was working on as well :D
> The secret key field let me use `1234` as the key,
You're absolutely right! I shouldn't let people enter weak secret keys. I'll push an update.
> A bug: I filled out the form but forgot to enable JavaScript. The form posted my passphrase back to the server
Thanks a lot for reporting! I'll get it fixed.
> I think the FAQ could try to list out reasons why you shouldn't use this tool, the current text seems overly optimistic which may confuse someone who isn't able to evaluate the security on their own. I don't think you're making money from this tool, so you don't need to oversell it.
Thank you, will do that.
Thanks a lot for checking it out, I really appreciate it :)
Pashword is a nice replacement when all you need is a strong password and don't have a password manager and don't want to remember too many things.
Most people have worse security than Pashword, which is: weak passwords + same passwords everywhere. Pashword overcomes that problem. It is not better than a password manager, can never realistically be but you can use it with a password manager, to store secret keys.
It works great for me so I have no complaints, plus I got to learn a lot :)