Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #185717 > unrolled thread
| 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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-08-30 20:10 +0200 |
| Message-ID | <ukfB9-3fk-43@gated-at.bofh.it> |
| In reply to | #186187 |
On Wednesday 30 August 2017 10:25:00 Thomas Schmitt wrote: > Hi, > > i wrote: > > > The reason why this is still not fully reflected by the man page > > > is not yet uncovered. > > Gene Heskett wrote: > > Maybe a wee bit of security by obscurity? There is that I think in > > everyones thinking on this subject. They don't want to price the > > farm so cheap that it will actually sell. > > Ah no. The obscurity principle is unpopular in cryptography. > The widely accepted method is to have the algorithms public, so they > can be analysed and discussed, and to have the secrets separated in > keys. > > Given that Theodore T'so can probably cause a text change in the man > page if he really demands it, i rather expect to find a nitpicker like > me who challenges the flat deprecation of /dev/random by some thin but > valid argument. Just a gut feeling of mine. > > > For my own decision of /dev/random against /dev/urandom: > I use either of them very rarely. I have to deal with several old > kernels of which i do not know how firm the opinions were when those > kernels were young. > So i will continue to use the legacy interface as long as it is > available. But i will not raise objections if some day it becomes > exactly the same as the /dev/urandom interface. > This is the decision of the maintainers (Theodore T'so and Neil Horman > of CRYPTOGRAPHIC RANDOM NUMBER GENERATOR), whom i deem more educated > on the topic than i am. > Theodore T'so opinion IMO, carry's enough weight to more than "balance the scales" in most any argument about this... Theodore was smack in the middle of TPTB when I ditched an amiga and built a 400 MHz k6 based machine and installed red hat 5.0 on it in late 1997. So while I did have to do the early windows machines at WDTV, my awe of microsoft was soured when a network message machine running NT3.51 decided to nuke the most important library on the hard drive. Since the NT license was in those days several hundred dollars, I called microsoft and tried to explain what had happened and they not only refused to help, they accused me of being a pirate. That was their mistake, and from that day on, any specialty built machines never saw a windows install cd on my watch. I still think they has a random delay generator that was to delete that file when the delay ran out. Call it a virus, but that machine never saw the internet to get a virus, what it got for data was transmitted in the networks video streams vertical interval. If the messages received needed a reply, it took the reply and dialed up the modem on their machine to post the reply. In the meantime, an intelligent young man taught himself about that stuff, relieving me of that responsibility. He has built several server class machines to handle all the programs in digital formats that what in now a 2 network, 6 channel tv station needs, capable of moving a 1 hour program from the receiver machine to the air server, in about 30 seconds while that air server is airing 6 separate channels. And now backups for both have been built with auto failover, even in mid program. He's good. The complex (now 6 channels of tv, 1 class C fm radio station) was recently sold since the owner died about 2 years back, and the buyers IT people wanted to replace all that linux "junk" with windows machines. Enthusiasm to convert silently died when they found the terminal room would need expanding and almost double the HVAC to support that many windows machines like they were using at all their other properties. VERY BIG ups powers it all for long enough to get a 125 kw generator up to speed, so its on the air 24/7 until its out of fuel. 500 gallon tank, so that takes a while to run low. They've got all that at their other properties including the winders headaches. This stuff Just Works, 24/7 even with 2 HD's sick and dead. I think its impressing the hell out of the windows crew the new owners have been keeping at their other stations. If not, they are dumb like a pet rock I once saw that said on one side, "turn me over" and on the other side "mmm, that felt good". > Have a nice day :) If I can recover from working on the mower deck and re-installing it over the last 4 days. Sheet metal close to toasted, had to make a 6" square, 1/4" thick plate to support the pivot bolt the deck clutch lever turns on. With luck, it may outlast me. An 82 yo body is over worked with all that rolling around on the driveway, and I've got aches in most of the major muscles today. But if it needs to be done, I'll figure out a way to do it. Raised in the farm country in Iowa, where it was a 4 hour drive to town, one way, with a team of horses in 1940. Out there, if it had to be done, you did it, or it didn't get done. And my grandfather was good at it, he had built and installed a 32 volt delco electric system, and made the Maytag washer into an electric one after it kicked back and broke grandmothers ankle starting it, a first by almost a decade in Madison County, where all the covered bridges that Clint Eastwood and Meryl Streep made the movie about. I've been across most of them, and in the house twice that a guy named Marion Morrison was born in. Those of you familiar with old western movies know him as John Wayne, one of hollywoods true patriots. Me Special? Only in my own mind... :) > Thomas Cheers Thomas, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-30 23:00 +0200 |
| Message-ID | <ukifD-4I6-5@gated-at.bofh.it> |
| In reply to | #186201 |
Hi,
Brian wrote:
> the crackers would likely not be in possession of a leaked password
> (Uld4dFpYSkdkV1J3ZFdOclpYSUsK) but of a hash of it.
That's why i did not claim to be able to decipher such things but rather
mentioned that the name is celebrity enough to be quickly enumerated.
The next two secrets were: base64 once, which is rather normal, and then
another base64 which would be guessable by a list of obvious obfuscation
opportunities.
Together this would be vulnerable to self-learning attacks which follow
the habits and typical ideas of certain groups of people.
> The password does not contain any memorable words so word lists do not
> look an inviting prospect.
This is not the decisive point. The list with celebrity names is input to
the not extremely unlikely operation of double base64. After this chain
of processing, you have a string that looks garbled, but is still based
only on the thin secrets.
> With the much slower bcrypt the effort to crack anything more might
> have been too much.
More bits and a more complex algorithm make testing slower, indeed.
The mathematical bet is that there are no shortcuts to the slowliness.
A secret salt (or other encryption key) may help if it can be kept
completely separate from the hash list, so that the attacker needs
two separate thefts.
But from
https://en.wikipedia.org/wiki/Bcrypt
i understand the salt is stored unencrypted in the shadow password.
So only the extra bits of the result and the hopefully reliable
artificial slowliness of the algorithm can be counted as advantage
over MD5.
> Gene Heskett's password does not have all the criteria for being complex
> and completely random, but for now it looks like it would escape
> unscathed from brute force probing.
If the attacker has a bcrypt shadow password then the same number of
enumeration tries is necessary as with MD5. But it lasts linearly longer
to test them.
The linear factor depends on the "cost" parameter of the bcrypted password.
In the wikipedia example it is 1024 times the cost of a single bcrypt
round divided by the cost of a MD5 computation.
I failed up to now with finding an estimation of this fundamental ratio.
bcrypt seems to have indeed a good reputation.
But google finds "Argon2" when i ask for "bcrypt successor".
> Suppose
> echo "ElmerFudpucker" | base64 | base64
> became
> echo "ElmerFudpucker" | <some_bcrypt_processing> | base64 | base64
The latter is less secret than
echo "ElmerFudpucker" | base64 | base64 | <some_bcrypt_processing>
because as you could see with Gene's challenge, an unobfuscated base64
string is an invitation to run base64 -d.
If the last step in the chain is bcrypt, then i have to guess about
base64 | base64
md5sum | base64
sha512sum | base64
md5sum | xxd
...
as many as Gene or i can imagine (but not many enough)
----------------------------------------------------------------------------
Whatever, it seems to me that you can really create extra security on your
local side if you put that slow thing into the enumeration chain.
Even assumed that your attacker knows it, he still has the problem that
bcrypt weights on the enumeration regardless how poor the remote hash
obfuscation is. (It must not be so poor that a collision easily lets him in
although he tried a wrong password.)
A very good property is that the whole bcryptization does not have to
be secret and thus you may store its lengthy parameters in unsecure places.
You will not use more than the hash part of bcrypt as password. No need
to send "cost" or "salt" to the remote service.
Assume that everybody knows them and thus you don't need to tell. :))
But still your brain password needs to be strong enough to become really
strong by the added bits equivalent of bcrypt slowliness. If in the time
of one bcrypt try one could do 4096 MD5s, then this bcrypt is worth 12 bits
of secret, compared to MD5 and in the context of enumeration.
The rest of hard-to-guess bits must be stored in your brain.
I wonder whether one can arbitrarily increase the computation time
by arbitrary high cost value without creating opportunities for a shortcut.
Somehow this smells like information out of deterministic nothing ...
... the 184 bit hash must produce collisions after at most 2 exp 184
tries. So a wrong brain password would yield the right long password.
This is a trivial upper bit count limit for what bcrypt can gain you.
Probably the real systematic limit is lower. Young mathematicians needed.
In any case you would buy a new bit by doubling password computation time
for each time you want to use the password. So there are real world limits
much lower than the bit count of the hash.
The ratio of the attacker's computing power and your computing power matters.
This is a disadvantage compared to other methods which harden against
enumeration.
Disclaimer: This looks quite good to me but might be wrong, nevertheless.
All depends on whether bcrypt really has the properties which
are intended. Not to speak of my questionable conclusions
or of any non-enumeration strategies.
Gene Heskett wrote:
> Theodore T'so opinion IMO, carry's enough weight to more than "balance
> the scales" in most any argument about this... Theodore was smack in
> the middle of TPTB
It is astounding how many people can tell such things about him.
We all trust him daily, because you can hardly avoid to use his work
if you run GNU/Linux.
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-09-01 10:40 +0200 |
| Message-ID | <ukPEC-1pS-25@gated-at.bofh.it> |
| In reply to | #186211 |
Hi,
i made a test program from the SHA512 function of libjte, which stems from
GNU C Library version 2.7 and is used for Jigdo ISOs. A loop of 10 million
calls with a text of 80 characters, compiled -O2, ends after 4.088 seconds.
That's about 2 exp 23 times faster than python-bcrypt with 2 exp 16 rounds.
So the ratio (bcrypt round / SHA512) is about 2 exp 7 = 128.
SHA512 is taken as placeholder for any postprocessing of the enumerated
celebrity names which the attacker might try. It looks reasonably complex to
serve for this purpose here.
If not other implementations of bcrypt are faster, then during enumeration
this is equivalent to 20+ bits of entropy compared to a SHA512 obfuscated
password with known salt. (Not full 23 bits because generation of input
passwords lasts time, too, maybe longer than their SHA512 processing.)
python-bcrypt consists of a thin outer python wrapper
https://sources.debian.net/src/python-bcrypt/3.1.3-1/src/bcrypt/__init__.py/
and C code from OpenBSD
https://sources.debian.net/src/python-bcrypt/3.1.3-1/src/_csrc/
So at least the speed of the implementation language cannot be easily
surpassed by the bcrypt of an attacker.
Here is the python program, Google and i wrote in the last hour:
----------------------------------------------------------------------------
bcryptedpw.py - Compute and show long and enumeration-unfriendly password
from short user password.
Needs package "python-bcrypt" and maybe others which were already installed
on my Jessie by the wish to have a general software development system.
Provided under BSD license: Use, modify, distribute as you like.
----------------------------------------------------------------------------
#!/usr/bin/python
# -*- coding: utf-8 -*-
import bcrypt
import getpass
import sys
import time
# Seconds how long the result shall stay visible
viewtime=15
# Invisibly ask user password
userpw = getpass.getpass('Your secret password, please: ')
# Compute long remote password and show it
print "Don't go away now ..."
p = bcrypt.hashpw(userpw, '$2a$16$TO/1Wc6L2wC8SgJpgQEV9e')[-31:]
print "Here it is for ", str(viewtime), " seconds:"
sys.stdout.write(p)
sys.stdout.flush()
# Wait and then overwrite by blanks
time.sleep(viewtime)
sys.stdout.write("\r \n")
print "Do not forget to clear your paste buffer !"
----------------------------------------------------------------------------
I know nearly nothing of python. Probably one can do this more elegantly and
more safely in respect to hiding the user password and the result from spies.
(But one can really ask Google like one would ask a workmate at the
next programming desk. I wonder if it could teach C in a similar way.)
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-09-01 10:50 +0200 |
| Message-ID | <ukPOi-1tD-5@gated-at.bofh.it> |
| In reply to | #186268 |
Hi, i forgot to emphasize that each user should generate an own salt value by $ python >>> bcrypt.gensalt(16) '$2a$16$MS6A6ZrsJ30ZdqHVCMWMm.' and put it into the bcrypt call of bcryptedpw.py p = bcrypt.hashpw(userpw, '$2a$16$MS6A6ZrsJ30ZdqHVCMWMm.')[-31:] If many users would use the same salt, then it would be rewarding for the attacker to memorize the bcrypted failed tries and to re-use them very quickly for attacking the next user. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2017-08-30 16:30 +0200 |
| Message-ID | <ukcae-ZN-17@gated-at.bofh.it> |
| In reply to | #186184 |
On 2017-08-30, Thomas Schmitt <scdbackup@gmx.net> wrote: > Hi, > > Gene Heskett wrote: >> Well, that easy to remember method just went down in flames. Sigh... > > That's the first diffuse but significant wisdom we found in this thread: > > If you can memorize it without the help of publicly knowable details of > your life, then it's too easy to enumerate with nowadays' hardware. > He should've salted it a little. > Another wisdom is that Theodore T'so, a well reputed and mindful person > who is also the kernel maintainer of "RANDOM NUMBER DRIVER", flatly thinks > that /dev/random is legacy as soon as the system is fully up. That's because he thinks entropy is a property of the process that generates the output and not of the output itself (yes, I spoke with Ted over lunch). Therefore the idea that it can be "depleted" or "used up" is not right. It's not even wrong (with apologies to Wolfgang Pauli). -- "The world breaks everyone and afterward many are strong in the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry." *A Farewell to Arms*
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-30 17:00 +0200 |
| Message-ID | <ukcDf-19H-9@gated-at.bofh.it> |
| In reply to | #186188 |
Hi, i wrote: > > If you can memorize it without the help of publicly knowable details of > > your life, then it's too easy to enumerate with nowadays' hardware. Curt wrote: > He should've salted it a little. Sure. I also did not "crack" it by enumeration but by base64 -d after recognizing the type of redundancy in Gene's challenge. But the salt must be stored somewhere outside the brain (because it is not safe if ... yada yada ...). This brings us to the (still amateurish) idea of having a good encryption algorithm with a computer stored key and a human memorizable input word. But as soon as the computer stored secret gets stolen and brought to an enumaration expert, the protection against skilled attacks is weak again. > yes, I spoke with Ted over lunch How annoyed was he by the topic comming up once again ? > That's because he thinks entropy is a property of the process that > generates the output I will have to think about this idea ... (with no expectation to beat Theodore T'so in such a game) ... Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-30 20:00 +0200 |
| Message-ID | <ukfrr-2W1-3@gated-at.bofh.it> |
| In reply to | #186184 |
On Wed 30 Aug 2017 at 15:47:35 +0200, Thomas Schmitt wrote: > Gene Heskett wrote: > > Well, that easy to remember method just went down in flames. Sigh... > > That's the first diffuse but significant wisdom we found in this thread: > > If you can memorize it without the help of publicly knowable details of > your life, then it's too easy to enumerate with nowadays' hardware. But the crackers would likely not be in possession of a leaked password (Uld4dFpYSkdkV1J3ZFdOclpYSUsK) but of a hash of it. The article Curt referenced relates how attacking the hashes with brute force for any password with over six random characters was only looked at selectively. And that was with MD5 hashes. With the much slower bcrypt the effort to crack anything more might have been too much. The example generated password is 28 characters. How random they are I do not know, but the article indicates it was not put to the test. Maybe Gene Heskett's password does not have all the criteria for being complex and completely random, but for now it looks like it would escape unscathed from brute force probing. The password does not contain any memorable words so word lists do not look an inviting prospect. Without the password one cannot begin to examine how it was created. Suppose echo "ElmerFudpucker" | base64 | base64 became echo "ElmerFudpucker" | <some_bcrypt_processing> | base64 | base64 which is as memorisable as previously, I am not saying the problem becomes insurmountable for attackers, but slowing them down considerably cannot be bad. (That's assuming they are in possession of the hashes and are after *your* Twitter account. You really don't believe that, do you?) -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-08-29 11:00 +0200 |
| Message-ID | <ujKxj-oP-11@gated-at.bofh.it> |
| In reply to | #186112 |
I stated: > > https://www.2uo.de/myths-about-urandom/structure-yes.png > > The new situation as stated in > > https://www.2uo.de/myths-about-urandom/structure-new.png > > I always thought (even pre- Kernel 4.8) that structure-new was how it > worked. But on the other hand, it's just a diagram - use the source, > Duke! Sorry, structure-yes is what I thought it was, and thought it still was, but seems it may no longer be. I don't understand the difference between -yes and -new; on its face, "-new" looks actually wrong to me - but it's just someone's diagram, the source code is the truth of what happens in the kernel. Good luck,
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-27 21:20 +0200 |
| Message-ID | <ujbgd-3uv-1@gated-at.bofh.it> |
| In reply to | #186030 |
Hi, Brian wrote: > I do not have to run faster than the bear, just faster than anyone else. According to the article about the successful cracking, it is not so much about how fast you are. The bear will not stop when it is done with eating those behind you. It is rather about not to walk the paths which all the tasty others walk. The first found meal tells the bear that there is more food in the same direction. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-29 21:20 +0200 |
| Message-ID | <ujUdk-6Et-21@gated-at.bofh.it> |
| In reply to | #186036 |
On Sun 27 Aug 2017 at 21:12:12 +0200, Thomas Schmitt wrote: > Brian wrote: > > I do not have to run faster than the bear, just faster than anyone else. (Analogies never work. Remind me not to use them again). > According to the article about the successful cracking, it is not so much > about how fast you are. The bear will not stop when it is done with eating > those behind you. Note that the article details the point at which the investigators gave up on going after what they saw as random passwords. They would never have got to my!only"reason£for$living%is^ebay no matter how low or high its entropy is. Which is not to say other techniques would not have caught it. Stamina is at least as important as speed. The bear will have run out of puff after trying n=10 for brute force. Protecting an online login is far more important than second-guessing how a provider has provisioned their system. A user has no control over the latter, so why should he put any great thought into comabating the provider as well as the crackers. We are mesmorised by the skills of offline crackers. They dazzle us and blind us to realities. Where is someone saying that eq8GeKBhVXOTjF0dAyd0 is a splendid password? It wouldn't have a chance of being forced via an online attack. > It is rather about not to walk the paths which all the tasty others walk. > The first found meal tells the bear that there is more food in the same > direction. With an offline attack, probably. But where are the people who say that online is the same as or even similar to offline, Inquiring minds would like to know why 'thisismySECRETpassword' is a poor login password. And, even assuming a site such as Ebay with its millions of users loses its marbles to offline cracking, why think you are first in line for rampaging? Ok, they have to start somewhere - it might as well be you. :) -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2017-08-29 21:40 +0200 |
| Message-ID | <ujUwH-6Me-53@gated-at.bofh.it> |
| In reply to | #186153 |
Hi. On Tue, Aug 29, 2017 at 08:14:59PM +0100, Brian wrote: > On Sun 27 Aug 2017 at 21:12:12 +0200, Thomas Schmitt wrote: > > > Brian wrote: > > > I do not have to run faster than the bear, just faster than anyone else. > > (Analogies never work. Remind me not to use them again). > > > According to the article about the successful cracking, it is not so much > > about how fast you are. The bear will not stop when it is done with eating > > those behind you. > > Note that the article details the point at which the investigators gave > up on going after what they saw as random passwords. They would never > have got to > > my!only"reason£for$living%is^ebay > > no matter how low or high its entropy is. Sadly it only means that these investigators were to lazy to implement Markov chains to generate a suitable dictionary. See this for the example: https://hashcat.net/events/p14-trondheim/prince-attack.pdf > We are mesmorised by the skills of offline crackers. They dazzle us and > blind us to realities. Where is someone saying that > > eq8GeKBhVXOTjF0dAyd0 > > is a splendid password? It wouldn't have a chance of being forced via an > online attack. Since it appeared in a public maillist - it is a bad password by definition. Reco
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-29 22:00 +0200 |
| Message-ID | <ujUQ2-6TY-19@gated-at.bofh.it> |
| In reply to | #186157 |
On Tue 29 Aug 2017 at 22:29:41 +0300, Reco wrote: > Hi. > > On Tue, Aug 29, 2017 at 08:14:59PM +0100, Brian wrote: > > On Sun 27 Aug 2017 at 21:12:12 +0200, Thomas Schmitt wrote: > > > > > Brian wrote: > > > > I do not have to run faster than the bear, just faster than anyone else. > > > > (Analogies never work. Remind me not to use them again). > > > > > According to the article about the successful cracking, it is not so much > > > about how fast you are. The bear will not stop when it is done with eating > > > those behind you. > > > > Note that the article details the point at which the investigators gave > > up on going after what they saw as random passwords. They would never > > have got to > > > > my!only"reason£for$living%is^ebay > > > > no matter how low or high its entropy is. > > Sadly it only means that these investigators were to lazy to implement > Markov chains to generate a suitable dictionary. See this for the > example: > > https://hashcat.net/events/p14-trondheim/prince-attack.pdf You are blinding us with technological terms. How does this help with attacking the password for a login with online techniques? > > We are mesmorised by the skills of offline crackers. They dazzle us and > > blind us to realities. Where is someone saying that > > > > eq8GeKBhVXOTjF0dAyd0 > > > > is a splendid password? It wouldn't have a chance of being forced via an > > online attack. > > Since it appeared in a public maillist - it is a bad password by > definition. It will not be used again. How easy is it to force +H3GHd8kXs8HfmRDzZ7y online by probing it over the net? -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-29 23:00 +0200 |
| Message-ID | <ujVM5-7u1-1@gated-at.bofh.it> |
| In reply to | #186158 |
Hi, Brian wrote: > They would never have got to > my!only"reason£for$living%is^ebay Unless some group of people is caught with using this scheme. Of course the attacker needs more computing power than with a camelback style text that bears no separators out of a set with a few dozen characters. You have a UK keyboard. That would be about number three to test for an easy to memorize sequence of non-letters. (QWERTY, QWERTZ, BS 4822, ...) So it's not much more work than with CamelBackStyle. > Stamina is at least as important as speed. Not to forget experience and gut instincts of the attacker. He sneaks into your shoes and lives a copy of your life ... shoo-hooo ... > We are mesmorised by the skills of offline crackers. They dazzle us and > blind us to realities. I often wonder how much of the reports about secret agency powers is intentional deception and how much is a glimpse of a world where nothing is private. One cannot even tell for sure whether they get something that is worth the money for the electricity they consume. It's all an endless series of tricks and lies. They even use truth to fool the enemy. Nobody believes the truth. > > The first found meal tells the bear that there is more food in the same > > direction. > With an offline attack, probably. But where are the people who say that > online is the same as or even similar to offline, If the attacker has no opportunity to test a lot of tries, then brute force has nearly no hope for success, indeed. In this case, eavesdropping and non-computer actions like burglary or social engineering are the things to fear. Not to forget judges. IPv6 addresses are a problem. If i ask a what-is-my-IP site for my IPv6 address then it tells me the town where i live. With IPv4 the reported location is often hundreds of kilometers away. > And, even assuming a site such as Ebay with its millions of users loses > its marbles to offline cracking, why think you are first in line for > rampaging? You'd end up in lists of cracked passwords and user names which get sold for Bitcoins. Mass matters. > Ok, they have to start somewhere - it might as well be you. :) Never choose a username that looks like money or sexual exploitability. A good precaution is to only do things in the internet, which you can justify doing in public as well, and to only expose as much money to the web as you can easily afford to lose. I live in a spacetime bubble where this is possible. Others are less lucky. Reco wrote: > Since it [eq8GeKBhVXOTjF0dAyd0] appeared in a public maillist - it is a > bad password by definition. Harvested today and on the market tomorrow. Brian wrote: > It will not be used again. Hey ! You are spoiling an upwardly mobile sector of the economy. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2017-08-30 10:50 +0200 |
| Message-ID | <uk6Rd-63h-37@gated-at.bofh.it> |
| In reply to | #186159 |
On 2017-08-29, Thomas Schmitt <scdbackup@gmx.net> wrote: > >> Ok, they have to start somewhere - it might as well be you. :) > > Never choose a username that looks like money or sexual exploitability. How about TawnyLoveRockefellerIII? -- "Time flies like an arrow. Fruit flies like a banana." Groucho.
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-30 12:40 +0200 |
| Message-ID | <uk8zD-79l-1@gated-at.bofh.it> |
| In reply to | #186167 |
Hi, Curt wrote: > How about TawnyLoveRockefellerIII? Expect to get mails like: "Your money account at Blingstergirl.com is empty. Please send 1 million $ and some swimwear photos of you to prove your identity." Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2017-08-30 00:00 +0200 |
| Message-ID | <ujWIb-84B-53@gated-at.bofh.it> |
| In reply to | #186158 |
Hi. On Tue, Aug 29, 2017 at 08:50:53PM +0100, Brian wrote: > On Tue 29 Aug 2017 at 22:29:41 +0300, Reco wrote: > > > Hi. > > > > On Tue, Aug 29, 2017 at 08:14:59PM +0100, Brian wrote: > > > On Sun 27 Aug 2017 at 21:12:12 +0200, Thomas Schmitt wrote: > > > > > > > Brian wrote: > > > > > I do not have to run faster than the bear, just faster than anyone else. > > > > > > (Analogies never work. Remind me not to use them again). > > > > > > > According to the article about the successful cracking, it is not so much > > > > about how fast you are. The bear will not stop when it is done with eating > > > > those behind you. > > > > > > Note that the article details the point at which the investigators gave > > > up on going after what they saw as random passwords. They would never > > > have got to > > > > > > my!only"reason£for$living%is^ebay > > > > > > no matter how low or high its entropy is. > > > > Sadly it only means that these investigators were to lazy to implement > > Markov chains to generate a suitable dictionary. See this for the > > example: > > > > https://hashcat.net/events/p14-trondheim/prince-attack.pdf > > You are blinding us with technological terms. 'Us'? Do not speak for all the list please. Admit that you just did not read the pdf. > How does this help with attacking the password for a login with online techniques? Simple. You generate passwords by using adjectives, nouns and verbs from Oxford and/or Webster dictionary. You don't put all the words together (the result will have too much volume), you try to create grammatically correct (although meaningless) phrases. A mathematical concept that allows you to do so is Markov chains. An implementation of this concept is called Prince Attack on hashcat lingua. Overall entropy of 'my!only"reason£for$living%is^ebay' password (aka XKCD 936 password) could be reduced significantly, leaving 'eq8GeKBhVXOTjF0dAyd0' password (aka base64 password) far superior. Also, bruteforcing a password by feeding a list of those to the online service of any kind is dumb (unless you have a disposable botnet dedicated to this purpose). Smart move is to obtain a list of (hopefully) hashed passwords, which all bad guys are doing these days. > > > We are mesmorised by the skills of offline crackers. They dazzle us and > > > blind us to realities. Where is someone saying that > > > > > > eq8GeKBhVXOTjF0dAyd0 > > > > > > is a splendid password? It wouldn't have a chance of being forced via an > > > online attack. > > > > Since it appeared in a public maillist - it is a bad password by > > definition. > > It will not be used again. > > How easy is it to force > > +H3GHd8kXs8HfmRDzZ7y Since you put it on the public maillist again - trivially. Reco
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-31 21:10 +0200 |
| Message-ID | <ukD0L-1eW-41@gated-at.bofh.it> |
| In reply to | #186161 |
On Wed 30 Aug 2017 at 00:59:15 +0300, Reco wrote: > On Tue, Aug 29, 2017 at 08:50:53PM +0100, Brian wrote: > 'Us'? Do not speak for all the list please. It is a construct; intended to involve everyone in the conversation. > Admit that you just did not read the pdf. It is not concerned with online cracking. That is obvious. Why should I spend time in reading its each and every detail > > How does this help with attacking the password for a login with online techniques? > > Simple. You generate passwords by using adjectives, nouns and verbs from > Oxford and/or Webster dictionary. You don't put all the words together > (the result will have too much volume), you try to create grammatically > correct (although meaningless) phrases. A mathematical concept that > allows you to do so is Markov chains. An implementation of this concept > is called Prince Attack on hashcat lingua. > > Overall entropy of 'my!only"reason£for$living%is^ebay' password (aka > XKCD 936 password) could be reduced significantly, leaving > 'eq8GeKBhVXOTjF0dAyd0' password (aka base64 password) far superior. > > Also, bruteforcing a password by feeding a list of those to the online > service of any kind is dumb (unless you have a disposable botnet > dedicated to this purpose). Smart move is to obtain a list of > (hopefully) hashed passwords, which all bad guys are doing these days. Services accept numerous failed *online* logins without doing anything about it? We (or, if you prefer - you) have now decided to move to offline cracking. It makes for a better press. > > > > We are mesmorised by the skills of offline crackers. They dazzle us and > > > > blind us to realities. Where is someone saying that > > > > > > > > eq8GeKBhVXOTjF0dAyd0 > > > > > > > > is a splendid password? It wouldn't have a chance of being forced via an > > > > online attack. > > > > > > Since it appeared in a public maillist - it is a bad password by > > > definition. > > > > It will not be used again. > > > > How easy is it to force > > > > +H3GHd8kXs8HfmRDzZ7y > > Since you put it on the public maillist again - trivially. Damn. I spent ages using the technique in the first post in this thread to devise it. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Fungi4All <fungilife@protonmail.com> |
|---|---|
| Date | 2017-08-31 21:20 +0200 |
| Message-ID | <ukDap-1iX-15@gated-at.bofh.it> |
| In reply to | #186247 |
[Multipart message — attachments visible in raw view] — view raw
> From: ad44@cityscape.co.uk > To: debian-user@lists.debian.org > > On Wed 30 Aug 2017 at 00:59:15 +0300, Reco wrote: > >> On Tue, Aug 29, 2017 at 08:50:53PM +0100, Brian wrote: >> "Us"? Do not speak for all the list please. > > It is a construct; intended to involve everyone in the conversation. Sorry Brian, after a while on the list I can get a sense that your communication is just peculiar, although you are not evil in real life, but this is the true essence of true fascism. To speak as you represent everyone isolating "one" and placing him/her against all of you! It is "us" against the jew, the homosexual, the jw, the gypsy, the commy. It is a populist tactic, you may want to place you manuals aside and read some early 20th century history. In an other continent it was america against the foreign invasion of a syndicalist. On this side of the pond it was us against "him". Hitler himself did alot of street talk to gain support. Unless secretly the rest of the list has elected you to speak on their speechless behalf. "It is a construct"! Ha!! >> Admit that you just did not read the pdf. > > It is not concerned with online cracking. That is obvious. Why should I > spend time in reading its each and every detail > > -- > Brian.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2017-08-31 21:40 +0200 |
| Message-ID | <ukDtL-1q4-3@gated-at.bofh.it> |
| In reply to | #186247 |
Hi.
On Thu, Aug 31, 2017 at 08:00:54PM +0100, Brian wrote:
> On Wed 30 Aug 2017 at 00:59:15 +0300, Reco wrote:
>
> > On Tue, Aug 29, 2017 at 08:50:53PM +0100, Brian wrote:
> > 'Us'? Do not speak for all the list please.
>
> It is a construct; intended to involve everyone in the conversation.
>
> > Admit that you just did not read the pdf.
>
> It is not concerned with online cracking. That is obvious. Why should I
> spend time in reading its each and every detail
Admitting something, especially in public takes courage.
I applaud you for admitting it, and adjust my further explanations as
clearly your talents lie outside of security field.
> > > How does this help with attacking the password for a login with online techniques?
> >
> > Simple. You generate passwords by using adjectives, nouns and verbs from
> > Oxford and/or Webster dictionary. You don't put all the words together
> > (the result will have too much volume), you try to create grammatically
> > correct (although meaningless) phrases. A mathematical concept that
> > allows you to do so is Markov chains. An implementation of this concept
> > is called Prince Attack on hashcat lingua.
> >
> > Overall entropy of 'my!only"reason£for$living%is^ebay' password (aka
> > XKCD 936 password) could be reduced significantly, leaving
> > 'eq8GeKBhVXOTjF0dAyd0' password (aka base64 password) far superior.
> >
> > Also, bruteforcing a password by feeding a list of those to the online
> > service of any kind is dumb (unless you have a disposable botnet
> > dedicated to this purpose). Smart move is to obtain a list of
> > (hopefully) hashed passwords, which all bad guys are doing these days.
>
> Services accept numerous failed *online* logins without doing anything
> about it?
You'd be surprised how many services do exactly nothing about failed
logins (ssh out of the box for starters). Even if they did - there's
nothing a hypothetical service could do against 10^5-10^6 unique IPs
('disposable botnet' comes here) each attempting 2-3 logins.
Besides, why bother with online logins if you can dump password
database ('dumb' and 'smart' come here)?
Reco
[toc] | [prev] | [next] | [standalone]
| From | Mario Castelán Castro <marioxcc.MT@yandex.com> |
|---|---|
| Date | 2017-08-27 04:20 +0200 |
| Message-ID | <uiVl7-18U-1@gated-at.bofh.it> |
| In reply to | #185994 |
[Multipart message — attachments visible in raw view] — view raw
On 26/08/17 13:25, Brian wrote: > How does this > > echo 'secretpassword' | sha256sum - | base64 | cut -c -30 | head -1 > > compare with your recommendation? I do not see the point in this post-processing. It seems that you have a very wrong impression of what makes a password generation scheme be a good password generation scheme. For any probability distribution fixed in advanced, the *expected* (in the sense used in probability theory) entropy of a password generated with my scheme is well defined and at least 132 bits (I wanted 128 bits, but using Base64 the choice is between 132 bits and 126 bits because 132 is not a multiple of 6). In other words, if you take a probability distribution and keep if fixed while generating a big amount of passwords with my scheme, the average entropy under that probability distribution will be at least (within sampling error) 132 bits. This property is achieved *because* there is a source of randomness (that we can assume, has uniform distribution and thus maximal entropy per byte) in my generation scheme, not because of Base64. Base64 is there just to turn the random bytes into a *short* human-readable string. One could turn the random bytes instead into a list of words (as long as the mapping is one-to-one) and the same property about expected entropy would hold, but then the password would be *much* longer. Length is the *only* reason to use Base64 here instead of using the random bytes to choose words at random. By contrast, your “scheme” has no systematic source of randomness. It requires that one has already decided for a “randompassword”, and then post-process it. If the attacker knows the post-processing, guessing this password is at least as easy than guessing the input to the post-processing step (plus computing the hash and encoding, but this is negligible). Moreover, your post-processing stage loses information, as another user has already noted. If the attacker knows your post-processing method, he can speed the search by avoid trying the passwords that could not be possibly generated with your method because of this loss of information. For example, your method will never generate a string of '0000...' because the input to Base64 are hex digits in ASCII, which never have the byte value 0 (0 is unprintable). If the attacker does not know the post-processing stage, then maybe he will eventually begin to guess that your password is an human-generated password ran through a post-processing stage. Then very possibly your post-processing adds security (because the attacker has to guess the post-processing method too), but how much? *It is not well defined*. We already talked about non-well-defined probabilities, so I will not repeat that fragment. -- Do not eat animals, respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web