Okay but there is literally a strong tag?? <strong>password</strong>
this post was submitted on 05 Jan 2024
297 points (100.0% liked)
196
16449 readers
2147 users here now
Be sure to follow the rule before you head out.
Rule: You must post before you leave.
founded 1 year ago
MODERATORS
You need letters, NUMBERS, and symbols. So you may still want to throw an tag in there.
Thanks for closing it
I'm not a monster! But actually, either Lemmy or Voyager added the closing tag automatically, I didn't at first.
That's interesting! Imagine being the developer who threw that edge check in there on the off chance that this would happen.
missed a / on the closing body tag in the confirmation field.
Which ironically increases the password strength.
Wait I just noticed :O
explanation for the tech illiterate (me)?
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.
Just use a password manager
Hmmm. No.
L
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.
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.
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
It's basically the "code" (markup, really) for showing the word "password" on a web page.
'well actually' a file simply containing password (with no tags) will also render (on >99% of browsers). the body and h1 tags only make the text bigger and more semantically clear. if you really want to be semantic and use w3 standards, you should use !DOCTYPE html and html as well.
for the tech illiterate (me)?
;P
In HTML, this would write "password" on the page as header(aka, big) text
Hmmm ...
“Password cannot contain username”
“Password must contain digits”
“Password cannot contain reversed misspellings of predynastic Egyptian pharaohs”
And now…
“Password cannot contain JavaScript”