Groups > linux.debian.user > #185717 > unrolled thread

One-line password generator

Started by	Mario Castelán Castro <marioxcc.MT@yandex.com>
First post	2017-08-22 17:10 +0200
Last post	2017-09-04 01:10 +0200
Articles	20 on this page of 117 — 22 participants

Back to article view | Back to linux.debian.user

  One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 17:10 +0200
    Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-22 21:50 +0200
      Re: One-line password generator <tomas@tuxteam.de> - 2017-08-22 22:10 +0200
        Re: One-line password generator John Hasler <jhasler@newsguy.com> - 2017-08-22 22:50 +0200
          Re: One-line password generator Jude DaShiell <jdashiel@panix.com> - 2017-08-23 14:40 +0200
      Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 22:20 +0200
        Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 22:20 +0200
        Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 22:30 +0200
          Re: One-line password generator Glenn English <ghe2001@gmail.com> - 2017-08-23 22:40 +0200
        Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-23 00:40 +0200
          Re: One-line password generator Lck Ras <likcoras@riseup.net> - 2017-08-23 02:30 +0200
            Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-23 19:20 +0200
              Re: One-line password generator Lck Ras <likcoras@riseup.net> - 2017-08-24 03:00 +0200
          Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-23 17:20 +0200
            Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-23 19:00 +0200
              Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-23 20:00 +0200
                Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-23 21:20 +0200
                  Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-24 01:10 +0200
                    Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-24 19:50 +0200
                      Re: One-line password generator David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 03:00 +0200
                        Re: One-line password generator Curt <curty@free.fr> - 2017-08-25 10:50 +0200
                          Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-25 11:30 +0200
                            Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 15:40 +0200
                              Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-25 16:50 +0200
                                Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 18:10 +0200
                                  Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-25 19:20 +0200
                                    Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 20:10 +0200
                                      Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-25 20:50 +0200
                                        Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 21:00 +0200
                          Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-25 19:00 +0200
                            Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 19:00 +0200
                              Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 19:20 +0200
                                Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-25 20:20 +0200
                              Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-25 19:20 +0200
      Re: One-line password generator Jape Person <japers@comcast.net> - 2017-08-22 22:20 +0200
        Re: One-line password generator Jude DaShiell <jdashiel@panix.com> - 2017-08-23 14:40 +0200
      Re: One-line password generator Mike McClain <mike.junk.46@att.net> - 2017-08-23 03:10 +0200
    Re: One-line password generator Teemu Likonen <tlikonen@iki.fi> - 2017-08-23 06:10 +0200
    Re: One-line password generator Aaron Toponce <aaron.toponce@gmail.com> - 2017-08-23 21:20 +0200
      Re: One-line password generator Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-23 21:30 +0200
        Re: One-line password generator Aaron Toponce <aaron.toponce@gmail.com> - 2017-08-23 21:40 +0200
          Re: One-line password generator Fungi4All <fungilife@protonmail.com> - 2017-08-23 22:50 +0200
            Re: One-line password generator Terence <terence.john@gmail.com> - 2017-08-23 23:40 +0200
    Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-26 20:30 +0200
      Re: One-line password generator Nicolas George <george@nsup.org> - 2017-08-26 20:40 +0200
        Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-26 21:10 +0200
          Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-27 16:00 +0200
      Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-26 21:20 +0200
        Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-27 16:00 +0200
          Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-27 17:10 +0200
            Re: One-line password generator Curt <curty@free.fr> - 2017-08-27 20:10 +0200
            Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-27 20:10 +0200
              Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-27 21:10 +0200
                Re: One-line password generator Andy Smith <andy@strugglers.net> - 2017-08-28 00:00 +0200
                  Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-28 09:40 +0200
                    Re: One-line password generator Curt <curty@free.fr> - 2017-08-28 11:40 +0200
                      Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-28 12:10 +0200
                        Re: One-line password generator Andy Smith <andy@strugglers.net> - 2017-08-28 13:50 +0200
                          Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-28 15:20 +0200
                        Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 04:40 +0200
                          Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 09:10 +0200
                            Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 10:50 +0200
                              Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 11:00 +0200
                                Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 12:50 +0200
                                  Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 13:00 +0200
                                    Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 14:30 +0200
                                      Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-30 03:50 +0200
                                        Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 12:40 +0200
                                  Re: One-line password generator Andy Smith <andy@strugglers.net> - 2017-08-29 14:10 +0200
                                    Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 15:00 +0200
                                      Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-30 03:50 +0200
                                        Re: One-line password generator Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-30 14:20 +0200
                                          Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 14:50 +0200
                                            Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 15:20 +0200
                                              Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 15:30 +0200
                                                Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 15:50 +0200
                                                  Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 16:00 +0200
                                                    Re: One-line password generator Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-30 16:10 +0200
                                                      Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 18:50 +0200
                                                    Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 16:30 +0200
                                                      Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 20:10 +0200
                                                        Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 23:00 +0200
                                                          Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-01 10:40 +0200
                                                            Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-01 10:50 +0200
                                                  Re: One-line password generator Curt <curty@free.fr> - 2017-08-30 16:30 +0200
                                                    Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 17:00 +0200
                                                  Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-30 20:00 +0200
                              Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 11:00 +0200
              Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-27 21:20 +0200
                Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-29 21:20 +0200
                  Re: One-line password generator Reco <recoverym4n@gmail.com> - 2017-08-29 21:40 +0200
                    Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-29 22:00 +0200
                      Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 23:00 +0200
                        Re: One-line password generator Curt <curty@free.fr> - 2017-08-30 10:50 +0200
                          Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 12:40 +0200
                      Re: One-line password generator Reco <recoverym4n@gmail.com> - 2017-08-30 00:00 +0200
                        Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-31 21:10 +0200
                          Re: One-line password generator Fungi4All <fungilife@protonmail.com> - 2017-08-31 21:20 +0200
                          Re: One-line password generator Reco <recoverym4n@gmail.com> - 2017-08-31 21:40 +0200
      Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-27 04:20 +0200
        Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-27 16:00 +0200
          Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-27 16:40 +0200
    Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-09-01 17:00 +0200
      Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-09-01 21:50 +0200
        Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-01 23:50 +0200
          Re: One-line password generator Jude DaShiell <jdashiel@panix.com> - 2017-09-02 11:50 +0200
            Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-02 13:00 +0200
              Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-09-02 19:20 +0200
                Re: One-line password generator Jude DaShiell <jdashiel@panix.com> - 2017-09-02 20:30 +0200
                Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-02 21:00 +0200
                  Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-09-02 22:00 +0200
        Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-09-02 01:50 +0200
      Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-09-02 01:50 +0200
        Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-09-02 04:40 +0200
          Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-09-02 05:40 +0200
            Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-09-02 16:40 +0200
              Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-09-04 01:10 +0200

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →

#185891

From	Curt <curty@free.fr>
Date	2017-08-25 10:50 +0200
Message-ID	<uiits-1L5-21@gated-at.bofh.it>
In reply to	#185871

On 2017-08-25, David Wright <deblis@lionunicorn.co.uk> wrote:
>
> Unless you have accounts¹ that invite break-in attempts², the main
> thing to resist offline cracking is to have better passwords than
> your neighbours, just like security against burglary. Once a suitable
> proportion of passwords have been cracked, which will consist of the
> easier ones, there are diminishing returns in continuing to try to
> crack the rest.

Brian's thesis:

https://xkcd.com/936/

(clever and funny, BTW,
yet contradicted by this:)

https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

> ¹accounts of all sorts, not just forums.
> ²institutions, slebs, politicians, etc.
>
> Cheers,
> David.
>
>


-- 
Only the coward who has more fear of death than dignity can comfort himself with the fact that
his body will in time live again in the grass, in the stones, in the toad. To find one's
immortality in the transmutation of substances is as strange as to prophesy a brilliant future
for the case after a precious violin has been broken and becomes useless. — "Ward 6"

[toc] | [prev] | [next] | [standalone]

#185895

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2017-08-25 11:30 +0200
Message-ID	<uij6a-2dt-19@gated-at.bofh.it>
In reply to	#185891

Hi,

Curt wrote:
> https://xkcd.com/936/

Well, this is a joke for mathematicians. ROFL et.al.

> https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

... and this lines out why the other is so funny.

So what is the reason why
IhaveaMemorablePasswordwhichIwillnotforget!
is an easy victim of the described methods, whereas
WVAq7XLM4va6e1A4Bb4+Zw
is probably not ?

The amount of information and redundancy in a message is relative
to the knowledge of the reader. So giving an absolute value of
information aka entropy is questionable.

One can estimate entropy by an approximation of the best possible
compression in the context of the knowledge of the reader.
The compression result will generally be longer if the compressor has
fewer knowledge about the message.

In the given case the message is the password and helpful knowledge
would be about systematic weaknesses of its production. E.g. if the
password scheme is published as a cartoon.

Although the first example yields a longer gzip result than the second one,
one must not ignore the problem of specialized compressors which can
concisely represent some classes of passwords, thus defining short
enumerations of these passwords.

In the case of the first password, a dictionary based attack looks
promising. Camelback style actually helps the attacker.
Dictionary attacks are well suited for being run by bot nets.
The Markov attack mentioned on page 2 of the sincere article is quite
frightning. (Are you different enough from your neighbor ?)

The second password class and my knowledge about it gives me not more
than a reduction of text bit number by 25 percent (6 bit text -> 8 bit
binary) and a couple of bits which are harder to harvest.
E.g. i know that a dictionary attack is of few use. That's one bit,
because it's the first decision i can make. Any further insight might add
only a fraction of a bit. (It's probabilistic. So we can grind bits to dust.)

Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#185911

From	Mario Castelán Castro <marioxcc.MT@yandex.com>
Date	2017-08-25 15:40 +0200
Message-ID	<uin06-4CU-11@gated-at.bofh.it>
In reply to	#185895

[Multipart message — attachments visible in raw view] — view raw

On 25/08/17 04:21, Thomas Schmitt wrote:
> One can estimate entropy by an approximation of the best possible
> compression in the context of the knowledge of the reader.
> The compression result will generally be longer if the compressor has
> fewer knowledge about the message.

In principle, yes, but in practice, not at all. File compressors are
designed assuming that the common case will be compression of data much
longer than passwords (at least 1 MB). The behavior for message less
than 100 B long will be highly anomalous.

Moreover, the meta-data (like magic number, container, et cetera) add
overhead to the compressed file. If we interpret compressed length as
entropy this will inflate your estimate of entropy by tens of bytes,
which is enough to make it useless.

The problem trying to estimate entropy of a message M' given a prior
message M (the _context_ in your wording) can be formulated
mathematically in terms of Kolmogorov complexity. Unfortunately,
determining “the” Kolmogorov complexity of a message (given an universal
encoding scheme, for example, programs in untyped λ-calculus) is
algorithmically undecidable. Worse yet, Chaitin proved a theorem (now
called Chaitin incompleteness theorem) that for any consistent formal
system there exist a bound N such that the formal system can not prove
that “the” Kolmogorov complexity of any specific string is higher than N.

> The second password class and my knowledge about it gives me not more
> than a reduction of text bit number by 25 percent (6 bit text -> 8 bit
> binary) and a couple of bits which are harder to harvest.
> E.g. i know that a dictionary attack is of few use.  That's one bit,
> because it's the first decision i can make. Any further insight might add
> only a fraction of a bit. (It's probabilistic. So we can grind bits to dust.)

This is a somewhat oversimplified analysis. You know beforehand that a
password is almost surely a sequence of printable characters among the
allocated code points in Unicode. If you know the program in which the
password has been input, then you can know the character encoding as
well. Assuming it is UTF-8, you can discard a large fraction of all
possible 8-bit strings (not all 8-bit strings are valid UTF-8). Thus the
prior distribution has less than 8 bits of entropy per bit.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan

[toc] | [prev] | [next] | [standalone]

#185920

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2017-08-25 16:50 +0200
Message-ID	<uio5R-5gL-15@gated-at.bofh.it>
In reply to	#185911

Hi,

i wrote:
> > One can estimate entropy by an approximation of the best possible
> > compression in the context of the knowledge of the reader.

Mario Castelán Castro wrote:
> In principle, yes, but in practice, not at all. File compressors [...]

I wrote "estimate", "approximation", and "best possible compression".
Of course gzip is not a very good approximation even if one subtracts the
header bytes. 

Better approximations are presented in the article. Given the time spans
and computing powers which were mentioned, i'd say they performed less
than 2 exp 50 tries to crack the majority of good passwords.
I.e. the compression which is established by their enumeration can squeeze
those good passwords to less than 50 bits of size. Of course, as any lossles
compression, it has to inflate other better passwords by at least one bit.

> > The second password class and my knowledge about it gives me not more
> > than a reduction of text bit number by 25 percent (6 bit text -> 8 bit
> > binary) and a couple of bits which are harder to harvest.

> This is a somewhat oversimplified analysis.

Wasn't it you who said in
  https://lists.debian.org/debian-user/2017/08/msg01260.html
  “alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"”

After exploiting the "base64" part to get my 25 percent, i'd go for
/dev/urandom. man 4 urandom says:
  "[...] if  there  is  not  sufficient  entropy  in  the
   entropy  pool, the  returned  values are theoretically vulnerable to a
   cryptographic attack on the algorithms used by the  driver."

So if the non-guessable information in the password shall be near 128 bit,
then i would consider to use /dev/random while writing a little love poem
to my coputer in order to fill the pool.

But even with only 64 bit of entropy (relative to our knowledge), we are
14 bits (= factor of 16384 tries) away from the majority of "good"
passwords in the article.
The testers would have to work 44.8 years rather than a day, or wait
23.9 years until Moore's law has caught up. (Somebody should compute how
long it lasts if they start now and keep their equipment updated to the
newest level.)

Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#185927

From	Mario Castelán Castro <marioxcc.MT@yandex.com>
Date	2017-08-25 18:10 +0200
Message-ID	<uiplg-6dJ-31@gated-at.bofh.it>
In reply to	#185920

[Multipart message — attachments visible in raw view] — view raw

On 25/08/17 09:46, Thomas Schmitt wrote:
> Mario Castelán Castro wrote:
>> In principle, yes, but in practice, not at all. File compressors [...]
> 
> I wrote "estimate", "approximation", and "best possible compression".
> Of course gzip is not a very good approximation even if one subtracts the
> header bytes. 

I know what you wrote. My point is that there is no way to make a
reasonable approximation to the Kolmogorov complexity of a password.

Also, again, file compressors are bad for small files, especially as
small as passwords (less than 100 bytes). It makes little difference
whether you discount the header and trailer, they are still bad.

All contemporary practical compressorors (some research compressors do a
little more than this, see e.g.: the ones in the Hutter prize
compettion) are based on *verbatim* repetition and the biased
distribution of bytes in the data. They are bad for your use case
because there is little *verbatim* repetition in a password. They can
not interpret the *meaning* of the information in any meaningful way,
unlike an human.

For example, for an human, a byte string “one, two, three...” (that goes
to 10,000) is very simple to describe as “the numbers from 1 to 10,000
written in English and separated by “, ””. A compressor does not
understand that these are consecutive numbers spelled in English and
thus can not take advantage of this. The size of that data, compressed
for example, with XZ, will be much longer than the phrase above that I
used to describe it.

To recap: Real-life file compressors can not be used to estimate the
strength of passwords because they do not understand *meaning* as humans
perceive it.

> Better approximations are presented in the article.

*What* article? Nobody has mentioned a scientific article in this thread.

> Given the time spans
> and computing powers which were mentioned, i'd say they performed less
> than 2 exp 50 tries to crack the majority of good passwords.
> I.e. the compression which is established by their enumeration can squeeze
> those good passwords to less than 50 bits of size. Of course, as any lossles
> compression, it has to inflate other better passwords by at least one bit.
> 
> 
>>> The second password class and my knowledge about it gives me not more
>>> than a reduction of text bit number by 25 percent (6 bit text -> 8 bit
>>> binary) and a couple of bits which are harder to harvest.
> 
>> This is a somewhat oversimplified analysis.
> 
> Wasn't it you who said in
>   https://lists.debian.org/debian-user/2017/08/msg01260.html
>   “alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"”
> 
> After exploiting the "base64" part to get my 25 percent,i'd go for
> /dev/urandom. man 4 urandom says:
>   "[...] if  there  is  not  sufficient  entropy  in  the
>    entropy  pool, the  returned  values are theoretically vulnerable to a
>    cryptographic attack on the algorithms used by the  driver."

I already explained why my method is not a 25% reduction in entropy, but
you ignored the argument.

Also, the theoretical vulnerability described in that man page is far
fetched. It would require a *practical* attack comparable to pre-image
of SHA1. And one must note that not even the deprecated MD5 has a
practical pre-image attack, to the best of my knowledge.

Moreover, such a theoretical attack applies only when the attacker
*already knows* some of the output of your /dev/urandom, you output some
more bytes, and the attacker has to guess these additional bytes based
on the previous ouptput. In the use being discussed here, which is
password generation, the attacker does not know anything else about the
output of the PRNG.

In Linux (the kernel) the same algorithm used for /dev/urandom is used
to mix /dev/random. So there is likewise a theoretical possibility of a
vulnerability if you use /dev/random instead of /dev/urandom. Read
“/drivers/char/random.c” if you are interested in possible
vulnerabilities of the random virtual devices.

-----
Also, you mentioned 64 bits, but I *never* suggested this (in)security
level.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan

[toc] | [prev] | [next] | [standalone]

#185936

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2017-08-25 19:20 +0200
Message-ID	<uiqqZ-6RU-11@gated-at.bofh.it>
In reply to	#185927

Hi,

Mario Castelán Castro wrote:

> My point is that there is no way to make a
> reasonable approximation to the Kolmogorov complexity of a password.

That's my point, too. Although i use the terms "information" and "entropy".

> To recap: Real-life file compressors can not be used to estimate the
> strength of passwords because they do not understand *meaning* as humans
> perceive it.

To be exacting: The words "Real-life" and "file" are your contribution,
not mine.

Each enumeration algorithm establishes a compression algorithm. Whether
it is effective is another question. Interesting are those which enumerate
the given passwords early. The bit count of the found enumeration number
is an upper limit of the password's entropy in the context of the algorithm.

> *What* article? Nobody has mentioned a scientific article in this thread.

It's not very scientific. More real life:
  https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

Curt brought it up in
  https://lists.debian.org/debian-user/2017/08/msg01437.html
Thanks for this.
Especially funny is the cartoon on page 3.

If you can memorize a password, then it's weak.

> I already explained why my method is not a 25% reduction in entropy,

If you run your hopefully random data through base64 and tell this to me,
then i can get rid of the base64 redundancy and thus reduce each group of
4 bytes to 3 bytes.

To be clear, your password generator looks very safe. Even with urandom.
But the passwords are not compatible to human memory, which is no wonder.

> Also, the theoretical vulnerability described in that man page is far
> fetched.

It is a mathematical fact. If you take a few theoretically unpredictable
bits and inflate them to 128 bits, then the added size is no entropy,
although it might be hard to distinguish this redundancy from the initial
information.
You bet that the cryptographic algorithm used pushes your bits into a region
in the 128 bit space which above enumerators visit late. 

> Moreover, such a theoretical attack applies only when the attacker
> *already knows* some of the output of your /dev/urandom

This statement would have to be proven.

In general, what the attacker does not know is the exact value of the
theoretically unpredictable random number that was input to the urandom
inflation mapping. That's what i count as entropy of the inflated value.
Then we have the cryptographic algorithm. If it has a theoretically unknown
key, add its entropy to the input entropy.
The rest of the 128 bit is redundancy.

The only remaining defense is to make the cryptographic algorithm darn
complicated. But that's linear and thus has no chance against Moore's Law
if it does not fall victim to an agile mind.

> In Linux (the kernel) the same algorithm used for /dev/urandom is used
> to mix /dev/random.

But /dev/random hopefully uses 128 bits of collected entropy as input
for that algorithm.

> “/drivers/char/random.c”

 * When random bytes are desired, they are obtained by taking the SHA
 * hash of the contents of the "entropy pool".  The SHA hash avoids
 * exposing the internal state of the entropy pool.

So i assume that it is not used to inflate /dev/random

> if you are interested in possible
> vulnerabilities of the random virtual devices.

Others have more talent than me.

Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#185941

From	Mario Castelán Castro <marioxcc.MT@yandex.com>
Date	2017-08-25 20:10 +0200
Message-ID	<uirdo-7n4-35@gated-at.bofh.it>
In reply to	#185936

[Multipart message — attachments visible in raw view] — view raw

On 25/08/17 12:15, Thomas Schmitt wrote:
>> Also, the theoretical vulnerability described in that man page is far
>> fetched.
> It is a mathematical fact. If you take a few theoretically unpredictable
> bits and inflate them to 128 bits, then the added size is no entropy,
> although it might be hard to distinguish this redundancy from the initial
> information.

This saves me from having to write a whole reply, since I know your
incompetence in cryptography is such that you are incapable of realizing
how incompetent you are.

I will justify my claim of incompetence.

You say that pseudo-random number generators can not add entropy and
this is a mathematical fact. This is true, and irrelevant.

It is also a mathematical fact that cryptographic algorithms you use
daily like DSA and Diffie-Hellman work over a cyclic group, including
their elliptic curve variants.

In the case of conventionall (not elliptic curve), the group in question
is the group of integers modulo “n”, where the group operatin is
*multiplication*.

DSA and Diffie-Hellman are broken if one can compute “discrete
logarithms”, that is, if one can compute “x”, given “b” and “(b^x) mod “n”.

Any cyclic group of order “n” is mathematically equivalent (isomorph) to
the group of integeres modulo “n”, where the group operation is *addition*.

In this group, computing “x” (or proving that it does not exists) such
that “ax=c” for any given “a“ and “c” is trivial (using the extended
euclidean algorithm). And this is mathematically (but not
computationally) equivalent to solving the discrete logarithm.

Why aren't these algorithms broken? Because this is only a mathematical
result. The isomorphisms can not be computed efficiently in practice, so
they are irrelevant for cracking. The same is the case with your
“mathematical fact”.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan

[toc] | [prev] | [next] | [standalone]

#185943

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2017-08-25 20:50 +0200
Message-ID	<uirQ5-7Bv-3@gated-at.bofh.it>
In reply to	#185941

Hi,

> You say that pseudo-random number generators can not add entropy and
> this is a mathematical fact. This is true, and irrelevant.
> [...
>  lots of algebraic terms about the difficulty to revert the
>  mapping which produces the pseudo-random redundancy
> ...]

The attack described in the article does not try to revert a mapping.
It enumerates the input in a skillful way in order to produce the output
values which it compares to the captured list of values.

The only precondition is that the mapping can be reproduced without
adding an amount of possibilities which together with the possibilities
of the input establishes too much entropy.
Such additional entropy is usually called "salt". It's repeated use weakens
its unpredictability, though. And it must be kept as secret as the freshly
stolen password hash list should have been kept.


> I will justify my claim of incompetence.

So that it does not look like an intentional insult ?


> Because this is only a mathematical result.

This leaves me speechless. I resort to classic literature:

Scott: Well, Captain, er... the Klingons called you a... a tin-plated
       overbearing, swaggering dictator with delusions of godhood.

Capt. Kirk: Is that all?

Scott: No, sir. They also compared you with a Denebian slime devil.

Capt. Kirk: I see.

Scott: And then they said that you were a...

Capt. Kirk: I get the picture, Scotty.

Scott: Yes, sir.

Capt. Kirk: And after they said all this, that's when you hit the Klingons.

Scott: No, sir.

Capt. Kirk: ...No?

Scott: No, er, I didn't. You told us to avoid trouble.

Capt. Kirk: Oh, yes.

Scott: And I didn't see that it was worth fighting about. After all,
       we're big enough to take a few insults. Aren't we?

Capt. Kirk: What was it they said that started the fight?

Scott: They called the Enterprise a garbage scow! Sir.

Capt. Kirk: I see. And... that's when you hit the Klingon?

Scott: Yes, sir!

Capt. Kirk: You hit the Klingons because they insulted the Enterprise,
            not because they...

Scott: Well, sir, this was a matter of pride. 

Capt. Kirk: All right, Scotty. Dismissed. Oh... Scotty, you're restricted
            to quarters until further notice.

Scott: Yes, sir. Thank you, sir! That'll give me a chance to catch up on
       my technical journals! 

(http://www.imdb.com/title/tt0708480/quotes)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#185944

From	Mario Castelán Castro <marioxcc.MT@yandex.com>
Date	2017-08-25 21:00 +0200
Message-ID	<uirZM-7EI-11@gated-at.bofh.it>
In reply to	#185943

[Multipart message — attachments visible in raw view] — view raw

On 25/08/17 13:44, Thomas Schmitt wrote:
>> I will justify my claim of incompetence.
> 
> So that it does not look like an intentional insult ?

This is plain and simply my reason is to avoid further discussion about
cryptography with you.

I did not write this with the purpose of making an insult, but if you
find my impression about you offensive, the only think I can say is: try
to give a better impression next time to the next person.

>> Because this is only a mathematical result.
> 
> This leaves me speechless. I resort to classic literature:
> 
> [garbage removed]

Obviously, I mean “_only_ a mathematical result (with no computational
consequences)” as opposed to a “a mathematical result (having
computational consequences”.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan

[toc] | [prev] | [next] | [standalone]

#185932

From	Brian <ad44@cityscape.co.uk>
Date	2017-08-25 19:00 +0200
Message-ID	<uiq7E-6u6-27@gated-at.bofh.it>
In reply to	#185891

On Fri 25 Aug 2017 at 08:40:35 +0000, Curt wrote:

> On 2017-08-25, David Wright <deblis@lionunicorn.co.uk> wrote:
> >
> > Unless you have accounts¹ that invite break-in attempts², the main
> > thing to resist offline cracking is to have better passwords than
> > your neighbours, just like security against burglary. Once a suitable
> > proportion of passwords have been cracked, which will consist of the
> > easier ones, there are diminishing returns in continuing to try to
> > crack the rest.
> 
> Brian's thesis:
> 
> https://xkcd.com/936/
> 
> (clever and funny, BTW,
> yet contradicted by this:)
> 
> https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/
> 
> > ¹accounts of all sorts, not just forums.
> > ²institutions, slebs, politicians, etc.

An interesting read. You would come away with the technical notion that
the only type of password which is secure against an *offline* attack is
one which is generated randomly. The rate at which hashes can be tested
is impressive and no doubt increasing, so we'll go along with that.

However, users use passwords to log into accounts *online* and those
passwords are devised to withstand an *online* attack (of 100 tests per
second maximimum(?)). This is the only aspect a user can completely
control and many make a good job of it. Passwords which are long and
have some complexity but are not a burden on the user or impossible to
memorise would withstand such an attack. (This leaves aside the defences
the site itself has in place).

A user has no control over what happens at the other end. Knowledge
about how data are stored and safeguarded will be sparse, so the user
will have to make a risk assessment about that; only time will tell
whether it is correct. What doesn't seem quite right (morally and
technically) is for it to be implied that the user should take some
responsibilty for the site's (unknown) shortcomings.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#185933

From	Mario Castelán Castro <marioxcc.MT@yandex.com>
Date	2017-08-25 19:00 +0200
Message-ID	<uiq7E-6u6-29@gated-at.bofh.it>
In reply to	#185932

[Multipart message — attachments visible in raw view] — view raw

On 25/08/17 11:51, Brian wrote:
> However, users use passwords to log into accounts *online* and those
> passwords are devised to withstand an *online* attack (of 100 tests per
> second maximimum(?)). This is the only aspect a user can completely
> control and many make a good job of it. Passwords which are long and
> have some complexity but are not a burden on the user or impossible to
> memorise would withstand such an attack. (This leaves aside the defences
> the site itself has in place).
> 
> A user has no control over what happens at the other end. Knowledge
> about how data are stored and safeguarded will be sparse, so the user
> will have to make a risk assessment about that; only time will tell
> whether it is correct. What doesn't seem quite right (morally and
> technically) is for it to be implied that the user should take some
> responsibilty for the site's (unknown) shortcomings.

Unless you have a good reason to think otherwise (e.g. *you* manage the
web site and you know you are doing a good job), you should assume that
the data-base with hashes passwords will leak without the system
administrators noticing, and then an attack can be carried offline.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan

[toc] | [prev] | [next] | [standalone]

#185934

From	Mario Castelán Castro <marioxcc.MT@yandex.com>
Date	2017-08-25 19:20 +0200
Message-ID	<uiqqZ-6RU-1@gated-at.bofh.it>
In reply to	#185933

[Multipart message — attachments visible in raw view] — view raw

On 25/08/17 12:11, Brian wrote:
>> Unless you have a good reason to think otherwise (e.g. *you* manage the
>> web site and you know you are doing a good job), you should assume that
>> the data-base with hashes passwords will leak without the system
>> administrators noticing, and then an attack can be carried offline.
> 
> The problem with assumptions is that they often do not reflect the truth
> of a situation and predispose us to making recommendations which are not
> in the best interests of other people.

This *sounds* very reasonable, but the truth is that you are simply
dodging that your recommendation leads to weak passwords.

In security, one should not take things for granted. One should plan for
the worst plausible case. Leaking hashed passwords has happened many
times, so it is very plausible.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan

[toc] | [prev] | [next] | [standalone]

#185942

From	Brian <ad44@cityscape.co.uk>
Date	2017-08-25 20:20 +0200
Message-ID	<uirn4-7qw-11@gated-at.bofh.it>
In reply to	#185934

On Fri 25 Aug 2017 at 12:14:18 -0500, Mario Castelán Castro wrote:

> On 25/08/17 12:11, Brian wrote:
> >> Unless you have a good reason to think otherwise (e.g. *you* manage the
> >> web site and you know you are doing a good job), you should assume that
> >> the data-base with hashes passwords will leak without the system
> >> administrators noticing, and then an attack can be carried offline.
> > 
> > The problem with assumptions is that they often do not reflect the truth
> > of a situation and predispose us to making recommendations which are not
> > in the best interests of other people.
> 
> This *sounds* very reasonable, but the truth is that you are simply
> dodging that your recommendation leads to weak passwords.

It not only *sounds* very reasonable, it *is* very reasonable. All of
us, at one time or another, make assumptions which, in the light of
experience or on closer examination, do not stand up.

I really am not trying to dodge anything, but would like to know if
distinguishing beween offline and online is reasonable. Passwords which
are possibly not immune to *offline* cracking is how I would categorise
my idea.  But that is not the responsibility of the user to mitigate.
(Does one take a parachute on to a plane "just in case...?).

> In security, one should not take things for granted. One should plan for
> the worst plausible case. Leaking hashed passwords has happened many
> times, so it is very plausible.

My bank has never (to my knowledge) had a breach. I trust it. I assume
the people it employs are conscientious and competent. I assume they
know more about their systems than I do. (BTW, one does this all the
time, from surgeons to train drivers). I could use a random password
to log in, but where is the deficiency in "Gimmethed0sh. It's*my*money!"
for an online login?

To "take things for granted" is just another way of talking about
assumptions. Maybe I am taking my bank's security for granted. But what
other option is there, other than to form an opinion and then weigh up
the risk? I have no control over their policies regarding data access.
The worst possible case for my argument would be that the online and
offline cases are indistinguishable.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#185935

From	Brian <ad44@cityscape.co.uk>
Date	2017-08-25 19:20 +0200
Message-ID	<uiqqZ-6RU-3@gated-at.bofh.it>
In reply to	#185933

On Fri 25 Aug 2017 at 11:55:01 -0500, Mario Castelán Castro wrote:

> On 25/08/17 11:51, Brian wrote:
> > However, users use passwords to log into accounts *online* and those
> > passwords are devised to withstand an *online* attack (of 100 tests per
> > second maximimum(?)). This is the only aspect a user can completely
> > control and many make a good job of it. Passwords which are long and
> > have some complexity but are not a burden on the user or impossible to
> > memorise would withstand such an attack. (This leaves aside the defences
> > the site itself has in place).
> > 
> > A user has no control over what happens at the other end. Knowledge
> > about how data are stored and safeguarded will be sparse, so the user
> > will have to make a risk assessment about that; only time will tell
> > whether it is correct. What doesn't seem quite right (morally and
> > technically) is for it to be implied that the user should take some
> > responsibilty for the site's (unknown) shortcomings.
> 
> Unless you have a good reason to think otherwise (e.g. *you* manage the
> web site and you know you are doing a good job), you should assume that
> the data-base with hashes passwords will leak without the system
> administrators noticing, and then an attack can be carried offline.

The problem with assumptions is that they often do not reflect the truth
of a situation and predispose us to making recommendations which are not
in the best interests of other people.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#185743

From	Jape Person <japers@comcast.net>
Date	2017-08-22 22:20 +0200
Message-ID	<uhnOy-7kH-31@gated-at.bofh.it>
In reply to	#185740

On 08/22/2017 03:46 PM, Brian wrote:
> On Tue 22 Aug 2017 at 10:04:59 -0500, Mario Castelán Castro wrote:
> 
>> I have the following line in my Bash init file:
>>
>> “alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"”
>>
>> This generates a password with just above 128 bits of entropy. You may
>> find it useful.
> 
> Wow! Can you suggest something which gives one teensy-weensy bit of
> memorability?
> 

Sorry didn't catch thread earlier. Was xkcdpass mentioned?

JP

[toc] | [prev] | [next] | [standalone]

#185776

From	Jude DaShiell <jdashiel@panix.com>
Date	2017-08-23 14:40 +0200
Message-ID	<uhD6V-x6-1@gated-at.bofh.it>
In reply to	#185743

Also, apg with the -a1 switch provides memorable passwords.
On Tue, 22 Aug 
2017, Jape Person wrote:

> Date: Tue, 22 Aug 2017 16:13:59
> From: Jape Person <japers@comcast.net>
> To: debian-user@lists.debian.org
> Subject: Re: One-line password generator
> Resent-Date: Tue, 22 Aug 2017 20:15:58 +0000 (UTC)
> Resent-From: debian-user@lists.debian.org
> 
> On 08/22/2017 03:46 PM, Brian wrote:
>> On Tue 22 Aug 2017 at 10:04:59 -0500, Mario Castel?n Castro wrote:
>> 
>>> I have the following line in my Bash init file:
>>> 
>>> ?alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && 
>>> echo"?
>>> 
>>> This generates a password with just above 128 bits of entropy. You may
>>> find it useful.
>> 
>> Wow! Can you suggest something which gives one teensy-weensy bit of
>> memorability?
>> 
>
> Sorry didn't catch thread earlier. Was xkcdpass mentioned?
>
> JP
>
>

--

[toc] | [prev] | [next] | [standalone]

#185761

From	Mike McClain <mike.junk.46@att.net>
Date	2017-08-23 03:10 +0200
Message-ID	<uhslc-27L-13@gated-at.bofh.it>
In reply to	#185740

On Tue, Aug 22, 2017 at 08:46:24PM +0100, Brian wrote:
> Wow! Can you suggest something which gives one teensy-weensy bit of
> memorability?

    Here's a solution I like. Scramble some letters and numbers you
know by heart to create your password, like so:
My mother's nickname is Ginny. She was born 5 May, 1920.
The password 'G05i05n19n20y' is harder to crack not being suseptible to
dictionary lookup. Add a dot/bang (./!) or a hash/query (#/?) and it
becomes '.G05i05n19n20y!' or '#G05i05n19n20y?' and it's 15 characters.
    Run your selected password across some of the on'line password
checkers, there are many.

Best of luck,
Mike
--
If you lend someone $20 and never see that person again,
    it was probably a wise investment.

[toc] | [prev] | [next] | [standalone]

#185764

From	Teemu Likonen <tlikonen@iki.fi>
Date	2017-08-23 06:10 +0200
Message-ID	<uhv9o-46e-1@gated-at.bofh.it>
In reply to	#185717

[Multipart message — attachments visible in raw view] — view raw

Mario Castelán Castro [2017-08-22 10:04:59-05] wrote:

> “alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"”

Or if one wants to define the char set:

    #!/bin/sh
    length=${1:-16}
    tr -cd 0-9A-Za-z </dev/urandom | head -c "$length"
    echo

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [prev] | [next] | [standalone]

#185788

From	Aaron Toponce <aaron.toponce@gmail.com>
Date	2017-08-23 21:20 +0200
Message-ID	<uhJm2-4yp-3@gated-at.bofh.it>
In reply to	#185717

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 22, 2017 at 10:04:59AM -0500, Mario Castelán Castro wrote:
> I have the following line in my Bash init file:
> 
> “alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"”
> 
> This generates a password with just above 128 bits of entropy. You may
> find it useful.

Three POSIX-compliant shell functions that rely on no extra utilities outside
of standard base installs. shuff() is needed for some BSD systems where
shuffle(1) is used in place of shuf(1):

    shuff () {
        if [ $(command -v shuf) ]
        then
            shuf -n "$1"
        elif [ $(command -v shuffle) ]
        then
            shuffle -f /dev/stdin -p "$1"
        else
            awk 'BEGIN{
                "od -tu4 -N4 -A n /dev/urandom" | getline
                srand(0+$0)
            }
            {print rand()"\t"$0}' | sort -n | cut -f 2 | head -n "$1"
        fi
    }
    gen_monkey_pass () {
        I=0 
        [ $(printf "$1" | grep -E '[0-9]+') ] && NUM="$1" || NUM="1" 
        until [ "$I" -eq "$NUM" ]
        do
            I=$((I+1)) 
            LC_CTYPE=C strings /dev/urandom | grep -o '[a-hjkmnp-z2-9-]' | head -n 24 | paste -s -d \\0 /dev/stdin
        done | column
    }
    gen_xkcd_pass () {
        I=0 
        [ $(printf "$1" | grep -E '[0-9]+') ] && NUM="$1" || NUM="1" 
        [ $(uname) = "SunOS" ] && FILE="/usr/dict/words" || FILE="/usr/share/dict/words" 
        DICT=$(LC_CTYPE=C grep -E '^[a-zA-Z]{3,6}$' "$FILE") 
        until [ "$I" -eq "$NUM" ]
        do
            I=$((I+1)) 
            printf "$DICT" | shuff 6 | paste -s -d '.' /dev/stdin
        done | column
    }

They can optionally take an argument on how many passwords to generate:

    $ gen_monkey_pass 10
    rq5xm9b7-jn2-s76-v7rymj2    pe9txqkuprr3nn9yczsp23rb
    uxsx4-673xcv7wkeu7c8g66k    88qd-y549n5pg3g87v33yetw
    tbf6nrnbub8q39wqt943cjas    ts64jgxjw7ut84--2cw6uzxj
    vk4am2pr8nbuvr3e4gk7tsnm    uhdsby7838gkgpnqjzvy73jm
    2ckgppd7c2uasbd598-44z6z    se8-74smtafh4h9dmeyschkc

    $ gen_xkcd_pass 10
    irking.bidets.listen.Soyuz.dahlia.supped
    boob.lacing.peyote.glob.lack.trifle
    shirt.gushed.Aron.notch.agates.Fergus
    hewed.burlap.wales.beck.prisms.rangy
    route.retook.gills.cilium.wadis.gem
    stools.scurf.lugged.mooch.skater.throng
    heist.bye.Google.shyly.Tutsi.rip
    taboo.queues.totes.moors.Suzhou.newest
    sawyer.gill.clutch.opts.zits.larch
    Eisner.sulks.Bradly.Schulz.Adler.puking

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o

[toc] | [prev] | [next] | [standalone]

#185790

From	Greg Wooledge <wooledg@eeg.ccf.org>
Date	2017-08-23 21:30 +0200
Message-ID	<uhJvJ-4Bq-13@gated-at.bofh.it>
In reply to	#185788

On Wed, Aug 23, 2017 at 01:16:56PM -0600, Aaron Toponce wrote:
> Three POSIX-compliant shell functions that rely on no extra utilities
>     shuff () {
>         if [ $(command -v shuf) ]

Needs quotes.

>             shuffle -f /dev/stdin -p "$1"

/dev/stdin is not POSIX-compliant.

>         else
>             awk 'BEGIN{
>                 "od -tu4 -N4 -A n /dev/urandom" | getline

/dev/urandom is not POSIX-compliant.  Then again, I don't believe there
is *any* POSIX-compliant source of randomness available to shell scripts
other than awk's srand and rand.

Emulating /dev/urandom in awk is left as an exercise. ;-)

>         [ $(uname) = "SunOS" ] && FILE="/usr/dict/words" || FILE="/usr/share/dict/words" 

It'd be better to list all the possible places the dict file may exist,
and iterate through them until you find it, regardless of uname.

Also, don't use all-caps shell variable names.  All-caps names are
reserved for special internal variables, and environment variables.

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →

csiph-web

One-line password generator

Contents

#185891

#185895

#185911

#185920

#185927

#185936

#185941

#185943

#185944

#185932

#185933

#185934

#185942

#185935

#185743

#185776

#185761

#185764

#185788

#185790