The comments have ping-ponged around making it difficult to see the whole. Rather than play whack-a-mole, here is a summary.
First, let's remember that any password scheme must improve on best practice. Best practice is to use a good password manager with a good password generator.
Let's also remember that security is only as strong as its weakest link. It doesn't matter how awesome your door is if I can go in through the window. Any single weakness invalidates the whole scheme. All weaknesses must be addressed.
Finally, a system's security is evaluated not as an ideal, but how it's actually used. The OP's question presented an ideal, but over the course of comments and edits we find that it's used rather differently in practice.
Passwords are only as strong as the key, and every password exposes the key to attack.
The main flaws in this system are that every password exposes the key to attack, and the strength of all passwords rests on how hard it is to brute force the key.
To brute force the key, one needs the a password, the salt, the prefix, and the process.
You do not control the security of your passwords, one must assume they will leak. The salt is, by design, easy to guess. The prefix can be discovered by comparing multiple passwords. Kerckhoffs's principle says we must assume the process is exposed.
The choice of an inappropriate hash algorithm makes brute forcing easier than it should be. And, as we'll see, once you start making passwords this is increasingly laborious to fix. Similarly, the key cannot change; you're stuck with an increasingly weak key.
Password managers have none of these flaws.
Ideal vs Practice
The ideal version of this scheme makes these claims about its usability.
- One only needs to remember the key.
- It's stateless, nothing needs to be written down.
- The process of choosing a salt is simple and easily remembered.
- No 3rd party needs to be trusted.
- It can handle "all of my online passwords".
These don't hold up in practice.
- One needs to remember two things, the key and the prefix(es).
- Salts and prefixes are written down because...
- Corner cases mean salting is complex and multiple prefixes are required.
- One can chose to trust insecure services with the key, prefix, and passwords.
- It cannot handle all online passwords without compromising security and usability.
In contrast, a good password manager...
- Only requires remembering the master password.
- Has state, but it's all encrypted.
- Has no algorithms to remember.
- Is audited by professionals.
- Can handle all secrets.
Too many important decisions must be made by the user.
The user must choose a hash algorithm, hash method, key, prefix, and salt procedure. All of these have an impact on usability and security. None of these should be made by the user.
For example, the OP chose an inappropriate hash algorithm making brute forcing the key easier. They used an untrusted site to do the hashing exposing everything. Their salt process is insufficient to cover all cases requiring some service names to be written down degrading usability. The chosen prefix may be inadequate to cover all password requirements.
The scheme can be improved by having professionals recommend choices for the user, but the user can still ignore them.
A good password manager has none of these flaws. The entire process is created by professionals, constantly reviewed and improved, and handled by the software.
Poor choices cannot be fixed.
In this scheme, a password relies on four pieces.
- The key
- The prefix
- The salt process
- The hash algorithm
Change any one of these and all passwords must change. This makes the system very brittle and has many consequences for security and usability.
Needless to say, a good password manager has none of these flaws.
For the remainder, for brevity, when I say "it cannot change" please read "it cannot change without changing all passwords". And if change is difficult, the user is likely to make compromises with their security.
The hash algorithm cannot be changed.
It's important to be able to change your hash algorithm should a weakness be exposed. A good system would be able to quietly swap in a better algorithm for passwords going forward.
SHA-512 is an inappropriate choice making it easier to brute force the already over-exposed key.
A password manager takes care of this for you.
The key will be increasingly compromised.
While mandatory password rotation has gone out of vogue, it remains a security cornerstone that you need be able to change your keys upon any suspicion of being compromised. The simpler the process the more likely you are to use a fresh key at any hint of a vulnerability.
If you chose a weak key, you cannot chose a better one. As computing power becomes stronger, you'll need a stronger key.
With a password manager, you can change your master password as often as you like.
The salting procedure will be inadequate.
To avoid writing salts down, the procedure to get a salt for a service must be flexible enough to accommodate all situations, yet simple enough to remember and be done in your head.
It's likely the user will pick a simple scheme and find it increasingly inadequate. Here's a few corner cases...
- Is github.com "Github" or "GitHub?
- If foo.com is "Foo" what is foo.us?
- How do you store foo.github.io?
- Will you realize that foo.io used to be foo.github.io?
The procedure cannot predict all situations, or it is so complex it cannot be reliably done in your head. The inevitable result is some service names must be written down decreasing usability and security.
The salting procedure may also drift over time as it's subtly changed to accommodate more edge cases. It may become incompatible with older passwords.
A password manager needs no such procedure.
One prefix does not fit all.
While password policies are finally going away, they're still around, and they're often nonsensical and contradictory. With this scheme one must, up front, choose a prefix which will cover all possible cases. This unlikely and perhaps impossible.
Edge cases require a special prefix just for one site, requiring them to be written down, decreasing usability and security.
A good password generator can accommodate most policies. If not, you can manually alter the generated password.
It cannot be safely shared.
Let's say, I want to have a shared set of passwords. Maybe for work or a project or with family.
With a good password manager I can create tertiary keys, hand them out, and, most importantly, revoke them. The vault can be made available either via the cloud or simply copying it. I can create shared vaults and choose which passwords are shared.
With this scheme, one must share the key, prefix, hash algorithm, and explain the salting procedure. The receipients must be willing to jump through all these hoops exclusive to this system. None of this can be revoked. All passwords are exposed, including future passwords. If one person compromises the key or prefix, everything is compromised. If you want to share only specific passwords you need to come up with and remember a new key and prefix and remember which passwords were generated with which key and prefix.
Difficult to backup.
One could store the key and prefix(es) and special salts and hash algorithm in a safe location. But one also has to write down an accurate description of the increasingly complex salting procedure. Anyone who reads documentation knows how difficult that is.
With a good password manager, one stores the vault key in a safe location and backs up the vault. Since the vault is encrypted it can be backed up anywhere.
How secure is this hash-based personal password scheme?
It's more secure than reusing a few easy to remember passwords. Compared to a good password manager and randomly generated passwords it's much harder to use, less featureful, and much less secure.
If you're allergic to commercial software, use open source. If you don't trust cloud storage, store the vault locally. If you want it available anywhere, store the vault and software on a thumb drive on your key ring.