Jude DaShiell wrote: > 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.
It is interesting what people can come up with. Thing is, if one uses a true random generated password, they are hard to crack but also hard to remember. I try to come up with something that will be hard to crack but easy for me to remember. Thing is, I do have a few passwords to keep up with. I recently changed my root password. I plan to change my user password soon. Then I have the password for Bitwarden. Then I have the password for the NAS, three external hard drives with different passwords for each etc. That's a lot to remember. To be honest, it's getting to be a bit much. Associating one password to one item is also difficult. Unless one leaves clues. Thing is, those clues reveal things as well. For websites, I really like Bitwarden. I remember one password and it can generate passwords for all the websites I use. The passwords it generates are pretty random. For sites that don't allow symbols, I can turn that off. The big point, I only remember one password. Thing is, on one hand I need help remembering all these passwords. On the other hand, that is a risk itself. This reminds me of a tennis ball. It just goes back and forth. Dale :-) :-) > 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 >> >
