I generate random passwords using dice. First and last characters in passwords are letters that's arbitrary buys more time. Those should have lengths over 13 and before the agency I used to work for went to smartcards and 256 character random passwords their last standard was 16 characters with minimum two symbols minimum two numbers minimum two upper-case and minimum two lower-case. No dictionary words or keyboard walking allowed. Firewall piercing with laptops got used regularly by state actors and there is a firewall-piercing-howto file on the internet for anyone interested. The remaining characters first got their sets chosen. A 1 on dice picked a number for that spot and a 6 picked a symbol. Two or 3 picked an upper-case and 4 or 5 picked a lower-case. Once the set spots got figured five dice got used for letters add the total and subtract 4 for the particular letter. three dice got used for symbols with a single dice roll of either odd for first 16 symbols or even single dice roll for second 16 symbols. Your choice as to put which 16 symbols in the even and odd sets those could be randomized. Numbers used two dice with 2 subtracted from total and a 2 rolled with the dice returned a 0. Slow and necessary to write worksheet down as dice rolling proceeded and password needed writing down on completion. Since I do most of my writing in braille I have a good encryption system I can encrypt further by using the old English braille instead of the American braille. American braille has dot arrangement 123 down left side of cell for reading and 4 5 6 down right side of cell for reading. English braille has 1 3 5 down the left side and 2 4 6 down the right side of the cell for reading. Those are dot number arrangements. Braille readers on this list I expect maybe only one other will understand what I just wrote.
-- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Tue, 19 Sep 2023, Michael wrote: > On Tuesday, 19 September 2023 06:36:13 BST Dale wrote: > > Howdy, > > > > As some know, I encrypt a lot of stuff here. I use passwords that I can > > recall but no one could ever guess. I don't use things that someone may > > figure out like pet's name or anything like that. I use a couple sites > > to see just how good my passwords are. I try to get into the millions > > of years at least. I have a couple that it claims is in the trillions > > of years to crack. I've read some things not to use like pet names and > > such. I've also read that one should use upper and lower case letters, > > symbols and such and I do that, especially on my stuff I never want to > > be cracked. Some stuff, when I'm dead, it's gone. > > As/when quantum computers development progresses, many/some passwords and > hashes will be cracked/brute forced (RSA encryption springs to mind). It is > best if you can think of any password as keeping your door and windows locked. > They will stop most opportunistic attempts, but not anyone who is determined > to break in. It is unlikely your passwords will stop state actors. A strong > password, like a strong door lock, buys you time. Hence the general > recommendation to change your passwords frequently. > > > > In the real world tho, how do people reading this make passwords that no > > one could ever guess? > > You can use gpg, or openssl, or app-admin/apg, or app-admin/pwgen, to generate > random enough strings to use as passwords. They will be difficult to guess, > but will be VERY difficult to remember. You'll have to store them offline > and/or protect them in turn with some master passphrase you can remember. > > As an example, you could choose characters/strings from the output stored in > file.txt, when you run: > > < /dev/random tr -dc "[:space:][:print:]" | head -c500 > file.txt > > > > I use Bitwarden to handle website passwords and > > it does a good job. I make up my own tho when encrypting drives. I'm > > not sure I can really use Bitwarden for that given it is a command line > > thing, well, in a script in my case. I doubt anyone would ever guess > > any of my passwords but how do people reading this do theirs? Just how > > far do you really go to make it secure? Obviously you shouldn't give up > > much detail but just some general ideas. Maybe even a example or two of > > a fake password, just something that you would come up with and how. > > > > This is the two sites I use. > > > > > > https://www.passwordmonster.com/ > > > > https://www.security.org/how-secure-is-my-password/ > > > > > > I have a password in the first one that shows this: > > > > > > It would take a computer about 63 thousand years to crack your password > > > > > > Second one says this. > > > > It would take a computer about 5 million years to crack your password > > > > Exact same password in both. Why such a large range to crack? > > I don't know why these guys come up with different years-equivalent strength, > but I tend to treat such websites as suspicious. They are more likely to act > as a honeypot to *record* your passwords, than provide you with truly > meaningful information. I suppose you could use them to test an example of a > password you would never use thereafter, but even this could reveal some > underlying pattern in how you structure your passwords. > > > > I tend > > to use the first site to create a password. Then I test it in the > > second site to sort of confirm it. If both say a long time, then I got > > a fairly good one depending on what I'm protecting. Still, why such a > > difference? One reason I use the first site, I can make it show the > > password. The second site doesn't do that so editing it to improve > > things is harder since you can't see it. The first site makes that easy > > and gives me a idea of whether I'm on the right track. Second site > > confirms it. I did contact the second site and ask for a button to show > > the password. After all, no one is here but me. My windows are covered. > > > > Also, I use cryptsetup luksFormat -s 512 ... to encrypt things. Is > > that 512 a good number? Can it be something different? I'd think since > > it is needed as a option, it can have different values and encrypt > > stronger or weaker. Is that the case? I've tried to find out but it > > seems everyone uses 512. If that is the only value, why make it a > > option? I figure it can have other values but how does that work? > > The size of key options depend on the block cipher. A larger key size tends > to be stronger, but its processing slower. Embedded devices without hardware > accelerated crypto could struggle with larger key sizes. > > > > Heck, a link to some good info on that would be good. :-) > > https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md > > https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf > > https://wiki.archlinux.org/title/Data-at-rest_encryption >
