Show HN: Pashword – Hashed Password Calculator(pashword.app)
pashword.app
Show HN: Pashword – Hashed Password Calculator
https://pashword.app
54 comments
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.
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.
The difference is that you'd also have to own the password store, rather than having to know about the hashing algorithm (which is open).
> 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.
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.
Compared to "traditional" password managers:
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
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
More cons: You still need to remember the exact spelling/variant of the URL, username and password-settings
I'll just stick with passwordstore.org and bitwarden/vaultwarden
I'll just stick with passwordstore.org and bitwarden/vaultwarden
Wdym "just brute force master passwords"? You use password + secret key to generate a password. Hardly brute-forceable.
If your password leaks from a single service, and I somehow know that you use this tool, I could then try all the combinations of the secret key until the service produces the same password as the one leaked. Now I have your secret key, and can derive your other passwords.
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.
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.
Yes but if I use a proper secret key, you won't be able to brute force it. You can't brute force anything 20+ chars in a billion years (inaccurate approximation)
That would still be very difficult I believe. The algorithm is CPU and Memory intensive because I'm using scrypt internally.
Think about what would happen if everyone uses this tool and its known around the world.
The basic principle still holds: "Kerckhoff's principle is the concept that a cryptographic system should be designed to be secure, even if all its details, except for the key, are publicly known" - which seems to be happening here (caveat emptor, also this should be self-hostable).
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")
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")
Sure, if everyone used this, you'd have a copy of the algorithm used. But you're trying to solve for two unique variables, master password and secret key.
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, ...
Source Code: https://github.com/pashword/pashword
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 :)
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.
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.
> 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.
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.
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.
> You can, actually. Just press the 'Not working?' button :)
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.
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.
I like it, many people use a single password for every website, this could keep them safer. Maybe make a browser extension?
Yes, I was working on a browser extension but got busy with work. I'll get back on it as soon as I get some time :)
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.
And when the website forces you to rotate your password? Will you have facebook.com-2, facebook.com-3, etc?
That's one of the flaws. No way to really avoid this since Pashword is a hashing algorithm basically.
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.
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.
I have unwillingly read this name out loud in Sean Connery's voice.
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.
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 also can use this with a password manager, that can remember your secret keys for you.
But if I have a password manager already, why use this?
You don't have to, unless you would like to get your passwords without managing your password manager.
I have written the same in the FAQ at the bottom.
I have written the same in the FAQ at the bottom.
If a website/service forces you to update your password, can this page create a second password? Or would it rely on you changing one of the inputs?
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.
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.
Looks like this will not work if you need to change your password (eg. site gets breached). This is one of the most common use cases in password auth.
What could go wrong…
I usually just get the hackers to make my passwords for me in the first place and save everyone some time.
Still stuck in the 10s? Passwordless is the Future
I agree but sometimes, receiving a link on email is a bit inconvenient when all you're trying to do is login on someone else's device.
For prior art, see LessPass: https://lesspass.com
How is this different from PasswordMaker (in JS or adddon form) that have been around for a decade or longer?
Pashword uses Scrypt, SHA3-512 to generate passwords. It's CPU and Memory intensive so a bit on the safer side as far as ASICs are concerned.
People asking how you can rotate your password.
I'm wondering, can't you just vary the password length for that?
I'm wondering, can't you just vary the password length for that?
This is beautifully done, great design work.
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...
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...
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 :)
> 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 :)
How do you rotate passwords?
Well, that's a bit inconvenient but still possible. You need to put a counter in front of either the website or username or the secret key.
I think this is a deal-breaker. I want a password manager to track the counter for me - at which point why use hashes as passwords?
Yes, as I mention it on the website. Pashword is for people who do not want to use or maintain a password manager.
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.
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.
I appreciate what you are trying to accomplish with Pashword, but it would be better to direct people towards user-friendly password managers such as Apple Keychain (if they are in that ecosystem) or BitWarden.
I actually built it for my personal use and made it public because there might be people who are comfortable with such a thing.
It works great for me so I have no complaints, plus I got to learn a lot :)
It works great for me so I have no complaints, plus I got to learn a lot :)
and how do you keep track of the counter for each website?
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.