|
|
| Author |
Message |
| 25 new of 226 responses total. |
remmers
|
|
response 75 of 226:
| 
Apr 19 23:22 UTC 1995 |
I think TS is saying that since members *can* do outbound internet
access, a password-stealer has more power if he or she breaks into
a member's account that a guest account.
|
steve
|
|
response 76 of 226:
|
Apr 20 01:17 UTC 1995 |
Only marginally. If the intent is to cause problems to the
specific person, then it doesn't matter. If the intent is to
cause problems for Grex itself, its somewhat more true.
|
adbarr
|
|
response 77 of 226:
|
Apr 20 05:24 UTC 1995 |
re: 74 - STeve, would you please explain --
Some
of them then bring over the source to telnet in the hopes that it is
a modified telnet that prevents them from getting onto the net. . ."
Sorry that isn't pretty job of formatting - Thanks in advance.
|
robh
|
|
response 78 of 226:
|
Apr 20 10:40 UTC 1995 |
Some systems could prevent specific users from telnetting to
other systems by modifying the source code of the telnet program
itself. If this were the case, users could upload their own
copy of the telnet source code, compile it, and use it to
their heart's content.
Grex uses a completely different method - not sure what -
to prevent non-members from accessing the Internet directly
from Grex at all. (i.e. telnet, ftp, IRC, etc.) So even if
they compile their own telnet program, it won't work.
|
davel
|
|
response 79 of 226:
|
Apr 20 12:11 UTC 1995 |
The kernel (the central compiled-in hunk of the operating system that
provides system services to everything else) was modified so that the
services necessary to talk to the net hardware check for access permissions.
I don't know any of the details, myself, but if done right that should be
pretty bullet-proof. (And I couldn't do it myself to save my life, &
would like to know the details. Oh, well.)
|
steve
|
|
response 80 of 226:
|
Apr 20 13:30 UTC 1995 |
Rob & Dave got it right. As for the details, its fairly simple at
the top level. Find the place where the connect happens, and insert
the code to check to see if the process belongs to either root or someone
in the internet group. If they are, pass along. If not, then deny
the connect.
|
tsty
|
|
response 81 of 226:
|
Apr 20 13:37 UTC 1995 |
"multiple site telent session" equals 3+ netlinks.
|
davel
|
|
response 82 of 226:
|
Apr 20 19:02 UTC 1995 |
(I meant details as in knowing how to do it myself if I have to some time,
STeve. I may need to do something at that level one of these days, with
no one to teach me.)
|
lilmo
|
|
response 83 of 226:
|
Apr 21 00:22 UTC 1995 |
(and this isn't the place for it, methinks)
|
adbarr
|
|
response 84 of 226:
|
Apr 21 05:00 UTC 1995 |
re 81 3+ netlinks -- is this equivalent to "3+ hops" - (passing
through a device functioning as a router? Thanks tsty.
|
tsty
|
|
response 85 of 226:
|
Apr 21 10:25 UTC 1995 |
yes, adbarr, correct-o-mundo.
|
sidhe
|
|
response 86 of 226:
|
Apr 25 00:06 UTC 1995 |
Hold on just for a second. Forcing Password changes once a year serves
only to aggrevate those who have become attached to their password, and
does no other good. Let us not overrun that. Strongly suggesting a
password change after a breakin is fine., as it serves to keep the problem
in hand. The annual change-force is circumventable, and as such, it only
serves to be an obnoxious draconian-feeling device.. and silly, as you can
reverse the password immediately.so, why have it again? I have yet to see
any justification.
|
steve
|
|
response 87 of 226:
|
Apr 25 02:06 UTC 1995 |
Well, think of it this way, then: making any changes to the shadow
system is going to take time to implement and test. Should this take
precedence over anything else thats in the queue to be worked on?
|
mdw
|
|
response 88 of 226:
|
Apr 25 05:02 UTC 1995 |
I believe the idea behind the annual password change is to encourage
people to change it every so often, and to make sure that someone who
does decide to circumvent it, at least has to go to extra work to make
that choice.
It's not that anyone *wants* to be any more difficult or obnoxious about
this than necessary. The *problem* is, what do you do about the
*incredible* number of people who don't know, and don't care about
password security, but would get awfully annoyed if something bad did
happen to their account?
|
rcurl
|
|
response 89 of 226:
|
Apr 25 07:35 UTC 1995 |
Is there a script available for automatically changing my password
every time I log in (and of course informing me what it is)? This
arises from my experiment of logging in via packet radio, and realizing
that I compromise my password each time I do that.
|
remmers
|
|
response 90 of 226:
|
Apr 25 10:32 UTC 1995 |
Wouldn't the "informing you what it is" be an insecure process?
|
steve
|
|
response 91 of 226:
|
Apr 25 15:02 UTC 1995 |
I at one point had a passwd program that took a password out of
a file and changed the password to that string. Although it is an
obvious security risk for that person, it can be done. This isn't
the item to talk about that, however. We should start up another item.
For every person that bitches about having to change their password,
more than a dozen change theirs, once they realize that they should do
so. I get writes about this all the time. So far two people have
expressed displeasure over this.
Given that we have a lot of other things to do, I'm not concerned
about it. Once a year is no burden.
|
ajax
|
|
response 92 of 226:
|
Apr 25 16:13 UTC 1995 |
I agree. I still think it's a doofy policy, but not worth changing.
It seems to me that the security improvement between changing a password
once per year, as opposed to never, is negligible. But the whole thing
is too trivial to worry about. It's easier for the few people who are
attached to their passwords to run passwd twice, once per year, to retain
their password, than it is to change the current setup.
|
rcurl
|
|
response 93 of 226:
|
Apr 25 18:58 UTC 1995 |
I don't think there would be enough interest in automatic passwd changes
to warrant a separate item and, besides, this would be a "forced"
passwd change on every login. Informing me what it is would be no more
insecure than the current passwd, since I now have to enter it twice.
I would propose that the passwd be generated randomly based on a time
stamp / random-alphanumeric generator.
|
selena
|
|
response 94 of 226:
|
Apr 27 04:59 UTC 1995 |
Hey, steve, I asked you myself- and changed it, because of the
breakin. That has nothing to do with the forcing of password changes.
And I know it's more than two, if you BOTHER to go look at the 93 previous
responses!
|
sidhe
|
|
response 95 of 226:
|
Apr 29 00:17 UTC 1995 |
Well, I'd daresay it deserves more attention than you are
currently giving it.
-To staff.
|
steve
|
|
response 96 of 226:
|
Apr 29 03:15 UTC 1995 |
Really? What would you like us to shelve, in order to worl
on this?
As someone said, it's only once a year that people are forced
to change. *My* personal preference is to force the issue once
every two months. But I know I haven't the slightest chance in
hell of getting that by.
|
davel
|
|
response 97 of 226:
|
Apr 29 14:04 UTC 1995 |
What STeve said.
|
steve
|
|
response 98 of 226:
|
Apr 29 17:26 UTC 1995 |
This once-a-year policy does have the advantage of stopping
14 year old passwords, from people who like the stability of
never changing them out.
|
sidhe
|
|
response 99 of 226:
|
Apr 30 00:49 UTC 1995 |
No, steve, it doesn't.
The people who are that attached will change them, and change them
back. I'm not saying to shelve anything else. I'm merely asking you to put
it on the to-do list, at the bottom. That's all. I merely want to hear
that it will be gone, however eventually that may be.
|