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 :)
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...