No! This is bad from a security perspective based on entropy.
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.
I agree that this is a bad scheme, but I think the hash rounds do serve a purpose, which is to protect from sites with no/weak hashing. If a list of passwords gets leaked, it will be intractable to derive your secret from your password.
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.
There are cernainly pros and cons to deterministic password generators compared to password managers, but I don't see why there would be a difference entropy-wise. Weak master password to a password manager presents the exact same risk as a weak "secret key" in this app.
> Doing a large number of hash rounds has zero effect on actual security here
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.
- 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
You might also run into trouble with random password format requirements - too long, too short, not enough special characters, the wrong kind of special characters, ...
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 :)
Other people have hit on some/all of these issues, but here's my list of why I would never consider using this, and would do everything I could to convince friends and family never to use it either:
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.
Not so much on the technical side, but from a product perspective I can't get over how the name, when spoken aloud, sounds like it's had a couple drinks too many or maybe lost its upper denture plate.
How is using this tool different from manually concatenating (website name + username + secret key), e.g. “reddit$myname$123456”? Since Reddit would hash it anyway, this plaintext string should be as secure as a Pashword.
Concatenating leaks your secret key to the website. If a hacker can add JavaScript to the login page of _any_ site you use, then they can record your plaintext password and log into _every_ site you use. Given the reddit password it's immediately obvious that "facebook$myname$123456" is your facebook password.
The tool uses scrypt to make it hard to figure out the secret key from the generated password.
I like the idea but having people give you their username and then generating the password for them is clearly a security risk since it's easy for that to be hacked and the save the passwords it's generated for people.
Am I misunderstanding something or is this not just replacing one password with two salts and another password? What benefits would this have over just generating a password?
You would, in theory, just need to remember your one strong password, like with a password manager (except 2fa and such). The benefit is that you don't need to store anything, just remember your master password and the "salts" are obvious to you, but an attacker with the clear text password would not be able to differentiate a random password to a pashword result. From the generation time and cpu usage on pashword I'd also guess bruteforce is very hard even if you would know it's generated.
There have been various implementations of this over the years (eg HashPass), and their biggest drawback is that as soon as your bank (or whatever site) forces you to change your password, you're stuck.
I used to use this ten years ago, but switched to Bitwarden because of this problem.
True, rotation is an issue. This project is a bit more reasonable for people who don't use Password managers (because of some reason, like many members in my family).
You also can use this with a password manager, that can remember your secret keys for you.
You would need to change one of your inputs unfortunately.
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.
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.
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.
Thanks a lot for the feedback and analysis, really helps me learn more :D
> 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 :)
[+] [-] timvisee|3 years ago|reply
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.
[+] [-] mistercow|3 years ago|reply
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.
[+] [-] entropyneur|3 years ago|reply
[+] [-] dandanua|3 years ago|reply
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.
[+] [-] PufPufPuf|3 years ago|reply
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
[+] [-] sigio|3 years ago|reply
I'll just stick with passwordstore.org and bitwarden/vaultwarden
[+] [-] shudza|3 years ago|reply
[+] [-] danbruc|3 years ago|reply
[+] [-] NayamAmarshe|3 years ago|reply
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 :)
[+] [-] tallanvor|3 years ago|reply
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.
[+] [-] shudza|3 years ago|reply
[+] [-] throwanem|3 years ago|reply
[+] [-] rkagerer|3 years ago|reply
[+] [-] crazylogger|3 years ago|reply
[+] [-] 8organicbits|3 years ago|reply
The tool uses scrypt to make it hard to figure out the secret key from the generated password.
[+] [-] johnnyfaehell|3 years ago|reply
[+] [-] voytec|3 years ago|reply
[+] [-] PythagoRascal|3 years ago|reply
[+] [-] YellowTech|3 years ago|reply
[+] [-] stavros|3 years ago|reply
I used to use this ten years ago, but switched to Bitwarden because of this problem.
[+] [-] NayamAmarshe|3 years ago|reply
You also can use this with a password manager, that can remember your secret keys for you.
[+] [-] jonwinstanley|3 years ago|reply
[+] [-] NayamAmarshe|3 years ago|reply
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.
[+] [-] figassis|3 years ago|reply
[+] [-] alex_suzuki|3 years ago|reply
[+] [-] totetsu|3 years ago|reply
[+] [-] XiS|3 years ago|reply
[+] [-] NayamAmarshe|3 years ago|reply
[+] [-] BrightOne|3 years ago|reply
[+] [-] wink|3 years ago|reply
[+] [-] NayamAmarshe|3 years ago|reply
[+] [-] jdthedisciple|3 years ago|reply
I'm wondering, can't you just vary the password length for that?
[+] [-] 8organicbits|3 years ago|reply
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
* https://spectre.app/
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...
[+] [-] NayamAmarshe|3 years ago|reply
> 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 :)
[+] [-] substation13|3 years ago|reply
[+] [-] NayamAmarshe|3 years ago|reply