1. 20
    1. 5

      Reminds me of Format Transforming Encryption (FTE) which can encrypt data such that the ciphertext conforms to some regular expression. Its purpose was in subverting regex-based DPI engines used for network censorship, for example by making the ciphertext look like an ordinary HTTP connection.

      A weakness of this approach (in evading detection) is that the ciphertext is oblivious to what it’s actually mimicking, e.g. the ciphertext wouldn’t necessarily conform to the protocol specification (e.g. the Content-Length header wouldn’t match up with the size of the body)

      However, it seems quite applicable here since any cryptographic cipher can be turned into a makeshift CSPRNG by encrypting random noise

      1. 3

        Interesting! That kinda reminds me of tor’s pluggable transports. At least it sounds like they try to achieve the same thing.

        1. 4

          There is in fact a Tor pluggable transport that uses FTE: https://blog.torproject.org/tor-heart-bridges-and-pluggable-transports/

          The project is here: https://github.com/kpdyer/fteproxy

      2. 1

        Would it be sufficiently high entropy to generate a random key, use “aaaaaaaaaaaaaaaaaaaaaaaaaa” as the input encrypt it, and use the encrypted text as the password ?

        1. 1

          Yes, ciphertext is indistinguishable from random: https://en.wikipedia.org/wiki/Ciphertext_indistinguishability

          However I’ve not attempted to generate passwords with FTE myself, so you can try it for yourself

    2. 4

      Just a nitpick, but:

      For example, you might use a regular expression like [a-z.]@yourcompany.com to validate if something is a valid company email address

      is a rather strange regex (usernames can be any character, but only one).

      1. 6

        Late joiners will have to pick something from a higher unicode plane.

      2. 2

        even nittier pick - it’s a single lowercase a to z plus full-stop, isn’t it?

        1. [Comment removed by author]

        2. 1

          No, the . matches any character.

          EDIT: actually according to regexr’s explainer it’s a literal full stop… wtf? why does the context change the behavior of that?

          1. 2

            It’s a character group. The only character I know off the top of my head that means something inside one is ^ and that only at the beginning to mean “match the inverse of this group “

          2. 1

            no, inside [] characters are literal and define sets. Neither . (any) nor ?, + or * (cardinality) make sense here, so they are literals.

      3. 1

        Fixed that! Thank you :)

    3. 2

      frankly I go with XKCD 936 an while I don’t agree with all the math, I made https://codeberg.org/mro/xkcd936 and prefer typeable phrases over alphabet soup.

      1. 2

        That is really cool, another implementation of that XKCD! And in only like 20 lines of OCaml, impressive :)

    4. 2

      Semi related: My coworker created https://github.com/rpdelaney/dumbpw for, well, dumb sites with dumb password rules

    5. 1

      Neat!

      A tiny mistake I noticed: the example passwords for “ generated by older versions of safari” and “ generated by current safari” are identical.

      1. 1

        Gotcha! I fixed that, seems like I should have proofread that. Thanks for the hint :)

    6. 1

      Maybe this is useful in some special cases, but like other comments here, I would prefer simple list of words. For an xkcd 936 style password, this is enough

      for i in $(seq 4); do
          sed -n $(((RANDOM+32768*RANDOM)%$(wc -l /usr/share/dict/words|cut -w -f2)))'{p;q;}' \
              /usr/share/dict/words
      done | tr '\n' '-' | sed 's/-$/\n/'