Suddenly you have a 26+ character password that you don’t forget and doesn’t compromise you across other services because each is different.
It depends on what is compromised and how the attacker operates. If the attacker has your plaintext password instead of just a (hopefully salted) hash AND targets you individually instead of just having your password in a giant list of login-info to automatically try on other services then it’s trivially easy to guess that e.g. your Spotify password is <Spotify>yogurt</Spotify>.
Whatever nickname you use for your services. There is no requirement you also use the service name in the tagging template.
The idea that a breach of a service would have someone looking at your individual password is also pretty silly. There would be variations and pattern matching Lagos run against lists of hundreds of thousands to millions of passwords… but the decryption of a complete password to plain text is so reductions at this point, we are talking about the 0.01% case of a then even more silly “let’s look at this guys password in particular” 0.0001% case on top of it…
It’s not a real problem because if your service is at the point it is leaking not just salted and hashed passwords, but plain text passwords: you are in a big problem up no matter what for most users. Almost everyone reuses passwords. The real risk is the simple reuse. Get just a slightly different variation and you are miles more secure in the case of a breach that results in full decryption.
The majority still reuse Password1234! Everywhere. This gives you a easier way to be miles better.
Better still of course is some sort of managed password vault, assuming you trust their implementation. However, this costs zero in the training, or tech literacy upskilling that even the moderate change to a password vault requires. It’s simply an extension of what people already intuitively know. Thus, barrier to entry is easier while giving you several orders more protection.
It depends on what is compromised and how the attacker operates. If the attacker has your plaintext password instead of just a (hopefully salted) hash AND targets you individually instead of just having your password in a giant list of login-info to automatically try on other services then it’s trivially easy to guess that e.g. your Spotify password is <Spotify>yogurt</Spotify>.
Notice how I didn’t just use the service name?
<Disco>
<Netfucks>
<MailGoog>
Whatever nickname you use for your services. There is no requirement you also use the service name in the tagging template.
The idea that a breach of a service would have someone looking at your individual password is also pretty silly. There would be variations and pattern matching Lagos run against lists of hundreds of thousands to millions of passwords… but the decryption of a complete password to plain text is so reductions at this point, we are talking about the 0.01% case of a then even more silly “let’s look at this guys password in particular” 0.0001% case on top of it…
It’s not a real problem because if your service is at the point it is leaking not just salted and hashed passwords, but plain text passwords: you are in a big problem up no matter what for most users. Almost everyone reuses passwords. The real risk is the simple reuse. Get just a slightly different variation and you are miles more secure in the case of a breach that results in full decryption.
The majority still reuse Password1234! Everywhere. This gives you a easier way to be miles better.
Better still of course is some sort of managed password vault, assuming you trust their implementation. However, this costs zero in the training, or tech literacy upskilling that even the moderate change to a password vault requires. It’s simply an extension of what people already intuitively know. Thus, barrier to entry is easier while giving you several orders more protection.