Discussion:
A better way to think about passwords
(too old to reply)
Doug Barton
2011-04-17 22:49:58 UTC
Permalink
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.

http://www.baekdal.com/tips/password-security-usability

- --

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
Robert J. Hansen
2011-04-17 22:58:13 UTC
Permalink
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
I am giving a great big yuk to his methodology. There's no reference to the entropy of text, for instance. His example of a three common word password, "this is fun," amounts to a total of 11 letters: this will be around 22 bits of entropy, or 4 million combinations. @ 100 attempts per second, that requires 40,000 seconds, or about 11 hours. He claims it'll take 2,357 years. Let's just say I'm skeptical.

Also, look at his claims for a six-character "common word." Okay, so this has at most 10 bits of entropy or so: any more and it wouldn't be common. 10 bits of entropy equals 1000 possibilities, @ 100 per second equals ten seconds to break it -- not the 3 minutes he claims.

His math doesn't work. I call shenanigans on the entire thing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 227 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20110417/51d540d7/attachment.pgp>
Grant Olson
2011-04-17 23:39:42 UTC
Permalink
Post by Robert J. Hansen
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
His math doesn't work. I call shenanigans on the entire thing.
I think it's worth noting that the low entropy of english (you quoted
2.5 bits per char in another thread) isn't just an academic issue. Real
password crackers actually do employ multiple strategies and passes in
order of complexity. For example, starting with dictionary, then
dictionary w/leetspeak, eventually brute force, etc.

My other big gripe with this article is that it completely ignores the
possibility of an offline attack against the hashes. It's assuming that
the limiting factor is the number of times you can access a webpage.
I've been goofing around with BitCoin this weekend, and my MacBook Pro
is generating about 2 Million SHA256 hashes a second.
--
-Grant

"Look around! Can you construct some sort of rudimentary lathe?"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 565 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110417/7e5e73e4/attachment.pgp>
Grant Olson
2011-04-18 00:00:18 UTC
Permalink
(you quoted 2.5 bits per char in another thread)
Apologies, actually you didn't say this. You said, "English text has in
the neighborhood of 1.5 to 2.5 bits of entropy per glyph." Just
correcting myself because I know how annoying it is to be misquoted.
--
-Grant

"Look around! Can you construct some sort of rudimentary lathe?"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 565 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110417/82047aa3/attachment.pgp>
Faramir
2011-04-18 10:53:12 UTC
Permalink
El 17-04-2011 20:39, Grant Olson escribi?:
...
Post by Grant Olson
I think it's worth noting that the low entropy of english (you quoted
2.5 bits per char in another thread) isn't just an academic issue. Real
password crackers actually do employ multiple strategies and passes in
order of complexity. For example, starting with dictionary, then
dictionary w/leetspeak, eventually brute force, etc.
Probably the idea is to avoid bruteforce at all costs, because if you
have to do that, you might be bruteforcing an 8 characters password for
more than 50 years (if mixed lowercase, uppercase, numbers and symbols,
and you just have 1 home computer dedicated to the task).

Maybe we should just pick a "good password", hash it a couple of
times, and use that hash as the real password... we could carry the
hashing tool in a flash drive.
Post by Grant Olson
My other big gripe with this article is that it completely ignores the
possibility of an offline attack against the hashes. It's assuming that
the limiting factor is the number of times you can access a webpage.
Right, limiting the attacks make even 4 pins codes secure, if the
account becomes blocked after 3 wrong attempts. But that won't protect
your password database if it falls in the wrong hands, or your GPG
private keys. And to say "that's a server problem, fix the server" is
wrong, because it will quickly become an user's problem if the password
is cracked, and the user uses the same password for different things (as
a lot of people do).
Post by Grant Olson
I've been goofing around with BitCoin this weekend, and my MacBook Pro
is generating about 2 Million SHA256 hashes a second.
I was checking how much time would it take to bruteforce a SHA-1 8
characters password (upper/lowercase characters, plus numbers, plus
symbols), and my machine did 2,5 millions of tries a second.

Best Regards
Hauke Laging
2011-04-18 11:21:07 UTC
Permalink
Post by Faramir
Maybe we should just pick a "good password", hash it a couple of
times, and use that hash as the real password... we could carry the
hashing tool in a flash drive.
That does not make sense to me because you do not increase the key space by
that. If you try to defend against somebody who knows what you do then it is
no protection.

My wish is to have a secure, small, cheap smartcard-like device which stores a
salt, takes a passwort and gives you a hash then. The salt makes this secure.
Your "password" can even be the name of the organization to which the account
belongs. "bank xy". Easy to remember and completely safe thus because the hash
is created over
"OJD5jLP1L8Wa0a19qtgRH4dlzA7aeZTobank xy"
And if you are asked to change the password, over
"OJD5jLP1L8Wa0a19qtgRH4dlzA7aeZTobank xy2"
"OJD5jLP1L8Wa0a19qtgRH4dlzA7aeZTobank xy3"

Such an device would also allow easy but secure CRAM logins ? even by phone.


Hauke
--
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110418/08d2d1b1/attachment.pgp>
Faramir
2011-04-19 10:56:30 UTC
Permalink
Post by Hauke Laging
Post by Faramir
Maybe we should just pick a "good password", hash it a couple of
times, and use that hash as the real password... we could carry the
hashing tool in a flash drive.
That does not make sense to me because you do not increase the key space by
that. If you try to defend against somebody who knows what you do then it is
no protection.
Well, true, if the attacker knows I do that. But as the password is
supposed to be secret, the password generation procedure could be
considered secret too. So, lets say, I think about a password easy to
remember to me, then I apply SHA-256 to it a "secret" amount of times
(lets say, I hash the hash 5 times). And I would use that final hash as
a password. It would defeat any dictionary attack, since the 4? hash
wouldn't be in any "commond words" dictionary. It would still be
vulnerable to a complete rainbow table for SHA-256, but if such rainbow
table exists at all, then we are all toasted, no matter what password we
use, it would still be found.

I don't know the storage space needed for the whole key space of
SHA-256, but I guess it would be huge (maybe not feasible).

Best Regards
MFPA
2011-04-19 17:56:57 UTC
Permalink
Hi


On Tuesday 19 April 2011 at 11:56:30 AM, in
Post by Faramir
It would still be
vulnerable to a complete rainbow table for SHA-256, but
if such rainbow table exists at all, then we are all
toasted, no matter what password we use, it would still
be found.
Doesn't the use of a salt defeat rainbow tables?

- --
Best regards

MFPA mailto:expires2011 at ymail.com

CAUTION! - Beware of Warnings!
Mark H. Wood
2011-04-18 15:46:29 UTC
Permalink
I think the author of the page was on his way to saying something
important but got sidetracked. Whether his math works or not is
secondary to the bit I think is important.

It's easy to build gadgets which yield passwords that are
mathematically very strong. The problem is that such passwords tend
to be psychologically and pragmatically weak: you'll never remember
"dishGhebJactotCerUnJodNavhahifbobTyWodvacushdojHashJakfawnairvak".
Instead you'll wind up writing it on a scrap of paper and carrying it
with you, and any pickpocket could take it. The essence of a password
or passphrase is that it is something you just learn, so that it
cannot be taken from you without violence.

So an "all-around strong" key generation method must take into account
psychology as well as cryptology. Its output must at the same time be
easy to learn, difficult to guess, and infeasible to calculate. The
obscured point in the article is that insisting solely on
ever-increasing mathematical complexity is psychologically unsound.
It tends to make the system's users into another class of adversary
whose goal is to bypass the complexity rules so he can get logged on
and do work without first spending an hour trying to recall something
that looks like line noise. A legitimate user should not have to
crack his own password more than three or four times in a decade.

--
Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20110418/0fd68cee/attachment.pgp>
Robert J. Hansen
2011-04-18 16:11:24 UTC
Permalink
Post by Mark H. Wood
It's easy to build gadgets which yield passwords that are
mathematically very strong. The problem is that such passwords tend
to be psychologically and pragmatically weak: you'll never remember
"dishGhebJactotCerUnJodNavhahifbobTyWodvacushdojHashJakfawnairvak".
I know lots of people who have memorized their 23-digit credit card +
expiration date + security code. A Base-64 encoding of a 128-bit hash
algorithm is 22 characters long.

Strong passphrases are well within the realm of human feasibility. They
just require a level of work most people are not willing to give. But
if you need a 128-bit passphrase, you can do it: it will just take a few
hours of drill and memorization repeated over a few days.

Really, what it boils down to is this: there are no shortcuts to making
high-entropy easily-human-memorizable passphrases. Sooner or later,
you've got to pay the piper...
Post by Mark H. Wood
It tends to make the system's users into another class of adversary
whose goal is to bypass the complexity rules so he can get logged on
and do work without first spending an hour trying to recall something
that looks like line noise.
Not only this, but it also produces an ideal environment for attackers.
It sets the security administrators up as the enemy of the people who
are actually doing the work -- which means that the people "in the
trenches," so to speak, will develop an us-versus-them culture in which
the security mechanisms are deliberately subverted just in order to get
work done. In that environment, a malicious attacker who comes in and
begins subverting mechanisms looks no different than an authorized user
who is executing a legitimate task -- and the attacker will likely be
able to deceive authorized users into helping the skulduggery ("hey, can
I borrow your login and password, the damn system's rejecting mine
again...").
Andrew Long
2011-04-18 16:31:48 UTC
Permalink
Post by Robert J. Hansen
Post by Mark H. Wood
It's easy to build gadgets which yield passwords that are
mathematically very strong. The problem is that such passwords tend
to be psychologically and pragmatically weak: you'll never remember
"dishGhebJactotCerUnJodNavhahifbobTyWodvacushdojHashJakfawnairvak".
I know lots of people who have memorized their 23-digit credit card +
expiration date + security code. A Base-64 encoding of a 128-bit hash
algorithm is 22 characters long.
Now insist that they change them every month. And that they have a different one for every application that they use. Single Sign On is a grat idea, but unlikely to be practical in the near future.

Regards, Andy
--
Andrew Long
andrew dot long at mac dot com





-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 275 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20110418/318479d8/attachment-0001.pgp>
Mark H. Wood
2011-04-18 17:02:05 UTC
Permalink
Post by Robert J. Hansen
Post by Mark H. Wood
It's easy to build gadgets which yield passwords that are
mathematically very strong. The problem is that such passwords tend
to be psychologically and pragmatically weak: you'll never remember
"dishGhebJactotCerUnJodNavhahifbobTyWodvacushdojHashJakfawnairvak".
I know lots of people who have memorized their 23-digit credit card +
expiration date + security code. A Base-64 encoding of a 128-bit hash
algorithm is 22 characters long.
Oh, sure -- I do that too. But the CC memorization problem seems a
lot easier. First, it's all digits, not a typical Base64 mishmash.
Second, it's not a 23-digit number; it's a 16-digit number, a date,
and a 3-digit number. The hardest part by far is the 16-digit number.
But since that number doesn't have any particular meaning to me *as a
number*, it can be further broken down to a sequence of four
four-digit sequences. Four four-digit numbers, a date, and a
three-digit number doesn't sound difficult at all -- it's only six
symbols. Chunking at useful level(s) can greatly assist learning.

OTOH if there are any useful groupings in "c2l4IHdvcmRzIGxvbmcuCg=="
they are not readily visible to me. My eye tends to slide right past
it without taking anything in.

This is why I tend to use something like APG to generate strings of
nonsense *syllables*. If I can pretend it's a word, it's a lot easier
for me to learn, because can I learn a handful of syllables instead of a
long patternless jumble of individual characters. It engages auditory
memory and can expose verbal handles for association.
--
Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20110418/d12641a3/attachment.pgp>
Grant Olson
2011-04-18 18:09:30 UTC
Permalink
Post by Mark H. Wood
OTOH if there are any useful groupings in "c2l4IHdvcmRzIGxvbmcuCg=="
they are not readily visible to me. My eye tends to slide right past
it without taking anything in.
This is why I tend to use something like APG to generate strings of
nonsense *syllables*. If I can pretend it's a word, it's a lot easier
for me to learn, because can I learn a handful of syllables instead of a
long patternless jumble of individual characters. It engages auditory
memory and can expose verbal handles for association.
There are more than a few password managers and generators that do have
the option to create pronounceable passwords like you're talking about.
Gibberish, but where the consonants and vowels are arranged in a way
where you can read it out loud:

https://encrypted.google.com/search?hl=en&&q=pronounceable+password+generator
--
Grant

"I am gravely disappointed. Again you have made me unleash my dogs of war."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 570 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110418/180f2316/attachment.pgp>
Grant Olson
2011-04-18 18:10:35 UTC
Permalink
Post by Grant Olson
Post by Mark H. Wood
OTOH if there are any useful groupings in "c2l4IHdvcmRzIGxvbmcuCg=="
they are not readily visible to me. My eye tends to slide right past
it without taking anything in.
This is why I tend to use something like APG to generate strings of
nonsense *syllables*. If I can pretend it's a word, it's a lot easier
for me to learn, because can I learn a handful of syllables instead of a
long patternless jumble of individual characters. It engages auditory
memory and can expose verbal handles for association.
There are more than a few password managers and generators that do have
the option to create pronounceable passwords like you're talking about.
Gibberish, but where the consonants and vowels are arranged in a way
https://encrypted.google.com/search?hl=en&&q=pronounceable+password+generator
DOH! Need more caffeine. I thought you were saying you wished APG had
that feature.
--
Grant

"I am gravely disappointed. Again you have made me unleash my dogs of war."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 570 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110418/9ad3a568/attachment.pgp>
Robert J. Hansen
2011-04-18 18:29:40 UTC
Permalink
Post by Mark H. Wood
Oh, sure -- I do that too. But the CC memorization problem seems a
lot easier. First, it's all digits, not a typical Base64 mishmash.
YMMV, but to me a glyph is a glyph is a glyph.
Post by Mark H. Wood
Second, it's not a 23-digit number; it's a 16-digit number, a date,
and a 3-digit number.
The date is usually encoded as four digits. On mine, for instance, it
reads 0112. A 16-digit number, a four-digit number and a three-digit
number turns into a 23-digit number. I personally chunk it into five
groups of four and one group of three.
Post by Mark H. Wood
OTOH if there are any useful groupings in "c2l4IHdvcmRzIGxvbmcuCg=="
c2l4 IHdv cmRz IGxv bmcu Cg==, as six chunks of four, took me about
fifteen minutes spread out over ninety minutes to memorize. However, it
is not beyond the realm of possibility that I am a freak of nature. :)
Ingo Klöcker
2011-04-18 19:45:07 UTC
Permalink
Post by Robert J. Hansen
Post by Mark H. Wood
Oh, sure -- I do that too. But the CC memorization problem seems a
lot easier. First, it's all digits, not a typical Base64 mishmash.
YMMV, but to me a glyph is a glyph is a glyph.
Post by Mark H. Wood
Second, it's not a 23-digit number; it's a 16-digit number, a date,
and a 3-digit number.
The date is usually encoded as four digits. On mine, for instance,
it reads 0112.
Yes, it's four digits. But it's also a month (there are only 12) and a
year (which most likely is less than a few years later than today).
Therefore comparing four digits representing a date with a random group
of four digits without apparent meaning is a bit weird. Also, I'd
remember the date as January 2012 and not as Oh-One-One-Two.
Post by Robert J. Hansen
A 16-digit number, a four-digit number and a
three-digit number turns into a 23-digit number. I personally chunk
it into five groups of four and one group of three.
Post by Mark H. Wood
OTOH if there are any useful groupings in
"c2l4IHdvcmRzIGxvbmcuCg=="
c2l4 IHdv cmRz IGxv bmcu Cg==, as six chunks of four, took me about
fifteen minutes spread out over ninety minutes to memorize. However,
it is not beyond the realm of possibility that I am a freak of
nature. :)
No. You are actually slow. :-p
There are techniques which allow people trained in those techniques to
remember such a string of characters in a much shorter time, e.g. you
could "invent" a story with 22 words starting with the 22 characters.

As you wrote in another message: This doesn't come for free. One has to
train this.

FWIW, I have a fairly complicated totally random 20-character passphrase
(letter, digits, symbols) which I have memorized pretty quickly after
using it for a few days having to type it each time I start my computer.
(I memorized it without using any of those techniques I referred to
above.) Then again, I can't really tell you this passphrase. I can type
it (with all 10 fingers) but I couldn't tell it to you without
simulating typing it. Maybe I'm a freak of nature. :-)
Or maybe that's just how 10-finger-typing works.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110418/1d7edbc8/attachment.pgp>
Mark H. Wood
2011-04-19 14:14:31 UTC
Permalink
Well, memory seems to be a highly individual thing. Mine is not so
good in some ways, and I've had to learn to search for the kinds of
patterns that I find memorable.

Frequent use helps too: I've learned to put repeating "touching base"
notes on my calendar to make me learn passwords to things which are
infrequently accessed but urgent when I do need them. (I don't put
the passwords in the calendar, of course!)

Incidentally, I've sometimes substituted a mechanical nonsense word
into a phrase, mostly just to satisfy some nag about "you should
switch to a passphrase". So I wound up with things like:

Paul McCartney fakbetyest Abbey Road Studios

I don't expect it to be much stronger than the nonsense word alone,
but perhaps it will encourage a complex cracker to waste time on
clever shortcuts before falling back to brute force. These I find
more or less equally memorable as the word alone.
--
Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20110419/9c161b03/attachment.pgp>
Robert J. Hansen
2011-04-17 23:40:56 UTC
Permalink
I was thinking about that, between words, there is only a BLANK
SYMBOL, same value of any other given symbol. Well, from point of view
of math, nothing changes, all "data", but from "knowledge" point of
view about human behaviour it is possible that it's have some kind of
relevance.
Yeah, more or less.

Elsewhere on his site he says that if you can't use spaces in a password, you should use dashes rather than just concatenate letters together: "this-is-fun" as opposed to "thisisfun." He's quite adamant this is necessary for the security of your password. Unfortunately, it just isn't so: if I'm running a Markov chainer to generate possible plaintext passwords, what symbol(s) I use as interword marker(s) is(are) completely arbitrary: it doesn't significantly affect the time to generate text.

So, yeah, like I said: I give a big yuk to his methodology.
Hedge Hog
2011-04-17 23:09:36 UTC
Permalink
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
His math doesn't work. ?I call shenanigans on the entire thing.
Correct. But do you claim the ideas are shenanigans:
a) use several words.
b) choose memorable combinations, to you, of these words.

Example: What do you make the _expected_ secure time _estimate_ of:
a) three four letter words say: muck, ruck, puck?
b) make them memorable: the puck in the ruck in the muck?

Then, for a), what is the estimate if one choose three five letter
words, or three six letter words?

Best wishes.
_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
--
????' ??? ??????, ???' ?????? ?? ????
[The fox knows many things, but the hedgehog knows one big thing.]
? Archilochus, Greek poet (c. 680 BC ? c. 645 BC)
http://wiki.hedgehogshiatus.com
Robert J. Hansen
2011-04-18 00:15:12 UTC
Permalink
The idea of "use several words in a combination that's only meaningful and predictable to you" is a good one. That's not in debate. The idea of "this is fun" being a passphrase that will require 2,500 years of attacks to break is just absolute balderdash.
Post by Hedge Hog
a) three four letter words say: muck, ruck, puck?
b) make them memorable: the puck in the ruck in the muck?
Can't be answered. In what kind of a system? What kind of technology can the attacker employ? Does the attacker have any knowledge about what the key material is probably like ("cribs", in cryptanalytic jargon)? What kind of budget? What's the attacker's skill level? What's... etc.

If we assume the attacker knows you're using English or something close to it, then I'm going to estimate it at about 2.5 bits of entropy per glyph, or about a billion combinations for a 20-character passphrase. This is enough to stymie a high school student who's running a brute-forcer he wrote in pure Python running on a single terminal in his high school computer lab, but it's literally seconds of work for a major corporation that can easily throw a thousand terminals running hand-tuned Assembly brute-forcers at it.
Hedge Hog
2011-04-18 01:25:21 UTC
Permalink
The idea of "use several words in a combination that's only meaningful and predictable to you" is a good one. ?That's not in debate. ?The idea of "this is fun" being a passphrase that will require 2,500 years of attacks to break is just absolute balderdash.
OK, but to my mind 'this is fun' is an example of the idea. But we
differ on definition of idea, so it is likely won't agree on whether
the '2,500 years' is a incorrect illustration of an idea or an
incorrect idea :)
Post by Hedge Hog
a) three four letter words say: muck, ruck, puck?
b) make them memorable: the puck in the ruck in the muck?
Can't be answered. ?In what kind of a system? ?What kind of technology can the attacker employ? ?Does the attacker have any knowledge about what the key material is probably like ("cribs", in cryptanalytic jargon)? ?What kind of budget? ?What's the attacker's skill level? ?What's... etc.
I'd be interested in the result that comes from the same assumptions
you just used to refute his calculations. That is those that gave you
the result 'equals ten seconds to break it -- not the 3 minutes he
claims'
If we assume the attacker knows you're using English or something close to it, then I'm going to estimate it at about 2.5 bits of entropy per glyph, or about a billion combinations for a 20-character passphrase. ?This is enough to stymie a high school student who's running a brute-forcer he wrote in pure Python running on a single terminal in his high school computer lab, but it's literally seconds of work for a major corporation that can easily throw a thousand terminals running hand-tuned Assembly brute-forcers at it.
I am genuinely interested in _roughly_ how much 'expected secure time'
the phrase 'the puck in the ruck in the muck' (eight words) would buy
you over some random 8 letter string.
Don't go overboard on 'the Science'. Twenty minutes with someone
'suitable' - maybe even your high school student - and a $5 budget for
a hammer and they _will_ have your passphrase/password, or your life.

Best wishes
--
????' ??? ??????, ???' ?????? ?? ????
[The fox knows many things, but the hedgehog knows one big thing.]
? Archilochus, Greek poet (c. 680 BC ? c. 645 BC)
http://wiki.hedgehogshiatus.com
Doug Barton
2011-04-18 02:19:26 UTC
Permalink
Post by Hedge Hog
Twenty minutes with someone
'suitable' - maybe even your high school student - and a $5 budget for
a hammer and they_will_ have your passphrase/password, or your life.
True, a determined attacker will always be able to get access to your
encrypted data. The trick is to make the difficulty of making that
happen more costly than the value of the data.


Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
Hedge Hog
2011-04-18 02:32:27 UTC
Permalink
Post by Doug Barton
Post by Hedge Hog
Twenty minutes with someone
'suitable' - maybe even your high school student - and a $5 budget for
a hammer and they_will_ ?have your passphrase/password, or your life.
True, a determined attacker will always be able to get access to your
encrypted data. The trick is to make the difficulty of making that happen
more costly than the value of the data.
I think the point of the blog post was to point out (not for the first
time), that the real trick is to make it easier, to make it costly for
the squeemish ;)

Best wishes
Post by Doug Barton
Doug
--
? ? ? ?Nothin' ever doesn't change, but nothin' changes much.
? ? ? ? ? ? ? ? ? ? ? ?-- OK Go
? ? ? ?Breadth of IT experience, and depth of knowledge in the DNS.
? ? ? ?Yours for the right price. ?:) ?http://SupersetSolutions.com/
--
????' ??? ??????, ???' ?????? ?? ????
[The fox knows many things, but the hedgehog knows one big thing.]
? Archilochus, Greek poet (c. 680 BC ? c. 645 BC)
http://wiki.hedgehogshiatus.com
Robert J. Hansen
2011-04-18 03:42:22 UTC
Permalink
Post by Hedge Hog
I'd be interested in the result that comes from the same assumptions
you just used to refute his calculations. That is those that gave you
the result 'equals ten seconds to break it -- not the 3 minutes he
claims'
Depending on who you refer to, English words have between 1.5 and 2.5 bits of entropy per glyph. There are a ton of different credible resources, all of which have different answers: Wikipedia says that it's between 0.6 and 1.5 bits per glyph. Assuming 2.0 bits per glyph is optimistic, but it's within the realm of possibility.

An 11-character password has 22 bits of entropy, or about four million possibilities. Four million divided by one hundred attempts per second (the number this guy claimed was reasonable for login attempts per second to a web service) equals 40,000 seconds, or just over 11 hours.

With that, you can do the math yourself to make your own back of the envelope calculations. Don't trust my math: trust your own math. :)
Post by Hedge Hog
I am genuinely interested in _roughly_ how much 'expected secure time'
the phrase 'the puck in the ruck in the muck' (eight words) would buy
you over some random 8 letter string.
And, like I told you, without a lot of context this question literally cannot be answered.
Andre Amorim
2011-04-17 23:27:15 UTC
Permalink
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
I am giving a great big yuk to his methodology. ?There's no reference to the entropy of text, for instance. ?His example of a three common word password, "this is fun," amounts to a total of 11 letters
I was thinking about that, between words, there is only a BLANK
SYMBOL, same value of any other given symbol. Well, from point of view
of math, nothing changes, all "data", but from "knowledge" point of
view about human behaviour it is possible that it's have some kind of
relevance.

--Kind Regards
AA
Faramir
2011-04-18 11:02:47 UTC
Permalink
Post by Robert J. Hansen
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
I am giving a great big yuk to his methodology. There's no reference to the entropy of text, for instance. His example of a three common word password, "this is fun," amounts to a total of 11 letters
I was thinking about that, between words, there is only a BLANK
SYMBOL, same value of any other given symbol. Well, from point of view
of math, nothing changes, all "data", but from "knowledge" point of
view about human behaviour it is possible that it's have some kind of
relevance.
And I was thinking that before attempting to bruteforce something, we
should try using symbols as separators between words, it is easier to
type wordnumbersymbolword than to put numbers and symbols between words...

Fortunately, I have not found a password cracking tool, for free,
capable of doing that.

Best Regards
Carsten Aulbert
2011-04-18 10:04:23 UTC
Permalink
Hi
Post by Robert J. Hansen
His math doesn't work. I call shenanigans on the entire thing.
I'd like to add a F-ACK to that statement, out of curiosity I tried cracking
"J4fS<2" with CUDA multiforcer and it took less than 15 minutes on a single
GF200 class card (the program tells me that it did about 490 million MD5
hashes per second)...

With that I'd estimate everything below 9 or 10 characters based on a random
combination of these characters should be considered broken or very likely to
be broken:
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

I'm currently running the "quick brown fox" using a dictionary "attack" (also
salted MD5 based), but that is usually only successful, if the correct
combination rules are being considered...

Just my inflationary ?0.023

Cheers

Carsten
Doug Barton
2011-04-18 01:31:43 UTC
Permalink
I agree that the description of baekdal's use case is pretty limited,
and his math may be optimistic. OTOH this page seems to cast doubt on
the idea that even comparatively simple passwords can be cracked in very
short time periods, and more importantly that length is more important
than complexity in any case:

http://blogs.mcafee.com/mcafee-labs/password-policy-length-vs-complexity

On the other other hand, if passwords are so easy to crack, why use them
at all? :)


Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
Grant Olson
2011-04-18 02:50:17 UTC
Permalink
Post by Doug Barton
I agree that the description of baekdal's use case is pretty limited,
and his math may be optimistic. OTOH this page seems to cast doubt on
the idea that even comparatively simple passwords can be cracked in very
short time periods, and more importantly that length is more important
http://blogs.mcafee.com/mcafee-labs/password-policy-length-vs-complexity
On the other other hand, if passwords are so easy to crack, why use them
at all? :)
That's back-of-the-envelope math, based on having to resort to a brute
force attack. If you're using English words, then ask yourself how many
letters can follow the letter q. There's obviously only one, and that's
u. Now those two characters that should have 26^2 possibilities
according to the back-of-the-envelope math really only be 26^1
possibilities.

Allow me to digress for a little bit. I've been reading a book on Game
Theory. It explained the best possible strategy for winning
rock-paper-scissors. If you don't already know the answer, take a
second and try come up with an ideal strategy for the game.

It turns out the perfect strategy is to make real random selections. If
you do this, over time you'll end up with a 50% win rate against any
opposing strategy.

If you attempt to use any strategy other than that, your opponent can
develop a counter-strategy that beats you. And then you can develop a
counter-counter-strategy to beat them. And they can... Well it's like
that scene in the Princess Bride where the villain analyzes the hero's
strategy to determine which cup is poisoned. You can't win.

Back to passwords.

If you develop a completely random string consisting of nothing but a-z
and a minimum length of 15, then yes it will take on average half the
total time listed in that article to crack the password. And yes, that
is better than the eight digit "p at ssw0rd".

But if you don't, and you use a dictionary word, or a dictionary word
with l33t-sp34k, or two dictionary words, your opponent can develop a
strategy that beats the average case brute force time. And your
opponent actually does this now. The McAfee article conveniently
ignores that the Cane & Abel can do dictionary attacks, and it can do
rainbow table lookups.

Given how much I've seen the original article you posted in the last few
weeks, I'm sure the people who write password crackers are coming up
with multiple-dictionary-word strategies, assuming they haven't already.

And the kicker is, even if they run through all of these strategies and
must eventually fall back on a brute-force attack, it's not much more
computationally expensive to do so. All these strategies might account
for something like 1% of the total search space. They'll still
ultimately get the totally random password in about the same average
time, but they'll get many not-so-random passwords out of the way much
much more quickly.

The seventeen character "imtoosexyformycar" may be much much easier to
hack than the seventeen character "qkgfnroefdsoeyhzz" depending on your
opponent's strategy, and it may not, but it'll never be significantly
slower.
--
-Grant

"Look around! Can you construct some sort of rudimentary lathe?"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 565 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110417/acdf070f/attachment.pgp>
Faramir
2011-04-18 13:19:47 UTC
Permalink
El 17-04-2011 23:50, Grant Olson escribi?:
...
Post by Grant Olson
But if you don't, and you use a dictionary word, or a dictionary word
with l33t-sp34k, or two dictionary words, your opponent can develop a
strategy that beats the average case brute force time. And your
opponent actually does this now. The McAfee article conveniently
ignores that the Cane & Abel can do dictionary attacks, and it can do
rainbow table lookups.
Yes, and I'm thinking we should include symbols between words (but I'm
not saying we should not also use them anywhere else).
About rainbow tables, probably the author used that hash to have
something to break, I mean, to bruteforce something, you need something
that is not the plain text password, it may be an encrypted file, or a
hashed value. I don't know if there are rainbow tables for SHA-256, but
so far I have not seen a site with the complete set for MD5 (maybe I
have not searched enough).

...
Post by Grant Olson
The seventeen character "imtoosexyformycar" may be much much easier to
hack than the seventeen character "qkgfnroefdsoeyhzz" depending on your
opponent's strategy, and it may not, but it'll never be significantly
slower.
Right said, eh, Grant ;)

The good thing is we are not forced to chose words just from English
dictionary... we can mix from several languages, including Klingon, plus
symbols... If the attacker knows too much about us to be able to design
a custom strategy to do a mixed dictionary attack, maybe they can also
use the 5 dollars hammer strategy. For remote attackers, maybe they
won't know that much about us.

Still, I'm considering my bullet-proof more-than-128-bits-of-entropy
passphrase might be not as hard as it might be :P

Best Regards
Andrew Long
2011-04-18 16:19:13 UTC
Permalink
<snip/>
On the other other hand, if passwords are so easy to crack, why use them at all? :)
"On the gripping hand'...

Sorry, couldn't resist channelling a bit of Niven/Pournelle ;-)

Regards, Andy
--
Andrew Long
andrew dot long at mac dot com
Avi
2011-04-18 19:43:51 UTC
Permalink
I know I'm late to the party, and forgive me if someone posted these links
already, but the two essays I found most informative and helpful when trying
to create secure passwords were:

<http://www.schneier.com/blog/archives/2007/01/choosing_secure.html>

<http://www.lockdown.co.uk/?pg=combi&s=articles>

--Avi

----
User:Avraham

pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) <avi.wiki at gmail.com
Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E
29F9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110418/b3b12067/attachment.htm>
Fraser Tweedale
2011-04-20 00:41:47 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
http://www.baekdal.com/tips/password-security-usability
- --
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
iQEcBAEBCAAGBQJNq26WAAoJEFzGhvEaGryEIvUIANLm+kRj6jD9uRvYvEbCRPH/
S+aLZ5k9eE4KnQM6RZ2GSamdtbaz3Fp0pn22IX0s2zRmqG2euRpQtf3mBdFdmGpI
rGwURRvSa1yu4g+V71r8DxezoYgOHFQYJQMbZRBTa7/3u6U2JyNA3F10/8LMXx0b
/J8NeD82lKvJJedC1Jd74KTJMGQuNaOLymbxWXciSbCDCRB4j18/oNm582UZerLi
frISyUAXARFqpokFc7/JdtsprTIXPwkXyY+dUyu1ue0YkCu4GYzDBCYGOKAMxT1u
6UFag4I0qd1vmLC63/UGuVwM8rRnKZqc1tCd7jS8bvTFrDM3cqlhl/yT6VzboQI=
=w6it
-----END PGP SIGNATURE-----
_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
FYI, This is the topic of the upcoming episode of Security Now.

Via Twitter:

(11/04/20 04:30) SGgrc: NEXT SECURITY NOW topic: "The security of short
sentences as passphrases." http://bit.ly/hmYfUJ <-- What I think he got
wrong

Regards,

Fraser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: </pipermail/attachments/20110420/3df77132/attachment.pgp>
Robert J. Hansen
2011-04-20 01:53:54 UTC
Permalink
Post by Fraser Tweedale
FYI, This is the topic of the upcoming episode of Security Now.
Gibson's reputation in this area is mixed. That doesn't mean what he says is wrong, but I'd suggest listening with skeptical ears -- which, you know, you really ought to be doing with everyone on the internet anyway. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 227 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20110419/21902d9d/attachment.pgp>
Nicholas Cole
2011-04-21 11:09:50 UTC
Permalink
Isn't the real problem that *any* policy (suggested or enforced)
reduces the complexity of guessing a password? The moment you start
saying "pick three words separated by a space or dash" or "pick eight
random letters" or the like you make it easier to attack a password.
My employer insists on passwords that meet a defined and public set of
criteria. I'm sure that in theory that actually makes them easier to
crack, since many millions of possibilities can be discounted.

In short: don't force a particular strategy on your users. Much
better to explain to users the general problem, and then leave it up
to them to pick a password.

Nicholas
Robert J. Hansen
2011-04-21 12:38:38 UTC
Permalink
Post by Nicholas Cole
In short: don't force a particular strategy on your users. Much
better to explain to users the general problem, and then leave it up
to them to pick a password.
Historically speaking, this has shown not to work. I'll try to dig up the HCI references if people really want, but the gist of it is people don't want to have to learn and understand: they just want to get their work done. The instant you make compliance voluntary and education-based, the vast majority of users say "meh" and choose "password" as their login credential.

The belief that security problems can be solved by educating users is a common one: it is also a deluded one. It handwaves the very serious problem of most users not wanting to be educated and being actively hostile to it. "Why do I have to learn all this propellerheaded geek stuff? I just want to get my work done!"
Jean-David Beyer
2011-04-21 13:20:51 UTC
Permalink
Post by Robert J. Hansen
Post by Nicholas Cole
In short: don't force a particular strategy on your users. Much
better to explain to users the general problem, and then leave it
up to them to pick a password.
Historically speaking, this has shown not to work. I'll try to dig
up the HCI references if people really want, but the gist of it is
people don't want to have to learn and understand: they just want to
get their work done. The instant you make compliance voluntary and
education-based, the vast majority of users say "meh" and choose
"password" as their login credential.
Way back when (1970s, I guess) we had a computer where I worked that was
networked to another one many miles away that acted as a server. We used
punched cards in those days. Passwords were up to 6 6-bit characters. To
run a job, you put a job card ahead of the stuff you wanted to run. We
had a whole box of those gang-punched and you took one and used it for
your job. The password was PASSWD. Some security. 8-(

Later I had to use multiple machines, and some I could log into with a
Teletype or similar communication device. Each had a different rule for
acceptable passwords. So there was no way I could use the same password
on all the machines. Now I now know that it is not a good idea to do
that in any case, but we were not supposed to write down our passwords.
And some required changing the password every month, so there was no way
to remember them all in any case. Even if I could remember them, I could
not even remember what login to use on each machine, and which password
went with which login so I did write them down and to hell with the
management rules.
Post by Robert J. Hansen
The belief that security problems can be solved by educating users is
a common one: it is also a deluded one. It handwaves the very
serious problem of most users not wanting to be educated and being
actively hostile to it. "Why do I have to learn all this
propellerheaded geek stuff? I just want to get my work done!"
I do not think it is entirely not wanting to be educated. But if the
education takes several hours a week to keep up with and to administer
my own responsibilities in the process( generating new passwords, and
different ones on a frequent basis, finding some way to remember them
other than writing them on a post-it note on a monitor, keeping up with
password rules (Must have letters in both cases, special characters,
digits, at least some length, not to exceed some other length, not a
simple permutation of the last few used on this system, etc. But some
require some or all of these. Some allow only letters and digits, and so
on. Who can keep up?), then management would have to budget the time so
I could do it, and they will not. There has to be a better way, and I do
not know what it is.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 09:10:01 up 5 days, 12:28, 3 users, load average: 5.32, 4.95, 4.88
MFPA
2011-04-21 22:37:13 UTC
Permalink
Hi


On Thursday 21 April 2011 at 2:20:51 PM, in
Post by Jean-David Beyer
I do not think it is entirely not wanting to be
educated. But if the education takes several hours a
week to keep up with and to administer my own
responsibilities in the process( generating new
passwords, and different ones on a frequent basis,
finding some way to remember them other than writing
them on a post-it note on a monitor, keeping up with
password rules (Must have letters in both cases,
special characters, digits, at least some length, not
to exceed some other length, not a simple permutation
of the last few used on this system, etc. But some
require some or all of these. Some allow only letters
and digits, and so on. Who can keep up?), then
management would have to budget the time so I could do
it, and they will not. There has to be a better way,
and I do not know what it is.
Your employee ID card acting as a hardware ID token, a single
passphrase to log onto your workstation, and the administrators of
each app taking care of which staff are allowed to use their system.
No further passwords/usernames are necessary, just a short timeout
feature to lock the workstation if the employee is stupid enough to
leave their ID card inserted when they leave their desk.

- --
Best regards

MFPA mailto:expires2011 at ymail.com

Dreams come true on this side of the Rainbow too!
Jean-David Beyer
2011-04-22 00:58:56 UTC
Permalink
Post by MFPA
Hi
On Thursday 21 April 2011 at 2:20:51 PM, in
Post by Jean-David Beyer
I do not think it is entirely not wanting to be
educated. But if the education takes several hours a
week to keep up with and to administer my own
responsibilities in the process( generating new
passwords, and different ones on a frequent basis,
finding some way to remember them other than writing
them on a post-it note on a monitor, keeping up with
password rules (Must have letters in both cases,
special characters, digits, at least some length, not
to exceed some other length, not a simple permutation
of the last few used on this system, etc. But some
require some or all of these. Some allow only letters
and digits, and so on. Who can keep up?), then
management would have to budget the time so I could do
it, and they will not. There has to be a better way,
and I do not know what it is.
Your employee ID card acting as a hardware ID token,
Our ID cards were good enough for military security in the late 1950s.
They had no magnetic stripe, no machine readable bar codes, no nothing.
Later they got Polaroid cards that had color pictures of us on them.
Still nothing machine readable.
Post by MFPA
a single
passphrase to log onto your workstation,
No workstations in those days. ASR-33 teletypes that you did not log
into. Later some electronic junk remote terminals by Teletype Corp.
Remember that we were still using punched cards in those days for most
work. Only the far-out people got to use dumb terminals, such as ADM-3.
It was the computer at the other end, typically a cobbled up version of
System/360 TSS for some systems, UNIX for other systems, GECOS for the
GE 635s, all different. Some times we had to log into what would now be
called a LAN in the building where the server might be first, then dial
the number of the server on that LAN, then log into that server.
Post by MFPA
and the administrators of
each app taking care of which staff are allowed to use their system.
No further passwords/usernames are necessary, just a short timeout
feature to lock the workstation if the employee is stupid enough to
leave their ID card inserted when they leave their desk.
Oh! Yes. Once I got stuck implementing security on a bunch of UNIX
servers on a battery of PDP-11/70s and Vaxes. I made it necessary for
each user to assign himself a password. I gave them 30 days and cut off
those who had not done it. I almost got lynched. I also put slowdowns in
the login program. If you got the password wrong, it waited a second
before you could try again. If you failed a second time, I doubled it,
etc. When it got up to a minute, I had it hang up on them.

People then got to leaving their terminals logged in, so I put a timer
in there and if they did no input for an hour, I logged them out. They
hated that too. That was not enough. Some @$$holes would wander around
and change passwords of people who deserted their terminals. I got so
many people mad at me that I was relieved of my responsibility for that,
thank goodness.

- --
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 20:45:01 up 6 days, 3 min, 4 users, load average: 5.48, 5.18, 5.01
Faramir
2011-04-24 03:23:39 UTC
Permalink
El 21-04-2011 10:20, Jean-David Beyer escribi?:
...
Post by Jean-David Beyer
to remember them all in any case. Even if I could remember them, I could
not even remember what login to use on each machine, and which password
went with which login so I did write them down and to hell with the
management rules.
You can store them in a password manager, it's more secure than a txt
file or a post-it on the screen. The only problem is you need a working
computer in order to be able to open de passwords database, so you still
need to remember your login for the computer...

Best Regards
MFPA
2011-04-24 09:16:15 UTC
Permalink
Hi


On Sunday 24 April 2011 at 4:23:39 AM, in
Post by Faramir
You can store them in a password manager, it's more
secure than a txt file or a post-it on the screen. The
only problem is you need a working computer in order to
be able to open de passwords database, so you still
need to remember your login for the computer...
That is not the only problem. It also requires that a password manager
is among the software your employer makes available (or allows you to
install).


- --
Best regards

MFPA mailto:expires2011 at ymail.com

A closed door is an invitation to knock
Ingo Klöcker
2011-04-24 16:47:40 UTC
Permalink
Post by Faramir
...
Post by Jean-David Beyer
to remember them all in any case. Even if I could remember them, I
could not even remember what login to use on each machine, and
which password went with which login so I did write them down and
to hell with the management rules.
You can store them in a password manager, it's more secure than a
txt file or a post-it on the screen.
That's not true. A Post-It is much more secure if you do not have to
keep the password secret from people who have physical access to your
computer. For most home users this should be the case.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110424/366bcb31/attachment.pgp>
MFPA
2011-04-25 09:55:13 UTC
Permalink
Hi


On Sunday 24 April 2011 at 5:47:40 PM, in
Post by Ingo Klöcker
A Post-It is much more secure if you
do not have to keep the password secret from people
who have physical access to your computer. For most
home users this should be the case.
That would be for home users who live alone and never have visitors
that snoop around the place. (-;

- --
Best regards

MFPA mailto:expires2011 at ymail.com

You can't build a reputation on what you are going to do
Ingo Klöcker
2011-04-25 18:04:31 UTC
Permalink
Post by MFPA
Hi
On Sunday 24 April 2011 at 5:47:40 PM, in
Post by Ingo Klöcker
A Post-It is much more secure if you
do not have to keep the password secret from people
who have physical access to your computer. For most
home users this should be the case.
That would be for home users who live alone and never have visitors
that snoop around the place. (-;
You have watched too many films were students steal their teachers'
passwords by looking under their keyboards. ;-)

If you do not live alone but still have to keep your passwords secret
from those living with you (i.e. you do not trust them) then you better
make sure those other people are either computer-illiterate or never
have unattended access to your computer.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110425/e07a3be5/attachment.pgp>
Werner Koch
2011-04-25 22:21:07 UTC
Permalink
Post by Ingo Klöcker
from those living with you (i.e. you do not trust them) then you better
make sure those other people are either computer-illiterate or never
have unattended access to your computer.
and you should also always check the cabling of your box. In particular
the keyboard cable needs to be closely checked. It's just too easy to
install a hardware sniffer.


Shalom-Salam,

Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Faramir
2011-04-26 22:47:55 UTC
Permalink
...
Post by Ingo Klöcker
Post by Faramir
You can store them in a password manager, it's more secure than a
txt file or a post-it on the screen.
That's not true. A Post-It is much more secure if you do not have to
keep the password secret from people who have physical access to your
computer. For most home users this should be the case.
Indeed. In fact, I keep some passwords on paper, just in case I can't
use my password manager (like the password to access the site where I
stored the password manager database backup. It doesn't include the
passphrase to open the backup, just in case).

By the way, I just found something interesting: an extension for
Firefox, to make different passwords for each site, but all of them
based on a single "master password", so people just need to remember 1
password, and yet knowing the password for 1 site won't grant the
attacker access to the other sites.

Here is the link:
http://trac.arantius.com/wiki/Extensions/MagicPasswordGenerator

I'm not saying that addon or that practice is safe, I'm just saying
the concept is interesting. I'm not saying it is unsafe, either.

Best Regards
Aaron Toponce
2011-04-27 09:12:46 UTC
Permalink
Post by Faramir
Indeed. In fact, I keep some passwords on paper, just in case I can't
use my password manager (like the password to access the site where I
stored the password manager database backup. It doesn't include the
passphrase to open the backup, just in case).
https://passwordcard.org

--
. 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 527 bytes
Desc: Digital signature
URL: </pipermail/attachments/20110427/ed07a707/attachment.pgp>
Faramir
2011-04-26 23:42:29 UTC
Permalink
Post by Faramir
You can store them in a password manager, it's more secure than a txt
...
how long have we been asking the industry for Single Logon? a password
manager could help to finally get that...
and at least now we have a valid purpose for a "web cam": when you move
away from your workstation that is when it locks none of this half hour
time out stuff
That would be interesting... but also annoying, if you are working at
your home, alone.
you password manager should of course execute before your keyboard
logger starts and take care to remove its tracks
If there are key loggers involved, then you are toasted, even if the
passwords are kept inside your mind instead of a password database. At
the moment you type them, they would be captured. Of course, we might
say it is better to lose one password at a time, and not the whole
database, but... well, I guess it's a personal decision (unless you have
to follow some policy).

Best Regards
Mike Acker
2011-04-27 13:02:49 UTC
Permalink
Post by Faramir
If there are key loggers involved, then you are toasted, even if the
passwords are kept inside your mind instead of a password database. At
the moment you type them, they would be captured. Of course, we might
say it is better to lose one password at a time, and not the whole
database, but... well, I guess it's a personal decision (unless you have
to follow some policy).
yep. Phil Zimmerman noted that in his original essay on PGP. If you
have a malware infection you can no longer speak to what your computer
is or is not doing.

which is why we need that software inventory tool.
--
/MIKE
Robert J. Hansen
2011-04-27 13:10:22 UTC
Permalink
Post by Mike Acker
yep. Phil Zimmerman noted that in his original essay on PGP. If you
have a malware infection you can no longer speak to what your computer
is or is not doing.
In fact, it's quite a bit worse than that. Your traffic is secure only so long as both endpoints are secure. Depending on who does the numbers, 15%-30% of all desktops are pwn3d. Even if your desktop is safe, the odds aren't good the other end will be, too.

There are many reasons why I feel OpenPGP is more or less irrelevant in the world today, outside of some very special case scenarios. This is one of the big ones: OpenPGP's necessary precondition -- that our endpoints are both securable and secured -- is not met.
Mike Acker
2011-04-27 16:56:19 UTC
Permalink
Post by Robert J. Hansen
Post by Mike Acker
yep. Phil Zimmerman noted that in his original essay on PGP. If you
Post by Mike Acker
have a malware infection you can no longer speak to what your computer
is or is not doing.
In fact, it's quite a bit worse than that. Your traffic is secure only so long as both endpoints are secure. Depending on who does the numbers, 15%-30% of all desktops are pwn3d. Even if your desktop is safe, the odds aren't good the other end will be, too.
There are many reasons why I feel OpenPGP is more or less irrelevant in the world today, outside of some very special case scenarios. This is one of the big ones: OpenPGP's necessary precondition -- that our endpoints are both securable and secured -- is not met.
*That would be 100% correct.*

This is why we need the Software Audit Tool I've discussed at times on
various boards. The Software Audit Tool will need to be on a separate,
read-only, bootable media such as a DVD. On boot-up it would mount the
C: drive of the target system and then pull a software inventory. When
complete this inventory would be audited, checking the data-time stamp
and CRC of every executable software in the inventory. This would be
checked against OEM specifications and system owner's noted. System
Owners Notes should specify: what packages are supposed to be on this
system.

this is the only way to certify a system: a running system cannot be
used to certify itself. for those who don't understand this an old and
common malware trick is to replace the directory list program. when the
system owner types dir c:\windows\*.* the modified dir list program
simply fails to report the presence of the malware programs, instead
adding the space taken by the malware back into the reported
free-space. the original dir program is hidden someplace on the c:
drive and then reported on the dir list with its orignal directory
info. if you dump the program out you get this back-up copy; but when
you run it -- the bad copy runs. the system-- has had a bug purposely
installed,-- one with produces INCOROUT (incorrect output) ,-- it has
been "pwn3d".

Wolfgang Stiller (Stiller Research ) did an inventory program as I've
described -- for DOS. We need one for Win/7. when we get it we can
begin certifying systems and once that is underway we can begin
identifying failure points which still need corrections.
--
/MIKE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110427/24c141b5/attachment-0001.htm>
Robert J. Hansen
2011-04-27 17:55:16 UTC
Permalink
On Wed, 27 Apr 2011 12:56:19 -0400, Mike Acker <Mike_Acker at charter.net>
Post by Mike Acker
This is why we need the Software Audit Tool I've discussed at times on
various boards. The Software Audit Tool will need to be on a separate,
read-only, bootable media such as a DVD. On boot-up it would mount the
C: drive of the target system and then pull a software inventory. When
complete this inventory would be audited, checking the data-time stamp
and CRC of every executable software in the inventory. This would be
checked against OEM specifications and system owner's noted. System
Owners Notes should specify: what packages are supposed to be on this
system.
Already exists: a copy of md5deep and the forensics signature database
will do it for you.

Unfortunately, as people have learned, this technique doesn't actually
work -- at least, not reliably. False positives abound all over the place.
The problem is the signature db: it simply cannot work the way people
think it should. Some system patches use data from the host system as part
of the patch. (As an example, your processor ID might be used as a unique
identifier somewhere within the code.) This means the updated executables
will not have a reproducible hash: each machine will report a slightly
different one.

You can get around this somewhat with fuzzy hashing, but in the main this
is an unresolved problem in computer forensics. You can easily tell when a
file is known-good, but just because a file isn't on the known-good list
doesn't mean it's bad -- and telling the bad apart from the good is a
Herculean task.

My next door neighbor (okay, so he lives a block away) is pretty big in
the digital forensics community: if you like, I'd be happy to ask him about
the latest research in this the next time we go out for beers (probably
Monday, to celebrate his Sunday marathon).
Mike Acker
2011-04-28 14:49:13 UTC
Permalink
Post by Robert J. Hansen
On Wed, 27 Apr 2011 12:56:19 -0400, Mike Acker <Mike_Acker at charter.net>
Post by Mike Acker
This is why we need the Software Audit Tool I've discussed at times on
various boards. The Software Audit Tool will need to be on a separate,
read-only, bootable media such as a DVD. On boot-up it would mount the
C: drive of the target system and then pull a software inventory. When
complete this inventory would be audited, checking the data-time stamp
and CRC of every executable software in the inventory. This would be
checked against OEM specifications and system owner's noted. System
Owners Notes should specify: what packages are supposed to be on this
system.
Already exists: a copy of md5deep and the forensics signature database
will do it for you.
Unfortunately, as people have learned, this technique doesn't actually
work -- at least, not reliably. False positives abound all over the place.
The problem is the signature db: it simply cannot work the way people
think it should. Some system patches use data from the host system as part
of the patch. (As an example, your processor ID might be used as a unique
identifier somewhere within the code.) This means the updated executables
will not have a reproducible hash: each machine will report a slightly
different one.
You can get around this somewhat with fuzzy hashing, but in the main this
is an unresolved problem in computer forensics. You can easily tell when a
file is known-good, but just because a file isn't on the known-good list
doesn't mean it's bad -- and telling the bad apart from the good is a
Herculean task.
My next door neighbor (okay, so he lives a block away) is pretty big in
the digital forensics community: if you like, I'd be happy to ask him about
the latest research in this the next time we go out for beers (probably
Monday, to celebrate his Sunday marathon).
I had worked with Wolfgang Stiller's program on DOS systems earlier.
and yes: it did create false positives. and it is easy to see how some
practices in software distribution and maintenance will tend to create
these false positives.

in view of the need however it is and has been my feeling that this is a
topic that needs to be pursued although I do not see is successful
solution as probable without direct vendor support. particularly in the
software inventory listings.

we shoud recognize that this inventory process is most critical for the
operating software itself: the software that is allowed to run in RING0.

In a properly secured O/S an application program can't do any damage to
its host O/S. with this in view we can take a limited approach to the
project at the start and expand it to cover application software where
vendors agree to sign on.

at all times it will be important to keep the objective in mind: we want
to certify the operating software on a selected computer system so that
we can be assured that our Encryption Software -- PGP, HTTPS, S/FTP &c
-- will be successful.

With that in mind, one element that will be needed it the System Owners
Notes. e.g. VERIFY SYSTEM C:\ as Windows7, x64, Home Premium, SP1.

Given cooperation from the OEM has provided a list of what we ought to
find, and where, we should be able to certify the system.

I would like to see MSFT convert their MSRT to perform this function.

The OEM Inventory could be obtained safely from a download using an
S/FTP connection.

So this is what I see -- as the start.

Notes
(1) modifying a load module after compilation is considered extremely
bad practice. if anyomne gets caught doing this during an install
process they need to go to the shed.
--
/MIKE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110428/28775c6e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110428/28775c6e/attachment.pgp>
Mike Acker
2011-04-28 15:29:44 UTC
Permalink
Hi,
signature verifies in all your signed posts composed in plain text.
Signature does not verify in all your signed posts composed (apparently,
as shown in the raw source) in HTML.
Best regards,
Charly
MacOS 10.6.7-MacBook Intel C2Duo 2GHz-GnuPG 1.4.11-MacGPG 2.0.17
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.6; en-US; rv:1.9.2.15)
Gecko/20110303 Thunderbird/3.1.9 Enigmail 1.2a1pre (20110426-1757)
thanks for the note

i have PGP/MIME set ON so this should not happen (and HTML has to be MIMEd )

from your note it sounds like Thunderbird is sending BOTH .txt and .html
formats. I would expect your e/mail client to selecvt one of these --
and either should verify -- which would mean the message has to carry
two signatures

we might see if anyone on the list has any info on this...
--
/MIKE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110428/70472705/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110428/70472705/attachment-0001.pgp>
Jean-David Beyer
2011-04-28 15:55:06 UTC
Permalink
Post by Mike Acker
thanks for the note
i have PGP/MIME set ON so this should not happen (and HTML has to be MIMEd )
from your note it sounds like Thunderbird is sending BOTH .txt and .html
formats. I would expect your e/mail client to selecvt one of these --
and either should verify -- which would mean the message has to carry
two signatures
we might see if anyone on the list has any info on this...
--
/MIKE
------------------------------------------------------------------------
_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
The only info I have, is this:

Error - signature verification failed; click on 'Details' button for
more information

I am running Thunderbird 2.0.0.24 on Linux.

It did come with this attachment that looks like a signature.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk25h+8ACgkQS/NNXDZDAccnJAD/Qeck95CG/1feZrnEILzWIMRt
kbHn0zSl6mP5lyxW1ZoBAI8/ptcE0jXNH7lRCpnAmLoBXhKj4K0PnNdmBmbYpFqg
=TcLe
-----END PGP SIGNATURE-----

- --
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 11:50:01 up 12 days, 15:08, 3 users, load average: 4.66, 4.94, 4.84
John Clizbe
2011-04-28 17:12:02 UTC
Permalink
Post by Mike Acker
thanks for the note
i have PGP/MIME set ON so this should not happen (and HTML has to be MIMEd )
from your note it sounds like Thunderbird is sending BOTH .txt and .html
formats. I would expect your e/mail client to selecvt one of these --
and either should verify -- which would mean the message has to carry
two signatures
we might see if anyone on the list has any info on this...
Compose window: Options --> Format --> Plain and Rich (HTML) text

Default behavior: main Window: Tools --> Options --> Composition -->
Send Options --> Text Format
--
John P. Clizbe Inet: John (a) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or
mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 886 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110428/2d864635/attachment.pgp>
Charly Avital
2011-04-28 17:55:06 UTC
Permalink
Post by Mike Acker
i have PGP/MIME set ON so this should not happen (and HTML has to be MIMEd )
from your note it sounds like Thunderbird is sending BOTH .txt and .html
formats. I would expect your e/mail client to selecvt one of these --
and either should verify -- which would mean the message has to carry
two signatures
When I set manually Thunderbird to *display* in plain text, your
signature verifies.

I have set Thunderbird to *send* in plain text (converts to plain text
if html is present).

I always compose in plain text, but I guess that when quoting html
formatted text, both formats are present.

Charly
Jean-David Beyer
2011-04-28 13:35:49 UTC
Permalink
Post by Mike Acker
this is the only way to certify a system: a running system cannot be
used to certify itself. for those who don't understand this an old and
common malware trick is to replace the directory list program. when the
system owner types dir c:\windows\*.* the modified dir list program
simply fails to report the presence of the malware programs, instead
adding the space taken by the malware back into the reported
drive and then reported on the dir list with its orignal directory
info. if you dump the program out you get this back-up copy; but when
you run it -- the bad copy runs. the system-- has had a bug purposely
installed,-- one with produces INCOROUT (incorrect output) ,-- it has
been "pwn3d".
I run Linux and I used to run the tripwire program to certify what ran
on it. What it actually did was assume at some point that all your
programs were valid, and compute some checksums of each one. Whenever
you ran the test, it would make sure the checksums were still valid.

http://sourceforge.net/projects/tripwire/

There were some serious problems, it seemed to me, with this.

First of all, I would have to install everything from the distribution
disks onto a blank machine, and trust the vendor to supply safe
software. I thought Red Hat pretty good in this respect, but could not
prove it. Trouble is that tripwire did not come with the distributions
at that time, so I had to go on line to get it, and that would run the
risk of getting my machine infected while I was on line.

The second problem is that there are a lot of updates that come down as
the system ages, and they all fail the tripwire testing. And how do I
know that the downloaded updates are correct? These days, the updates
come with checksums and sometimes have digital signatures, so they may
be OK. But for every update, I have to reset the signature database, and
that got to be so much trouble that I have not used tripwire in several
years.

There is SELINUX on my machine, but I have never enabled it.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 09:20:01 up 12 days, 12:38, 3 users, load average: 5.00, 4.67, 4.68
Mike Acker
2011-04-27 16:58:42 UTC
Permalink
Post by Robert J. Hansen
Post by Mike Acker
yep. Phil Zimmerman noted that in his original essay on PGP. If you
Post by Mike Acker
have a malware infection you can no longer speak to what your computer
is or is not doing.
In fact, it's quite a bit worse than that. Your traffic is secure only so long as both endpoints are secure. Depending on who does the numbers, 15%-30% of all desktops are pwn3d. Even if your desktop is safe, the odds aren't good the other end will be, too.
There are many reasons why I feel OpenPGP is more or less irrelevant in the world today, outside of some very special case scenarios. This is one of the big ones: OpenPGP's necessary precondition -- that our endpoints are both securable and secured -- is not met.
you are 100% correct. and this applies to HTTPS as well. also S/FTP
--
/MIKE
Nicholas Cole
2011-04-22 14:04:33 UTC
Permalink
In short: don't force a particular strategy on your users. ?Much
better to explain to users the general problem, and then leave it up
to them to pick a password.
Historically speaking, this has shown not to work. ?I'll try to dig up the HCI references if people really want, but the gist of it is people don't want to have to learn and understand: they just want to get their work done. ?The instant you make compliance voluntary and education-based, the vast majority of users say "meh" and choose "password" as their login credential.
The belief that security problems can be solved by educating users is a common one: it is also a deluded one. ?It handwaves the very serious problem of most users not wanting to be educated and being actively hostile to it. ?"Why do I have to learn all this propellerheaded geek stuff? ?I just want to get my work done!"
You know, I worded the above poorly, and for that I have only myself
to blame for the fact that you jumped on the obvious objection to a
complete free-for-all.

It probably is wise to have some sort of control in place to prevent
very stupid passwords. Even in 1997 my university had a system in
place that prevented the use of dictionary-words (including Latin and
- IIRC - Greek words) or passwords that were merely dictionary words
with a number added at the end.

What I meant was rather this: there are several strategies that
produce good passwords. Teaching them requires (at some employers) a
30 minute course or the reading of a web page. However, forcing any
*particular* strategy onto users will dramatically reduce the time it
takes to guess a password, since knowing the strategy reduces the
number of possibilities dramatically.

I thought we were talking about this particular proposal (the "use
three dictionary words" one) and my point was that if everyone were to
use this its security would be dramatically reduced. However, as one
of several strategies available to those selecting passwords, it
probably isn't a bad one in and of itself.

Nicholas
Robert J. Hansen
2011-04-22 18:17:45 UTC
Permalink
Post by Nicholas Cole
What I meant was rather this: there are several strategies that
produce good passwords. Teaching them requires (at some employers) a
30 minute course or the reading of a web page. However, forcing any
*particular* strategy onto users will dramatically reduce the time it
takes to guess a password, since knowing the strategy reduces the
number of possibilities dramatically.
Let's have a thought experiment: your particular situation is such that
you want attackers to face at least a 9-bit keyspace, but you also want
to disqualify easy, commonly-used keys.

Answer: tell users their passwords must be any number between 0 and 999
inclusive, except that it can't be in the range 0-9, or be any two- or
three-character repeating password (no 11, no 222, no 33, but 331 is
fine). This is meant to keep people from choosing weak passwords. This
has the net effect of striking 10 (0-9) + 9 (11+22+33... etc.: note that
00 is already struck under the "no 0-9" rule) + 9 (111+222+333... etc.)
= 28 possibilities.

You've reduced the original 9.97-bit keyspace to 9.92 bits, which still
exceeds your requirements. At the same time, you're preventing users
from choosing trivially weak and easily guessable passwords.

Your observation is correct only if excluding certain passphrases causes
the entropy of the keyspace to drop below your requirements. Otherwise,
there's no problem with strategy enforcement.
Devin Fisher
2011-04-21 12:56:43 UTC
Permalink
If you leave it up a user, they'll choose nothing, or the last four of the social. There should be criteria, but not public criteria.
------Original Message------
From: Nicholas Cole
Sender: gnupg-users-bounces at gnupg.org
To: gnupg-users at gnupg.org
Subject: Re: A better way to think about passwords
Sent: Apr 21, 2011 4:09 AM

Isn't the real problem that *any* policy (suggested or enforced)
reduces the complexity of guessing a password? The moment you start
saying "pick three words separated by a space or dash" or "pick eight
random letters" or the like you make it easier to attack a password.
My employer insists on passwords that meet a defined and public set of
criteria. I'm sure that in theory that actually makes them easier to
crack, since many millions of possibilities can be discounted.

In short: don't force a particular strategy on your users. Much
better to explain to users the general problem, and then leave it up
to them to pick a password.

Nicholas

_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

-Devin
Aaron Toponce
2011-04-24 13:37:54 UTC
Permalink
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
http://www.baekdal.com/tips/password-security-usability
Yeah, I've read it. It sucks. If an author claims they know something about
password security, but don't define entropy, or at least explain it, then
the article is worth a grain of salt. The math is just bad. Very, very bad.

If you really want password security, coupled with massive amounts of
entropy, and 100% platform independence, then I would suggest
https://passwordcard.org.

My thoughts on the matter:
* Entropy: http://pthree.org/?p=1761.
* Password Card: http://pthree.org/?p=1564

--
. 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 527 bytes
Desc: Digital signature
URL: </pipermail/attachments/20110424/887fdae9/attachment.pgp>
Aaron Toponce
2011-04-27 09:04:34 UTC
Permalink
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
http://www.baekdal.com/tips/password-security-usability
I'm just going to drop this here:

http://www.troyhunt.com/2011/04/bad-passwords-are-not-fun-and-good.html

--
. 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 527 bytes
Desc: Digital signature
URL: </pipermail/attachments/20110427/dc43ea6a/attachment.pgp>
Ben McGinnes
2011-04-27 13:00:49 UTC
Permalink
Post by Aaron Toponce
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
http://www.baekdal.com/tips/password-security-usability
http://www.troyhunt.com/2011/04/bad-passwords-are-not-fun-and-good.html
Nice. I noticed the author of the first article commented on the second
one too.


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110427/33f8588b/attachment.pgp>
MichaelQuigley
2011-04-28 18:28:49 UTC
Permalink
----- Message from Mike Acker <Mike_Acker at charter.net> on Thu, 28
Apr 2011 10:49:13 -0400 -----
"Robert J. Hansen" <rjh at sixdemonbag.org>
gnupg-users at gnupg.org, Faramir <faramir.cl at gmail.com>
Re: Re: Keylogers
On Wed, 27 Apr 2011 12:56:19 -0400, Mike Acker <Mike_Acker at charter.net>
<snip>
we shoud recognize that this inventory process is most critical for
the operating software itself: the software that is allowed to run in
RING0.
In a properly secured O/S an application program can't do any damage
to its host O/S.
<snip>

"In a properly secured O/S an application program can't do any damage"

No damage, yes. But additional alterations can happen. Software
installations alter the base O/S--especially the Windows registry. Keep
in mind things such as Anti-virus software need to put in hooks to
intercept normal/original processing to test files/programs.

I've wondered how this same subject works with application whitelisting.

Also, I believe device drivers still run in RING0 on Windows. Although I
haven't heard/checked whether that's still true in Windows 7.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110428/35121000/attachment.htm>
Mike Acker
2011-04-29 13:08:50 UTC
Permalink
Post by MichaelQuigley
"In a properly secured O/S an application program can't do any damage"
No damage, yes. *But additional alterations can happen*. Software
installations alter the base O/S--especially the Windows registry.
Keep in mind things such as Anti-virus software need to put in hooks
to intercept normal/original processing to test files/programs.
I've wondered how this same subject works with application whitelisting.
Also, I believe device drivers still run in RING0 on Windows.
Although I haven't heard/checked whether that's still true in Windows 7.
yep. when i was working OS/MVT I used to hate people who wanted to
install an SVC.

and so it is with Win7: if your app needs to modify the O/S then your
app has to be vetted just as though it was the O/S. because when it
"hooks in" -- it has to be treated that way.

obviously you would not want to allow any and every app program to do
that... if you did you'd have a mess on your hands. Don't we?

I have always felt the registry should be for the O/S use only. App
Programs should use their own .ini files.

one of the things we have failed to recognize is that the computers for
hobbyists, experimenters et al are different from the computers for
commercial/network/business applications.
--
/MIKE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110429/f1140277/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110429/f1140277/attachment.pgp>
Daniel Kahn Gillmor
2011-05-27 23:16:03 UTC
Permalink
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
http://www.baekdal.com/tips/password-security-usability
A computational linguist's rebuttal to Baekdal's post:

http://trochee.net/2011/05/fragments-will-not-save-us/

The takeaway: Baekdal's analysis only holds for extremely na?ve brute
force attempts. Please don't assume that all attackers will be so
na?ve.

--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: </pipermail/attachments/20110527/83c0f85c/attachment.pgp>
Andre Amorim
2011-05-27 23:25:22 UTC
Permalink
Just "blood-thing" about linguist reminds-me "language acquisition" anyways ....
Post by Doug Barton
Summary: A 3-word password (e.g., "quick brown fox") is secure against
cracking attempts for 2,537 years.
http://www.baekdal.com/tips/password-security-usability
?http://trochee.net/2011/05/fragments-will-not-save-us/
The takeaway: Baekdal's analysis only holds for extremely na?ve brute
force attempts. ?Please don't assume that all attackers will be so
na?ve.
? ? ? ?--dkg
_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
--
Gnupg key: 02375205
Fingerprint: F7CD D181 943B 0453 8668 ?AF16 84E9 7565 0237 5205
Continue reading on narkive:
Loading...