Tag Info

New answers tagged

3

As @Rook says, a good starting point is the kernel source code itself, precisely the drivers/char/random.c file. It begins with a long description (as comments), including this passage: Sources of randomness from the environment include inter-keyboard timings, inter-interrupt timings from some interrupts, and other events which are both (a) ...


1

Here's a short bash only script that uses ASCII printable characters: [[ $1 == [1-9]* ]] && length=$1 || length=12 n=0 until [ $n -eq $length ]; do c=0 until [ $c -gt 32 ]; do c=$((RANDOM%127)) done printf "\x$(printf %x $c)" ((n++)) done echo where the first argument specifies the length of the password written to ...


0

I know you asked for one line, but it's really more robust with more. ;-) The major work can be compressed down to one line if you want to eliminate the error checking and compatibility across different versions of the base64 utility; this implementation works on both OS X and Linux. (see the create_password function, and replace do_base64 with just plain ...


5

A one-liner to create a readable and relatively easy-to-remember password: cat /usr/share/dict/words | shuf -n 4 | tr '\n' ' '| tr -d \' Example output: correct horse battery staple If you want a longer password, change the 4 to a higher number. For a password without spaces, add an escaped space to the end of the line: cat /usr/share/dict/words | ...


7

Using pwgen Simplest oneliner ever: pwgen It attempts to make passwords that are easy to remember. To disable that and create more secure passwords, use the --secure or -s flag. pwgen -s Are the generated passwords too long? Too short? Just append the desired length: pwgen 9 # Or pwgen -s 9 # Or pwgen 9 -s Similar tools I just happen to know ...


0

uuidgen will provide you with a UUID; remember to check which version of UUID it generates on your computer as some versions will allow someone who snoops your password to track it to your computer, which may (probably is) a security issue. You can use uuidgen -r to make sure that the ID only consists of random(ish) digits and cannot be tracked to you. ...


1

For the random information to be readable, we can encode it in base64. One character in base64 has 6 bits of entropy. Thus, for 128 bits of entropy you need 22 characters (128/6=21+⅓). This leads us to the command: base64 < /dev/urandom | head -c 22 Which can be translated in English by "generate cryptographic quality random data with /dev/urandom and ...


1

I would use apg with 16-byte seed from /dev/urandom (maximum allowed) apg -a 0 -d -m 15 -n 1 -c "`head -c16 /dev/urandom`"; echo You can chain the apg commands so you can have longer password from more entropy.


43

It depends on what you mean by "readable". If you want to use only hexadecimal characters, you will need 32 of them to reach 128 bits of entropy; this line will work (using only commands from the coreutils package): head -c16 /dev/urandom | md5sum This variant produces passwords with only lowercase letters, from 'a' to 'p' (this is what you will want if ...


20

Some fab suggestions in the other answers. I find that makepasswd is not available everywhere, and using tr is (slightly) tricky, so there's another option using OpenSSL: openssl rand -base64 16 The number is the number of bytes of randomness - so 16 bytes for 128-bits of entropy.


3

There is a package called makepasswd which can do this. $ makepasswd --chars 64


10

Depending on the type of characters you may include, an easy command to create a readable password with 128 bits of entropy looks like this: < /dev/urandom tr -dc [:graph:] | head -c20; echo; (Taken from here). [:graph:] are all ascii pritable characters except space. Explanation: 128 bits are equivalent to 3.40e+38 combinations. If you're using the ...


4

Statistical tests like the one you use cannot detect whether /dev/urandom is good or bad on a specific machine. Specifically, /dev/urandom runs a cryptographically secure PRNG. From a given initial internal state (the "seed"), it produces an arbitrarily long stream of seemingly random bytes. The PRNG being cryptographically secure means that for an attacker ...


0

Increasing the kernel's entropy counter requires the RNDADDENTROPY ioctl. The easiest way to call it is to use the rngd daemon from the rng-tools package: rngd -r /path/to/F (Note: rngd expected this to be a hardware device, so when it reaches the end of the file, it will complain that the entropy source is no longer working.)


6

First of all, to answer your question directly: This cannot be done. It is purposefully not allowed. You can, in fact write to /dev/random and it will mix your input into the random pool, potentially improving the quality of the output. But it won't update the entropy_count and unlock /dev/random for reading, because that would be cheating. Otherwise you'd ...


1

Given everything you said, you should probably read directly from your file instead of from /dev/random. As you apparently don't trust how /dev/random works (perhaps you read this paper) then be declarative, and don't place your trust in it. You should realize by now that there should be no way anyone can be allowed to inject data directly into the entropy ...


6

The weak point in any security strategy is always human predictability. Any clever password that you can think of, and remember, will be remarkably similar to a lot of other clever passwords people use. We just aren't as unique as we believe ourselves to be. People essentially think and memorise things in well understood and predictable ways. Some basic ...


0

On most Linux systems, the entropy pool used by /dev/random is initialized at boot using /var/run/random-seed. If this process were omitted, then two identical servers using the same distribution of Linux may have an identical boot sequence and would therefore have an identical /dev/random state. To prevent this from happening, upon shutdown the current ...


3

Yes, in particular in the light of "practical purposes" for the non-NSA type of attacker. For online passwords, the rate at which attacks on the password can be done is limited. Also, there usually exist security exploits (customer service being the single biggest security exploit by design) which are often much more vulnerable than your password. Why waste ...


25

Short answer: The more the better, but for now this is probably enough. There is an important distinction between hacking into your Gmail and cracking an offline password. If you want to hack a Gmail account by guessing the password, you can only do a few tries per second at most. Google will block thousands of login attempts to a single account in too ...


3

I think so, but its important to understand true entropy when it comes to how computers brute force. A word in the dictionary in any language can be thought of as a character, similar to a chinese character. And there are common words and uncommon words. Uncommon words can be thought of as having a very large alphabet, common words having a much smaller ...



Top 50 recent answers are included