Good Random Password Generator? (CLI or GUI)

chrispoole · 2009-02-16 14:40:37

I've started storing my passwords in a plain text file, secured with GPG.

Does anyone know of a well-tested (i.e., produces good randomness and frequently used) password generator?

I don't care if it's CLI or GUI, but I would want it to be able to use symbols (if asked for), alphanumerics, variable length, etc.

Thanks.

buttons · 2009-02-16 14:53:05

cat /dev/urandom | guuencode -m "" | head -n 2 | tail -n 1

Cut to desired length. I use this for all my passwords.

chrispoole · 2009-02-16 15:23:05

You assume that /dev/urandom is more random than /dev/random?

I guess this is true if the entropy of /dev/random is overestimated, but I don't know how true this is in general (and I may be using this on a Mac OS X box as well as Linux).

whompus · 2009-02-16 15:23:53

pwgen is in the extra repository.

buttons · 2009-02-16 16:21:07

chrispoole wrote:

You assume that /dev/urandom is more random than /dev/random?
I guess this is true if the entropy of /dev/random is overestimated, but I don't know how true this is in general (and I may be using this on a Mac OS X box as well as Linux).

It's not, no. But /dev/random works just as well.

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered. (Source: Linux Programmer's Manual, section 4)
The intent is to serve as a true random number generator, delivering real entropy for the most random data possible. This is suggested for use in generating cryptographic keys for high-value or long-term protection.
A counterpart to /dev/random is /dev/urandom ("unlocked" random source) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random.

From the wikipedia page.

initbox · 2009-02-16 18:33:53

buttons wrote:

cat /dev/urandom | guuencode -m "" | head -n 2 | tail -n 1
Cut to desired length. I use this for all my passwords.

< /dev/urandom tr -dc A-Za-z0-9_ | head -c8

replace -c8 with -c charactercount

Berticus · 2009-02-16 20:56:27

I wrote a C program... Very easy to write.

One thing I would like to throw out there is do people consider which hand is used to type the password? Because once the password generator spat out a password that required only my left hand. Thought that would make it too easy, so now the program provides a little more spread while keeping some clusters. Not sure if I still have it, wrote it 5 years ago.

cactus · 2009-02-16 21:48:13

whompus wrote:

pwgen is in the extra repository.

i use pwgen multiple times a week. great program.

bluewind · 2009-02-17 12:54:58

apg is also nice.

moljac024 · 2009-02-17 13:43:05

chrispoole wrote:

I've started storing my passwords in a plain text file, secured with GPG.
Does anyone know of a well-tested (i.e., produces good randomness and frequently used) password generator?
I don't care if it's CLI or GUI, but I would want it to be able to use symbols (if asked for), alphanumerics, variable length, etc.
Thanks.

One question - how do you store passwords to that file ?
That is, do you for any moment save it to disk in unencrypted form ?

scj · 2009-02-17 14:27:21

I'm using keepassx, mostly because it has a windows version and it's sort of nice, except the linux version can't merge password databases.

dyscoria · 2009-02-17 14:32:13

I feel the command line password manager pwsafe should get a mention, and it has it's own random password generator function.

chrispoole · 2009-02-17 15:20:05

moljac024 wrote:

chrispoole wrote:
I've started storing my passwords in a plain text file, secured with GPG.
Does anyone know of a well-tested (i.e., produces good randomness and frequently used) password generator?
I don't care if it's CLI or GUI, but I would want it to be able to use symbols (if asked for), alphanumerics, variable length, etc.
Thanks.
One question - how do you store passwords to that file ?
That is, do you for any moment save it to disk in unencrypted form ?

Yes, I'm afraid so.

I realise this isn't exactly great security, but I do at least attempt to securely erase the plaintext file with srm.

I've just struggled to find a program that's free software, still under development, and used by trusted people so that I trust it not to have flaws in its implementation.

Barrucadu · 2009-02-17 15:54:38

chrispoole wrote:

Yes, I'm afraid so.
I realise this isn't exactly great security, but I do at least attempt to securely erase the plaintext file with srm.
I've just struggled to find a program that's free software, still under development, and used by trusted people so that I trust it not to have flaws in its implementation.

You could decrypt it to a temporary location, make the changes, and then save the new encrypted file to the permament location. When editing my GPG'd passwords file I decrypt it to /tmp, which is tmpfs.

chrispoole · 2009-02-17 16:01:08

Barrucadu wrote:

You could decrypt it to a temporary location, make the changes, and then save the new encrypted file to the permament location. When editing my GPG'd passwords file I decrypt it to /tmp, which is tmpfs.

Is this for the standard Arch kernel build? (Or indeed, the standard Linux setting?)

I understand it's stored in RAM. While I do use a laptop (so restart far more frequently than any server), I should still use srm to securely erase the file after I've finished using it?

Barrucadu · 2009-02-17 16:12:15

tmpfs is in the Arch kernel, you just have to mount /tmp as tmpfs in /etc/fstab to use it. I wouldn't think srm is necessary, as RAM is lost on power off anyway, and other things will be written over it.

moljac024 · 2009-02-17 16:17:25

How does srm compare to shred ?
In what other way could GPG be safely used in this manner for us that don't have a tmpfs ?

chrispoole · 2009-02-17 16:55:28

moljac024 wrote:

How does srm compare to shred ?

Last time I checked (few months ago), shred and srm were very similar in functionality and operation.

I believe they both implement the Guttman method for secure erasure on magnetic media.

I chose srm because it comes as standard on Mac OS X too, which I also use.

Ranguvar · 2009-02-17 20:29:59

/dev/shm is by default a tmpfs, you could use that.

Last edited by Ranguvar (2009-02-17 20:30:09)

Xyne · 2009-02-17 20:45:17

How does "wipe" compare to srm and shred?

*after reading the project web site*

Wipe specifically mentions PGP:

http://wipe.sourceforge.net/ wrote:

Utilities such as PGP and the GNU Privacy Guard provide strong encryption, but encryption is useless if the original plaintext can be recovered. When using PGP and GPG, temporary files that are disk-backed should be stored on an encrypted file system. That way, the plaintext never hits the platters. Wipe is designed for situations where an encrypted file system isn't practical.

fumbles · 2009-02-18 03:30:11

You could always use fist, fist is the best for of randomness.

First grab fist
Then move downward towards the keyboard

You password is then generated.

An example:

u8fvt674rxd

moljac024 · 2009-02-18 12:21:26

My fist just generated this:

DKLsgsdyw4UI#tyV:vucxgyp4etP(F&SD&)Ve6rwaydchSEGGUE$QO;"x"ysa*r#< l:""CR)*C"EA"$ GPC>Sa

Doesn't look so bad...

von_Wanderlust · 2009-06-02 08:40:02

Berticus wrote:

I wrote a C program... Very easy to write.
One thing I would like to throw out there is do people consider which hand is used to type the password? Because once the password generator spat out a password that required only my left hand. Thought that would make it too easy, so now the program provides a little more spread while keeping some clusters. Not sure if I still have it, wrote it 5 years ago.

If you are interested in this type of stuff... I read that this thinking helped Bletchley Park crack the German's Enigma encrypts during WWII. The Nazi code guys believed that to have two of the same letters next to each other within the 3 character combination meant that their code wasn't random enough and would change/redo the random code for that day. Once the British heard of this through their intelligence channels, they knew that they could rule out the first ring's letter from the 2nd ring, and the 2nd ring's letter from the last ring (there being 3 rings each based on the alphabet). I guess it reduced it from 17576 (26^3) to 16250 (26*25*25) possible combinations. (I hope I got that right.)

Anyway, from a practical point of view, I don't think it'll matter that much. I believe that certain big brothers have computing power that can outdo us anyday, no matter how many hands you have.

Aprz · 2009-06-02 09:25:43

moljac024 wrote:

My fist just generated this:
DKLsgsdyw4UI#tyV:vucxgyp4etP(F&SD&)Ve6rwaydchSEGGUE$QO;"x"ysa*r#< l:""CR)*C"EA"$ GPC>Sa
Doesn't look so bad...

Haha! I like that.

I use (this similar to what some folks have posted up here already):

cat /dev/urandom | tr -cd [:graph:] | fold -w $LENGTH | head -n 1

Where $LENGTH is the length you want your password to be.

Initbox, I recommend using [:alnum:] instead of a-zA-Z0-9 or better is [:graph:], which include symbols. The password to even log into my non-root account is #`o'Hyd3Ob5t. Oh no! Somebody might hack me now! :[

rine · 2009-06-02 15:18:28

Barrucadu wrote:

chrispoole wrote:
Yes, I'm afraid so.
I realise this isn't exactly great security, but I do at least attempt to securely erase the plaintext file with srm.
I've just struggled to find a program that's free software, still under development, and used by trusted people so that I trust it not to have flaws in its implementation.
You could decrypt it to a temporary location, make the changes, and then save the new encrypted file to the permament location. When editing my GPG'd passwords file I decrypt it to /tmp, which is tmpfs.

You can also use this (if you use vim that is): http://www.vim.org/scripts/script.php?script_id=661
It's really convenient. When you open a file ending in .gpg, vim asks for the password.

Arch Linux

#1 2009-02-16 14:40:37

Good Random Password Generator? (CLI or GUI)

#2 2009-02-16 14:53:05

Re: Good Random Password Generator? (CLI or GUI)

#3 2009-02-16 15:23:05

Re: Good Random Password Generator? (CLI or GUI)

#4 2009-02-16 15:23:53

Re: Good Random Password Generator? (CLI or GUI)

#5 2009-02-16 16:21:07

Re: Good Random Password Generator? (CLI or GUI)

#6 2009-02-16 18:33:53

Re: Good Random Password Generator? (CLI or GUI)

#7 2009-02-16 20:56:27

Re: Good Random Password Generator? (CLI or GUI)

#8 2009-02-16 21:48:13

Re: Good Random Password Generator? (CLI or GUI)

#9 2009-02-17 12:54:58

Re: Good Random Password Generator? (CLI or GUI)

#10 2009-02-17 13:43:05

Re: Good Random Password Generator? (CLI or GUI)

#11 2009-02-17 14:27:21

Re: Good Random Password Generator? (CLI or GUI)

#12 2009-02-17 14:32:13

Re: Good Random Password Generator? (CLI or GUI)

#13 2009-02-17 15:20:05

Re: Good Random Password Generator? (CLI or GUI)

#14 2009-02-17 15:54:38

Re: Good Random Password Generator? (CLI or GUI)

#15 2009-02-17 16:01:08

Re: Good Random Password Generator? (CLI or GUI)

#16 2009-02-17 16:12:15

Re: Good Random Password Generator? (CLI or GUI)

#17 2009-02-17 16:17:25

Re: Good Random Password Generator? (CLI or GUI)

#18 2009-02-17 16:55:28

Re: Good Random Password Generator? (CLI or GUI)

#19 2009-02-17 20:29:59

Re: Good Random Password Generator? (CLI or GUI)

#20 2009-02-17 20:45:17

Re: Good Random Password Generator? (CLI or GUI)

#21 2009-02-18 03:30:11

Re: Good Random Password Generator? (CLI or GUI)

#22 2009-02-18 12:21:26

Re: Good Random Password Generator? (CLI or GUI)

#23 2009-06-02 08:40:02

Re: Good Random Password Generator? (CLI or GUI)

#24 2009-06-02 09:25:43

Re: Good Random Password Generator? (CLI or GUI)

#25 2009-06-02 15:18:28

Re: Good Random Password Generator? (CLI or GUI)

Board footer