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

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to