You can take this a step further to segregate passwords as well.
Reusing passwords across devices is bad. If one gets compromised you don’t want a password being out into a brute force table to be used with all your other accounts elsewhere.
This method of tagging using HTML markup styles in your passwords lets you keep the same core passphrase but alter the tagging, specific to the service.
You can do this easily while also giving you artificial password complexity.
Example:
Core passpgrase is “yogurt”
Password for gmail becomes markup with a yogurt
I only need to remember yogurt.
Every device just gets a truncated service tag appended to the beginning and end using HTML style tags.
Suddenly you have a 26+ character password that you don’t forget and doesn’t compromise you across other services because each is different.
Right, there shouldn’t be an easy to decipher password rule. Random passphrases seem to make the strongest passwords these days, especially if symbols, numbers, and spaces are allowed and used. Even the strongest password should have 2FA, and even that is only as strong as the identity verification of the password/2FA reset process.
Depends on the implementation of different login services and the number of possible permutations. An attacker will probably get locked out of trying to log in after making dozens of guesses.
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 yogurt.
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.
I’m not an expert but I think this is code that can be used to make text larger and bolder- in other words, STRONG text.
And you can see that the text being modified by those commands, in the middle of them… is ‘Password’
So they’re literally creating a Strong Password
You can take this a step further to segregate passwords as well.
Reusing passwords across devices is bad. If one gets compromised you don’t want a password being out into a brute force table to be used with all your other accounts elsewhere.
This method of tagging using HTML markup styles in your passwords lets you keep the same core passphrase but alter the tagging, specific to the service.
You can do this easily while also giving you artificial password complexity.
Example:
Core passpgrase is “yogurt”
Password for gmail becomes markup with a yogurt
I only need to remember yogurt.
Every device just gets a truncated service tag appended to the beginning and end using HTML style tags.
Suddenly you have a 26+ character password that you don’t forget and doesn’t compromise you across other services because each is different.
Sure they are different, but if somehow someone finds out just one password of yours, all others are broken too, right?
Right, there shouldn’t be an easy to decipher password rule. Random passphrases seem to make the strongest passwords these days, especially if symbols, numbers, and spaces are allowed and used. Even the strongest password should have 2FA, and even that is only as strong as the identity verification of the password/2FA reset process.
Even rigid, known password rules are fine as long as there are enough possible combinations. xkcd.com/936/
Depends on the implementation of different login services and the number of possible permutations. An attacker will probably get locked out of trying to log in after making dozens of guesses.
You don’t partially decrypt passwords. You either get the full thing or you get gobble.
So if they get 1, they still don’t know you use or or etc. I wouldn’t just straight up say “Netflix” in my service tagging.
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 yogurt.
Notice how I didn’t just use the service name?
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.
Just use a password manager
Hmmm. No.
L
Or use a password manager you monster.
Merica means freedom to do dumb things. Lemme fly!
https://dev-to-uploads.s3.amazonaws.com/i/it0fk0jbqphcgecnpbq7.jpg