maybe; probably the easiest way to do this is to choose a random 4-digit hexadecimal number, which gives you 16 bits when you enter it (e.g. via ctrl+u on linux). But personally I think I’d usually rather just enter those hex digits directly, for the same entropy minus a keystroke. Or, even better, maybe just type a random 3-character base32 string for one fewer bit.
If you have a nonstandard unicode character in your password and an attacker tries to crack a password based on the assumption that no nonstandard unicode character is in the password, they can’t crack your password no matter how much compute they throw at it.
Given that you decide where in your string you place it, the attacker would have to test for the special character being at multiple different positions which adds a lot of additional entropy.
Well, not that much, right? If you had an 11-word diceware passphrase to start, each word is about 7 characters on average, so you have maybe 90 places to insert a token—only 6.5 extra bits come from choosing a place to insert your character. And of course you get the same added entropy from inserting a random 3 base32 chars at a random location.
Happy to grant that a cracker assuming no unicode won’t be able to crack your password, but if that’s your goal then it might be a bad idea to post about your strategy on the public internet ;)
If you have a nonstandard unicode character in your password and an attacker tries to crack a password based on the assumption that no nonstandard unicode character is in the password, they can’t crack your password no matter how much compute they throw at it.
Given that you decide where in your string you place it, the attacker would have to test for the special character being at multiple different positions which adds a lot of additional entropy.
maybe; probably the easiest way to do this is to choose a random 4-digit hexadecimal number, which gives you 16 bits when you enter it (e.g. via ctrl+u on linux). But personally I think I’d usually rather just enter those hex digits directly, for the same entropy minus a keystroke. Or, even better, maybe just type a random 3-character base32 string for one fewer bit.
If you have a nonstandard unicode character in your password and an attacker tries to crack a password based on the assumption that no nonstandard unicode character is in the password, they can’t crack your password no matter how much compute they throw at it.
Given that you decide where in your string you place it, the attacker would have to test for the special character being at multiple different positions which adds a lot of additional entropy.
Well, not that much, right? If you had an 11-word diceware passphrase to start, each word is about 7 characters on average, so you have maybe 90 places to insert a token—only 6.5 extra bits come from choosing a place to insert your character. And of course you get the same added entropy from inserting a random 3 base32 chars at a random location.
Happy to grant that a cracker assuming no unicode won’t be able to crack your password, but if that’s your goal then it might be a bad idea to post about your strategy on the public internet ;)
If you have a nonstandard unicode character in your password and an attacker tries to crack a password based on the assumption that no nonstandard unicode character is in the password, they can’t crack your password no matter how much compute they throw at it.
Given that you decide where in your string you place it, the attacker would have to test for the special character being at multiple different positions which adds a lot of additional entropy.