I made a palette for colour space conversions for reference: https://imgur.com/a/2vgFsT4

  * $30 (not missing a zero)
  * OpenWRT support
  * 128MB RAM
  * 3 gigabit ethernet ports
  * 802.11ac Wi-Fi

[0] https://github.com/jazzband/pip-tools

Why would one want to infer the requirements file? Would that be like `pip list --not-required --format-freeze`?

  pip-compile # resolve and pin the dependency tree
  grep '==' requirements-pinned.txt | xargs -n1 pip wheel  # build every wheel in parallel
  pip install *.whl  # install the pre-built wheels

It still happens from time to time, but if somebody else read this comment, you want to check how many wheels you build before doing so.

Also, you may want to cache those build once and for all.

I love pronounceable passwords, but there's research indicating that such generators typically produce lower than expected entropy. Do you mind sharing what algorithm you use?

This representation is my favorite:

The 84-bit number 10231239242746186561668573 can be represented as: ...

In 12-bit words of 5 letters or less: hits towel bloke gala blah jimmy barry

Diceware is good too.

A word of warning: be careful playing around with stochastic text generation if you're susceptible to delusions and hallucinations. You'd have to be pretty far gone to think "hits towel bloke gala blah jimmy barry" was a message from God, but of course we all know people who have fallen into that kind of belief, and the strain on credulity gets smaller as the text model gets more sophisticated.

By contrast, trying every phrase of 20 words or less in every book that has ever been published would only take something like 129 million × 19 × 500,000 = 1.225 quadrillion tries. At a billion tries a second, that's only two weeks. (And if the password hash is inadequately salted, the attacker can use a rainbow table and put in that effort ahead of time and distribute it across all the victims.)

An attacker with more resources might devote a million CPUs to the problem, which would cut the time to success from 300 million years down to only 300 years (assuming a billion tries a second). In the next few decades it will become practical to devote much larger amounts of computation to problems like this, so such an attack might succeed, but currently it is beyond the capabilities of all but a few adversaries. And, as I understand it, Grover's algorithm will enable a large enough quantum computer to solve your password in only 2⁴² tries, which is only about four trillion tries, under an hour at the billion-tries-per-second speed I suggested above. I'm not sure, but I think it would need to prevent qubit decoherence for that period of time.

You can get equivalent security with a shorter password that looks like random gibberish, such as b7fc d750 9a52 ad6a e48c a, eedgckeimbjdefhcjclmghh, mgujdlrgdfmadtlidu, 1qvrx21zego0scvyi, 17uUPBKnfX7fSNY, >4h)&crV,+E{O, or 宜潨阰揫難侌, but those are a lot harder to memorize. They're shorter to type, though, and they're less vulnerable to side-channel attacks.

Looking random isn't good enough, though. They need to actually be random.

  #!/bin/bash
  pickaword() {
        WORDFREQFILE=/usr/share/dict/cracklib-small;
        WORDLENGTH=$1;
        awk -v wordlength="$WORDLENGTH" 'length($1) == wordlength {print $1}' "$WORDFREQFILE"|shuf|head -n 1;

    }
  [[ ! -z $1 ]] && numWords=$1 || numWords=4
  separator="-"
  count=0
  currentWord=""
  while [[ $count -lt $numWords ]]; do 
    [[ $count != 0 ]] && echo -n $separator
    num=$((3 + RANDOM % 10))
    word=$(pickaword $num)
    echo -n "$word"
    count=$(($count + 1));
  done
  echo ""

Modulo operations like these are another thing to avoid. To get equal chances for each word, the simplest thing to do is e.g.

    do
      wordlistlength = 10e3
      randomnumber = os.urandom(1) * 256 + os.urandom(1)
    while randomnumber > wordlistlength
    return wordlist[randomnumber]

Further, I see that cracklib-small is 52k words. That's not good or bad, but it makes the default 4-word phrase 52e3⁴ ~ 63 bits of entropy, which isn't terrible but in my opinion on the short side as a default. It will be perfectly fine if you only ever want to defend against online attacks, but in some cases (think disk encryption or password manager) offline cracking should be kept in mind and for the rest you should usually use a password manager anyhow (so then memorability doesn't matter).

Or perhaps more succinctly: please don't roll your own crypto.

I understand that this is of course very unlikely to be abused if it's just for yourself and nobody knows of this weakness in your credentials (security through obscurity works... until it doesn't), but one day someone will use this as inspiration or it will spread somehow, say through an HN comment... just use good password generators or at least keep insecure ones secret.

Btw: many standard Debian(-based) installations have /usr/share/dict/words available so you don't need an extra install; I haven't seen cracklib used before but that might just be me.

Also, why do we avoid modulo operations?

$RANDOM provides 15 bits of randomness (32768 possible values) from an LCG[1] - https://en.wikipedia.org/wiki/Linear_congruential_generator

LCGs are multiply followed by add followed by modulus, which is usually implied by a mask or a native word bit length rolling over. You should observe that multiplies have patterns in the lower digits which an add will only offset, and the modulus will only throw away high bits rather than mix them back in to the low bits. Consider the low digit in multiples of 7 (what you'd get picking a number between 0 and 9 inclusive via modulus):

    7 -> 7
   14 -> 4
   21 -> 1
   28 -> 8
   35 -> 5
   42 -> 2
   49 -> 9
   56 -> 6
   63 -> 3
   70 -> 0
   77 -> 7
   84 -> 4
   91 -> 1
   98 -> 8
  105 -> 5
  112 -> 2
  119 -> 9
  126 -> 6
  133 -> 3
  140 -> 0

But again, don't use an LCG for generating your password.

[1] I looked at the source. Bash looks like it tries to use random(3) if it's available, otherwise it seems to use this, which doesn't have an add:

  x(n+1) = 16807 * x(n) mod (m)

- It contains unusual proper names such as della, ervin, eaton, moran

- It contains a few strange letter sequences such as aaaa, ll, nbis

- It contains some words with punctuation such as ain't, don't, he'll

- It contains individual letters and non-word bigrams like tl, wq, zf

- It contains numbers and variants such as 46, 99 and 99th

- It contains many vulgar words

- Diceware passwords need spaces to be correctly decoded, e.g. in and put are in the list as well as input

[1] https://www.eff.org/deeplinks/2016/07/new-wordlists-random-p...

I think you copy-pasted it from elsewhere on HN, causing the end to be cut off.

Actually, I do mind. And so should you! I developed it myself, however, and feel reasonably confident about it.

Note that this advice is for the average, common site. If you have special considerations for your bank, broker, or similarly high-value sites, different advice might apply of course (but this is not really the place for that and there are already enough recommendations online).

I wonder which way round is actually the right way to say it?

    with open('/dev/urandom', 'rb') as f:
        return base64.urlsafe_b64encode(f.read(12))

    </dev/urandom tr -dc a-zA-Z0-9 | head -c 16

Security level: log((26+26+10)¹⁶)/log(2) ~ 2⁹⁵ (95 bits of entropy), comparable with adding those 12 extra symbols: log((26+26+10+12)¹⁶)/log(2) ~ 2⁹⁹. (Adding a character makes more sense than adding a symbol if you want more security, all else being equal of course.) If a stupid application still has outdated password requirements (thankfully this is rare among the applications I use) then one can of course add the classic ! at the end.

    cat /usr/share/dict | shuf -n 4 | tr '\n' '-'

> Please don't use $RANDOM or $((RANDOM)) or standard `shuf` for password generation. These RNGs are not cryptographically secure. Use input from /dev/urandom instead.

The same with gshuf.

I use an alias to add this switch by default.

(Sorry I had to)

Made this for (and have not touched it since) my last job search.

Design-wise I'd like to dial back the animation and minimalism a bit, and bump the contrast. Also have been thinking about adding more written content like blog posts or technical whitepapers.