Anon E. Muss wrote:
> On Fri, 19 Sep 2008 09:56:24 -0500, Allen Kistler
> wrote:
>
>> Anon E. Muss wrote:
>>> I recently noticed excessive acitivity on my router's activity LED and
>>> did a little investigating. As immediate action, I used a big hammer
>>> and firewalled off 218/8 until I can figure out what is going on here.
>>> Yesterday, it was 201/8.
>>>
>>> Below is most of output of netstat. Can someone let me know what is
>>> going on here? SynFlood?? Also, any suggestions??
>>>
>>> ===== BEGIN =====
>>> Active Internet connections (w/o servers)
>>> Proto Recv-Q Send-Q Local Address Foreign Address State
>>>
>>> [snip]
>> Welcome to the Internet. It's been here for a while. Where have you been?
>
> Been here a while.
>
>> If you have services offered to the world, lots of people are going to
>> try to break in. If you have ssh turned on with guessable usernames
>> (like, you know, root, ftp, httpd, or bin) and authentication using only
>> password enabled, eventually someone is going to guess your lame password.
>
> Not *my* password.
>
> I will go through the users and find out who used a lame-o password.
>
> Thanks for the help.

Ahh. You misunderstand: a lot of that is script kiddies, attacking your
services, and guessing good password's like Governor Palin's zipcode for her
login password on Yahoo. (Follow her adventures with Wikileaks if you're curious.)

Prime wrote:
> Sylvain Robitaille wrote:
>> Prime wrote:
>>
>>> It does no one any good to provide additional resources for newbie
>>> skript kiddies ...
>>
>> obscurity != security
>
> I don't totally agree but I do understand your point ... but why advertise?

Because it's useful to the honest people to have a hint as to what this week's
s script kiddies are using.

Prime writes:

>Unruh wrote:

>>> Unruh wrote:

>>
>> We are constrantly telling people to provide information when they post
>> here with problems. He posts his information and you attack him. That info
>> can be useful in deciding to advise him how to handle the attack.

>There is a limit ... I personally disagree with providing too much info
>in open forums ... and lets face it, half of the initial responses
>(including your first response) didn't even read correctly the log
>information that was provided.

I agree I did misread it.

>Secondly, I didn't attack him ... I pointed out in direct language
>exactly what he had done.

And the difference between :attack" and "pointed out in direct language" is
what?


>The one thing that was correct in David Brown's post was the statement
>that "... it was unnecessary to post the whole log file". I agreed then
>and my post stated a similar position now.

I would far rather he post too much info than too little. I agree that he
posted too much, but how was he to know what "too much" and "too litlle"
is? He is confused, and thus his judgement about the relevance of data is
impaired. In that case going overboard is far better than giving to little.


>I was a regular contributor to this forum many years ago and we had a
>problem then with overzealous contributors who got it wrong.

Many years ago modems were common and overposting took forever to load. No
longer true in general.


>Cheers

>Luke

Unruh wrote:

> And the difference between :attack" and "pointed out in direct language" is
> what?

Direct Language:
Congratulations ... you just posted the url's for a couple of tools that
this amateur skript kiddie is using.

Attack:
You would have to be one of the most ignoarant sys admins I've ever come
across ... idiot! why would you be so stupid as to post the urls that
this amateur skript kiddie is using ...

.... do I need to go on?

>> The one thing that was correct in David Brown's post was the statement
>> that "... it was unnecessary to post the whole log file". I agreed then
>> and my post stated a similar position now.
>
> I would far rather he post too much info than too little. I agree that he
> posted too much, but how was he to know what "too much" and "too litlle"
> is? He is confused, and thus his judgement about the relevance of data is
> impaired. In that case going overboard is far better than giving to little.

Perhaps had you not been overwhelmed with too much information you might
have read the log file correctly?

Clearly you and I need to agree to differ. Lets just leave it at that.

Cheers

Luke

Nico Kadel-Garcia wrote:
> Prime wrote:
>> Sylvain Robitaille wrote:
>>> Prime wrote:
>>>
>>>> It does no one any good to provide additional resources for newbie
>>>> skript kiddies ...
>>>
>>> obscurity != security
>>
>> I don't totally agree but I do understand your point ... but why
>> advertise?
>
> Because it's useful to the honest people to have a hint as to what this
> week's s script kiddies are using.

Ok, given the "kit" that I downloaded, the SK's ability has diminished
somewhat in the last 7-8 years.

Also, don't be under any illusions that crackers are continually
monitoring this and other forums. I'd hate to see this forum become a
swap meet for cracking tools in the name of openness for the honest people.

Cheers

Prime wrote:

> Are you prepared to publish all of the exploits, exploit analysis etc
> that you have on file ... what about a detailed look at all of the
> security measures you employ on your host(s) ... I think not.

For what it's worth, most of the exploits I've examined were readily
available, and obtained via pointers posted to newsgroups or mailing
lists I subscribe to (with an intended audience of "the good guys").
Details of how my systems are secured aren't readily available, true,
but certainly there are outlines that are. I don't feel a need to hide
everything I do, though I'm not about to divulge exactly *how* I do it.

Your post was the first I've ever seen suggesting that someone shouldn't
have posted a link to a publically available exploit tool. Then again,
I don't monitor this newsgroup as religiously as I think I should, so
very often long times go by between when I get around to reading this
group (and my returns are usually accompanied by a lot of messages that
are let go, unread).

> I've seen regular advice regarding running ssh on an obscure port to
> make it more difficult to find ... therefore obscurity = slightly
> better security.

I disagree on that, and have expressed that the notion of moving any
service (ssh included) to a non-standard port (what, exactly, is an
"obscure port"? Nmap will find ssh at any port) is completely the wrong
way to do things. There is a lot of advice out there, intended to help
secure systems that is misguided at best.

I have Ssh running on every system I manage, on TCP/22. I see lots of
evidence of attempted brute-force attacks against user passwords on at
least some of those systems. I have yet to discover a compromise that I
can show occured because of an attack against Ssh. I don't want to say
that it has never happened, but in more than 12 years as a system
administrator (including using Ssh even before its use was very
widespread), I've not *seen* a compromise that I could attribute to Ssh.

Weak user passwords can be compromised at any port. Someone looking to
break into a system, especially manually, won't be slowed very much by
having to point his/her Ssh brute-force attack at port 22222 (for
example) rather than 22.

> My point also mentioned "Newbie skript kiddies" ... why make it easy
> for them ... make them earn their stripes.

My point is that it's already easy for them. Why make it harder for
*us* to find the tools they're using than it is for them?

> I didn't see anything in a very cursory look that even indicated the
> kiddie had obtained root.

Agreed. I have the same impression. What does that have to do with
whether the OP should have posted the unsanitized command history?

> ... revealing a kiddies toys revealed nothing of any worth in the
> analysis of his problem.

Disagreed. Obfuscating the sources of the intruder's tools would have
offered us no useful information whatsoever about the scans originating
from his system (and no doubt many others out there).

> I am surprised that no one has piped in earlier demanding that he
> unplug his hosts from the net, completely wipe the affected system and
> then re-install ...

You and I agree that it doesn't appear, from the data that was posted
here, as though the system was compromised at any level higher than an
unprivileged user account. Unless the OP has evidence to the contrary,
I fail to see what a complete wipe/re-install sequence would accomplish.

> but hey ... most of you thought he was being attacked not doing the
> attacking so I guess that is easily explained.

Perhaps. It was really great of you to step up and point out the error
so quickly. Oh wait, given that your first post on the topic was to
"congratulate" the user for posting links to tools used to launch scans
and/or attacks from his system, I think that might have been someone
else ...

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Sylvain Robitaille wrote:
> Prime wrote:
>
>> Are you prepared to publish all of the exploits, exploit analysis etc
>> that you have on file ... what about a detailed look at all of the
>> security measures you employ on your host(s) ... I think not.
>
> For what it's worth, most of the exploits I've examined were readily
> available, and obtained via pointers posted to newsgroups or mailing
> lists I subscribe to (with an intended audience of "the good guys").
> Details of how my systems are secured aren't readily available, true,
> but certainly there are outlines that are. I don't feel a need to hide
> everything I do, though I'm not about to divulge exactly *how* I do it.

Ok ... so there is some merit in obscurity.


>> I've seen regular advice regarding running ssh on an obscure port to
>> make it more difficult to find ... therefore obscurity = slightly
>> better security.
>
> I disagree on that, and have expressed that the notion of moving any
> service (ssh included) to a non-standard port (what, exactly, is an
> "obscure port"? Nmap will find ssh at any port) is completely the wrong
> way to do things. There is a lot of advice out there, intended to help
> secure systems that is misguided at best.

I agree. There are better ways of doing things.


> Weak user passwords can be compromised at any port. Someone looking to
> break into a system, especially manually, won't be slowed very much by
> having to point his/her Ssh brute-force attack at port 22222 (for
> example) rather than 22.

Also agree. That was a point I made in another post ... the advice
provided in this forum should have been centred around sound security
practices including but limited to password strength and user scrutiny.


>> My point also mentioned "Newbie skript kiddies" ... why make it easy
>> for them ... make them earn their stripes.
>
> My point is that it's already easy for them. Why make it harder for
> *us* to find the tools they're using than it is for them?

I must be missing something here ...

The OP posted a netstat log that most in this forum mis-read. Had it
not been for your keen eye, the thread may well have gone off on a
completely incorrect tangent. So, props to you for getting it right!


>> I am surprised that no one has piped in earlier demanding that he
>> unplug his hosts from the net, completely wipe the affected system and
>> then re-install ...
>
> You and I agree that it doesn't appear, from the data that was posted
> here, as though the system was compromised at any level higher than an
> unprivileged user account. Unless the OP has evidence to the contrary,
> I fail to see what a complete wipe/re-install sequence would accomplish.

I wasn't suggesting that a complete wipe/re-install was called for ...
in days gone by, many in this forum would have piped in and suggested
that wiping the system was the only way to guarantee a clean system.

I was surprised that wiping the system wasn't demanded given that many
weighed in too quickly with equally unprofound advice.


[snip]

I've had enough of this thread now, we're getting nowhere ... again, we
should agree to disagree or agree to accept that others may have
different ways of doing things.

Cheers

Prime wrote:

>> I don't feel a need to hide everything I do, though I'm not about to
>> divulge exactly *how* I do it.
>
> Ok ... so there is some merit in obscurity.

Well, if you want to suggest that people not publishing their passwords
is a form of obscurity, I suppose I heartily advocate for it, even. In
the sense of "don't divulge details of commands run by an intruder on
your system," though, I most certainly don't.

> ...
> I agree. ...
> ...
> Also agree. That was a point I made in another post ...
> ...
> I must be missing something here ...

Perhaps I'm the one whose missing it, if it seems we're agreeing more
than we've said (before your last post).

> The OP posted a netstat log that most in this forum mis-read.

Yes, but our disagreement occurred when you criticised the OP for also
posting an unsanitized command-history from the intrusion on his/her
system. I disagreed with your criticism.

> I wasn't suggesting that a complete wipe/re-install was called for ...

Ok, so we agree on that as well, then ...

> I was surprised that wiping the system wasn't demanded given that many
> weighed in too quickly with equally unprofound advice.

I missed what may have been intended sarcasm, then.

> I've had enough of this thread now, we're getting nowhere ...

I don't think so: I think we've clarified points we do and don't agree
on.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On Mon, 22 Sep 2008, in the Usenet newsgroup comp.os.linux.security, in article
, Sylvain Robitaille wrote:

>Prime wrote:

>> Are you prepared to publish all of the exploits, exploit analysis etc
>> that you have on file ... what about a detailed look at all of the
>> security measures you employ on your host(s) ... I think not.
>
>For what it's worth, most of the exploits I've examined were readily
>available, and obtained via pointers posted to newsgroups or mailing
>lists I subscribe to (with an intended audience of "the good guys").

CERT? Bugtraq? Sans? Wazzat?

>> I've seen regular advice regarding running ssh on an obscure port to
>> make it more difficult to find ... therefore obscurity = slightly
>> better security.
>
>I disagree on that, and have expressed that the notion of moving any
>service (ssh included) to a non-standard port (what, exactly, is an
>"obscure port"? Nmap will find ssh at any port) is completely the
>wrong way to do things.

1. Moving a service from a "well known port" to something else. The
concept of well known ports goes back to the 1970s, and was meant to
allow others to find specific services. If a specific service isn't
meant to be offered to everyone, making it more difficult to find
may be a valid decision (I'm not sure how many zombies and skript
kiddiez do a full port-scan before "attacking"). It also may not be
the optimum solution, especially if it's the only one applied..

2. An "obscure port" is "not well known". In practice, it often means
some port number above 1024, and not a "sekrit number" like 12345 or
other numbers that appeal to the mindless.

3. man nmap and look at the '-p ' option. Most skript
kiddiez don't even know about the option, and thus accept the default
(1-1024 plus those listed in the services file supplied with nmap -
the file that comes with nmap-4.76 lists 3398 TCP ports above 1024).

>There is a lot of advice out there, intended to help secure systems
>that is misguided at best.

Agreed

>I have Ssh running on every system I manage, on TCP/22. I see lots
>of evidence of attempted brute-force attacks against user passwords
>on at least some of those systems.

One of the reasons some get unhappy with such attempts is the waste
of bandwidth. A simple solution to that problem is to configure the
firewall to block access to the SSH server for addresses that will
have no valid or imaginable reason to be trying such access. As of
mid-month, there were 2708817080 IPv4 addresses in use on 88156
networks in the world. I'm no longer amazed that people think
they need to allow SSH access from every single one of those (and
1586150216 others either unassigned or reserved by RFC3330) - after
all, you KNOW they'll be leaping onto a plane in a few minutes and
flying to Afghanistan, Armenia, Angola, Aruba, and the Aaland Islands
(or similar), and simply don't have time to white-list the address
ranges that might be used there.

Another reason some get unhappy is that they must log every failed
attempt - perhaps so they can click their tongues in disgust, and
maybe turn over this information to the Internet Police. I have no
sympathy for these either.

>Weak user passwords can be compromised at any port.

Of course

>Someone looking to break into a system, especially manually, won't be
>slowed very much by having to point his/her Ssh brute-force attack at
>port 22222 (for example) rather than 22.

They will be slowed if they must first _find_ the port. Something like
port 22222 is _somewhat_ less easy to find ("22222" is in that nmap
services file),

[compton ~]$ ls -ld a* | cut -c37-41 | grep "[0-9]\{5\}" | column
15588 02555 13004 31924 18104 15326 10940 40304 10458
16266 13167 22820 34870 10943 18430 21195 10005
[compton ~]$

but ports 31924, 34870, or maybe 21195 might be a bit more obscure. A
problem with this is that most users can't remember their own telephone
number or postal delivery code, and expecting them to remember any port
number is probably asking to much.

Old guy

>One of the reasons some get unhappy with such attempts is the waste
>of bandwidth. A simple solution to that problem is to configure the
>firewall to block access to the SSH server for addresses that will
>have no valid or imaginable reason to be trying such access. As of
>mid-month, there were 2708817080 IPv4 addresses in use on 88156
>networks in the world. I'm no longer amazed that people think
>they need to allow SSH access from every single one of those (and
>1586150216 others either unassigned or reserved by RFC3330) - after
>all, you KNOW they'll be leaping onto a plane in a few minutes and
>flying to Afghanistan, Armenia, Angola, Aruba, and the Aaland Islands
>(or similar), and simply don't have time to white-list the address
>ranges that might be used there.

In a university setting with many faculty, yes, they'll be leaping on a
plane in a few minutes to Afghanistan, Armenia, Angola, Aruba, and the
Aaland Islands,(or similar). And trying to figure out waht the IP address
range is that will be in use there is a serious task-- could take you
staying at home weeks to discover it ( eg the faculty member might discover
that an internet cafe is the onlyway to connect, or that the hotel-- what
the hell is its ip address-- charges $40 an hour for internet connectivity.



....
>but ports 31924, 34870, or maybe 21195 might be a bit more obscure. A
>problem with this is that most users can't remember their own telephone
>number or postal delivery code, and expecting them to remember any port
>number is probably asking to much.

Precisely.

Moe Trin wrote:

> CERT? Bugtraq? Sans? Wazzat?

.... and others, but Bugtraq is one I frequently get good information
from. The usual websites also (most pointed to from the SecurityFocus
website, so I won't try and get a list). I've spent less time on this
type of thing in the past couple of years, so I can't point you to the
"best" sources.

> ... If a specific service isn't meant to be offered to everyone,
> making it more difficult to find may be a valid decision ...

Well, if a specific service isn't meant to be offered to everyone, one
might argue that the first step in ensuring that, is that the service
shouldn't be *visible* to everyone, or at least it shouldn't *respond*
to everyone.

> It also may not be the optimum solution, especially if it's the only
> one applied..

absolutely.

> 2. An "obscure port" is "not well known".

Well, most people I know (with IT knowledge) are aware of TCP ports from
1 to 65535. They're pretty well-known, if not all by name. ;-)

> 3. man nmap and look at the '-p ' option.

Exactly.

> Most skript kiddiez don't even know about the option, ...

Counting on that, though, is in the same category as the misguided advice
I was referring to in an earlier post.

> A simple solution to that problem is to configure the firewall to
> block access to the SSH server for addresses that will have no valid
> or imaginable reason to be trying such access.

Yes, that's certainly advisable, as one layer of security. More to the
point, I generally advise configuring a firewall (in whatever form that
might be) to permit access only from those addresses (or address ranges)
where legitimate access is expected. As you no-doubt imagine, the
reactions I get are frequently similar to those you get, but the
approach works really well.

> Another reason some get unhappy is that they must log every failed
> attempt ....

I normally advise folks to worry about the attempts that didn't fail.
Those that failed are the result of your configuration working as it
should ...

>> Someone looking to break into a system, especially manually, won't be
>> slowed very much ...
>
> They will be slowed if they must first _find_ the port.

As quoted above, they "won't be slowed very much". In fact, in my
opinion, they won't be slowed enough to offset the inconvenience to
users who will then need to remember to send their Ssh clients to the
non-standard port.

> ("22222" is in that nmap services file),

The actual port-number in my example wasn't the point ...

> A problem with this is that most users can't remember their own
> telephone number or postal delivery code, and expecting them to
> remember any port number is probably asking to much.

Well, after all, we're asking them to remember reusable passwords too,
without using simple dictionary words! Some of us even insist that
they not write them down on a sticky-note taped to their monitors (oh
the nerve we have!)

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On Tue, 23 Sep 2008, in the Usenet newsgroup comp.os.linux.security, in article
, Sylvain Robitaille wrote:

>Moe Trin wrote:

>> ... If a specific service isn't meant to be offered to everyone,
>> making it more difficult to find may be a valid decision ...
>
>Well, if a specific service isn't meant to be offered to everyone, one
>might argue that the first step in ensuring that, is that the service
>shouldn't be *visible* to everyone, or at least it shouldn't *respond*
>to everyone.

I think that is the one that most smart people adopt. My home system
under "normal" conditions accepts connections from a /22 and two /24s
on the outside. In the somewhat rare situations when I'm traveling,
I've taken to using a port-knocking scheme (where you first attempt
to connect to an otherwise un-used port - the firewall notes the
attempt, and unblocks access to the SSH server from "that" address for
one minute). I still have to authenticate (an RSA key on a USB memory
card) so the knocking isn't really security, but more "noise
reduction".

>Yes, that's certainly advisable, as one layer of security. More to
>the point, I generally advise configuring a firewall (in whatever form
>that might be) to permit access only from those addresses (or address
>ranges) where legitimate access is expected. As you no-doubt imagine,
>the reactions I get are frequently similar to those you get, but the
>approach works really well.

We're a research facility for the company, and have somewhat less of a
"need" to log in from the outside world. This permits pretty
restrictive limits on such access.

>> Another reason some get unhappy is that they must log every failed
>> attempt ....
>
>I normally advise folks to worry about the attempts that didn't fail.
>Those that failed are the result of your configuration working as it
>should ...

Exactly. That's also why the USB dongle only provides part of the
authentication - the users still need a password that gets hashed in
to create the actual credentials.

>> They will be slowed if they must first _find_ the port.
>
>As quoted above, they "won't be slowed very much". In fact, in my
>opinion, they won't be slowed enough to offset the inconvenience to
>users who will then need to remember to send their Ssh clients to the
>non-standard port.

It's amazing how much fits into those little USB dongles today. We
are getting more concerned with 'homeland security' idiots than we used
to be. There has always been the worry about having a laptop stolen
at the security check-point, which is why filesystem encryption is more
common, but now that may result in the laptop being detained while the
CBP look for illegal files. See the stuff in news://comp.risks issues
25-28 (12 Aug, 2008) and 25-14 (2 May, 2008) including the EFF URL.

>> A problem with this is that most users can't remember their own
>> telephone number or postal delivery code, and expecting them to
>> remember any port number is probably asking to much.
>
>Well, after all, we're asking them to remember reusable passwords too,
>without using simple dictionary words! Some of us even insist that
>they not write them down on a sticky-note taped to their monitors (oh
>the nerve we have!)

The sticky-note on the monitor, or on the bottom of the keyboard (or
mouse) had a fairly short life here - we got tagged in a government
security audit many years ago, and there was hell to pay. We _try_ to
help our users by having a regular hand-out that shows ways to create
and remember more difficult passwords - the "n'th letter of the words
of a phrase/song" seems to be tolerable, and a heck of a lot more
secure than the phone number of the bookie, pizza-joint, or what-ever.

Old guy

ibuprofin@painkiller.example.tld (Moe Trin) writes:


>The sticky-note on the monitor, or on the bottom of the keyboard (or
>mouse) had a fairly short life here - we got tagged in a government
>security audit many years ago, and there was hell to pay. We _try_ to
>help our users by having a regular hand-out that shows ways to create
>and remember more difficult passwords - the "n'th letter of the words
>of a phrase/song" seems to be tolerable, and a heck of a lot more
>secure than the phone number of the bookie, pizza-joint, or what-ever.

You might want to use my program wgen which generates "words" based on a
dictionary. It takes the dictionary and calculates the occurance of the
"trigrams-- combinations of three letters, including a double init to
indicate the beginning of the word. It uses urandom to grab the next letter
based on the probability of that letter being the last letter in a set of
three as determined by teh dictionary. This produces words that are not
words but are very similar in their structure to English words. It also
puts out a "entropy" for the word (ie the number of bits of entropy for each
word based on those trigrams-- it is a rough guide.

People should grab longer words with higher bit numbers, or combine shorter
words .
Here is an example-- with max length of 10 characters

ambly [17.1833]
mainterial [24.9927]
xeno [18.3541]
rectinite [25.0441]
anneau [23.2039]
bismentram [32.0393]
beworl-air [39.8553]
gumfervivi [34.0005]
prophy [16.0704]
strusion [21.3945]
unsonnersa [30.087]
corrhaceab [26.3783]
unaceae [17.1724]
terregraem [37.0352]
letason [29.3827]
avolverra [33.715]
subhensick [30.6531]
coorsomide [37.5863]
cosis [14.3989]
airer [19.1535]


Note occasionally a real word is generated.
There is about 3 bits of entropy per letter-- some more, some less.
But "airer anneau" would have an entropy of over 40. Throw in a few
capitals or even punctuation, and you might get that up to 45 (but it is
harder than you think to "throw in random punctuation"..
(Note-- that entropy basically means that if the attacker used the same
dictionary, that is a measure of how many times he would have to try to
generate your password-- ie if the ranking is 35 it would take 2^35 = 10^10 tries.
It is also better to use longer dictionaries (I have one with 400,000
words) as it makes rarer combinations more likely. (By default it uses
/usr/share/dict/words)

If you use a text document as the dictionary, especially simple text, you are likely to get simply short
words-- since the probabilities are coumputed from the whole document,
with its repetitions of of words (a, the) biasing the results.

http:www.theory.physics.ubc.ca/wgen/wgen.c or
http:www.theory.physics.ubc.ca/wgen/wgen for the binary.

On 09/25/2008 12:03 PM, Unruh wrote:
>
>
> If you use a text document as the dictionary, especially simple text, you are likely to get simply short
> words-- since the probabilities are coumputed from the whole document,
> with its repetitions of of words (a, the) biasing the results.
>
> http:www.theory.physics.ubc.ca/wgen/wgen.c or
> http:www.theory.physics.ubc.ca/wgen/wgen for the binary.
>

wget http://www.theory.physics.ubc.ca/wgen/wgen.c
--2008-09-25 12:12:41-- http://www.theory.physics.ubc.ca/wgen/wgen.c
Resolving www.theory.physics.ubc.ca... 142.103.234.29
Connecting to www.theory.physics.ubc.ca|142.103.234.29|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2008-09-25 12:12:41 ERROR 403: Forbidden.

Unruh wrote:

> You might want to use my program wgen which generates "words" based on
> a dictionary. ...

I like it, at least as a starting point for decent passwords. Thanks
for passing that on.

> People should grab longer words with higher bit numbers, or combine
> shorter words . .... Throw in a few capitals or even punctuation, ...

Agreed.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Douglas O'Neal writes:

>On 09/25/2008 12:03 PM, Unruh wrote:
>>
>>
>> If you use a text document as the dictionary, especially simple text, you are likely to get simply short
>> words-- since the probabilities are coumputed from the whole document,
>> with its repetitions of of words (a, the) biasing the results.
>>
>> http:www.theory.physics.ubc.ca/wgen/wgen.c or
>> http:www.theory.physics.ubc.ca/wgen/wgen for the binary.
>>

>wget http://www.theory.physics.ubc.ca/wgen/wgen.c
>--2008-09-25 12:12:41-- http://www.theory.physics.ubc.ca/wgen/wgen.c
>Resolving www.theory.physics.ubc.ca... 142.103.234.29
>Connecting to www.theory.physics.ubc.ca|142.103.234.29|:80... connected.
>HTTP request sent, awaiting response... 403 Forbidden
>2008-09-25 12:12:41 ERROR 403: Forbidden.

Oops. Corrected now.

Moe Trin wrote:

> On Tue, 23 Sep 2008, in the Usenet newsgroup comp.os.linux.security,

.....
>
> The sticky-note on the monitor, or on the bottom of the keyboard (or
> mouse) had a fairly short life here - we got tagged in a government
> security audit many years ago, and there was hell to pay. We _try_ to
> help our users by having a regular hand-out that shows ways to create
> and remember more difficult passwords - the "n'th letter of the words
> of a phrase/song" seems to be tolerable, and a heck of a lot more
> secure than the phone number of the bookie, pizza-joint, or what-ever.
>
> Old guy

If you have people using a lot of different passwords each, or several,
want them to remain unique, but be secure, then in an office
environment, I always have complex passwords, but simply have the user
keep them in a PGP encrypted file that they would use their one single
complex, yet easily enough to remember, password for viewing. But, of
course, there are always problems with trying to get an office or
company full of people to remember passwords and store them safely.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!

Unruh wrote:

> http:www.theory.physics.ubc.ca/wgen/wgen.c or

Hrmmm.... not a complaint, but a suggestion for documentation:

: alcor[syl] ~; make wgen
cc wgen.c -o wgen
/tmp/ccxv11ko.o: In function `main':
wgen.c.text+0x8e7): undefined reference to `log'
wgen.c.text+0xb35): undefined reference to `log'
wgen.c.text+0xbd6): undefined reference to `log'
wgen.c.text+0xc23): undefined reference to `log'
wgen.c.text+0xc64): undefined reference to `log'
/tmp/ccxv11ko.o:wgen.c.text+0xcb1): more undefined references to `log' follow
collect2: ld returned 1 exit status
make: *** [wgen] Error 1
: alcor[syl] ~; cc -lm wgen.c -o wgen
: alcor[syl] ~; ./wgen
total trigrms= 4206391 raw ent= 2.119955e+06 tcount = 352846
Max length=10 Number=20, Entropy3=9.760737 Entropy4=12.250720
...

Again, thank you.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Tim Greer wrote:
> Moe Trin wrote:
>
>> On Tue, 23 Sep 2008, in the Usenet newsgroup comp.os.linux.security,
>
> ....
>> The sticky-note on the monitor, or on the bottom of the keyboard (or
>> mouse) had a fairly short life here - we got tagged in a government
>> security audit many years ago, and there was hell to pay. We _try_ to
>> help our users by having a regular hand-out that shows ways to create
>> and remember more difficult passwords - the "n'th letter of the words
>> of a phrase/song" seems to be tolerable, and a heck of a lot more
>> secure than the phone number of the bookie, pizza-joint, or what-ever.
>>
>> Old guy
>
> If you have people using a lot of different passwords each, or several,
> want them to remain unique, but be secure, then in an office
> environment, I always have complex passwords, but simply have the user
> keep them in a PGP encrypted file that they would use their one single
> complex, yet easily enough to remember, password for viewing. But, of
> course, there are always problems with trying to get an office or
> company full of people to remember passwords and store them safely.

Heh. I'm remembering a password based on 'The curious incident of the dog in
the night-time', where the password owner was talking about the book, and
didn't know that it's a famous Sherlock Holmes quote.