|
|
| Author |
Message |
| 25 new of 222 responses total. |
goose
|
|
response 125 of 222:
| 
Jun 7 11:10 UTC 2000 |
(RE:Icom -- I liek and trust STeve, but I've not been happy with my Icom.
I'd much rather have a Yaesu HT, and a Kenwood Mobile)
|
iggy
|
|
response 126 of 222:
|
Jun 7 12:35 UTC 2000 |
the stupidest password i hadever known anyone to have was 'password'
|
jmsaul
|
|
response 127 of 222:
|
Jun 7 12:37 UTC 2000 |
"secret" is another popular one.
|
jep
|
|
response 128 of 222:
|
Jun 7 13:02 UTC 2000 |
It's amusing, working in an office where passwords have to be changed
often. You can walk around and find out anyone's password, from the
post-it note on the front of their computer.
|
jazz
|
|
response 129 of 222:
|
Jun 7 15:42 UTC 2000 |
Yet another thing that is not commonly understood in IT is that
convenience, security, and ease of setup are related in a Heisenbergian way.
The more security you have, the less convenience or ease of setup ...
|
rcurl
|
|
response 130 of 222:
|
Jun 7 16:08 UTC 2000 |
Most of my passwords for various systems are on postit notes on my
computer...verfy handy 8^}
|
remmers
|
|
response 131 of 222:
|
Jun 7 16:46 UTC 2000 |
The last time Grex forced me to change my password, I came up
with what I thought was a paragon of obscurity. "Too obvious",
said the passwd program. So I chose an even more obscure-
seeming one. "Too obvious".
Finally, I chose one that seemed (to me) distinctly more obvious
than the first two. The passwd program took it without objection.
Go figure.
|
remmers
|
|
response 132 of 222:
|
Jun 7 16:50 UTC 2000 |
(Password-cracker wannabes should take note that my current
password is now different than the "more obvious" one mentioned
above. I changed it again in the wake of the recent gryps
vandalism.)
|
drew
|
|
response 133 of 222:
|
Jun 7 19:37 UTC 2000 |
If a password is not in any dictionary, is it still possible/feasible for the
crack program to find it by trial and error? Assume it to be running on a 500
MHz PC.
|
scg
|
|
response 134 of 222:
|
Jun 7 19:40 UTC 2000 |
That would depend. If it's truely a string of random characters, there's a
huge number of possibilities, and that would take a very long time. If it's
something like all numbers, all lower case letters, or something like that,
it won't be that hard.
|
mdw
|
|
response 135 of 222:
|
Jun 7 20:17 UTC 2000 |
If it's short enough, it doesn't matter how random the characters are.
Crack programs generally iterate all the possible permutations of
characters for short lengths, then use rules to generate a small set of
variations (such as mixed case, added digit, etc.) based on every entry
in a set of word lists.
The logic in passwd tries to forbid choices like this - so it forbids
passwords that are "too short", and it has its own set of word lists
which it checks. A password that fails the check in passwd is almost
certainly a bad choice. Just because it passes the check doesn't mean
it's a good choice however, the question there would be if it's
something that could be generated by a rule selected by a vandal, and
it's somewhat difficult to predict just what rules a vandal might
actually select.
|
spooked
|
|
response 136 of 222:
|
Jun 7 23:32 UTC 2000 |
The one-way Hash function on Unix password systems are all the same,
correct? If so, why?
|
mcnally
|
|
response 137 of 222:
|
Jun 8 00:38 UTC 2000 |
I don't think that is correct, actually..
|
spooked
|
|
response 138 of 222:
|
Jun 8 00:41 UTC 2000 |
I was wondering, I had a suspicion they were, but not sure. Marcus? (:
|
scg
|
|
response 139 of 222:
|
Jun 8 00:49 UTC 2000 |
My impression is that by default most but not all Unix systems use the same
hashing algorythm. There's a good standardization argument for that, since
it allows password files to be moved between systems, but I suspect it has
more to do with people creating new Unix systems tending to reuse stuff from
older systems.
However, there is nothing stopping somebody from writing their own crypt()
function. Some systems are different from others, by default. Grex has its
own password encryption function that Marcus wrote, in order to be less useful
to somebody trying to run crack on stuff here.
|
spooked
|
|
response 140 of 222:
|
Jun 8 00:51 UTC 2000 |
Yep, thanks Steve. Like I thought.
|
janc
|
|
response 141 of 222:
|
Jun 8 03:43 UTC 2000 |
Most Unix systems use crypt, which is derived from DES. Most systems
don't meddle with it, because creating good encryption algorithms is a
very subtle and sophisticated art. In many, many cases if you try to
make "improvements" you may be weakening it instead. So most people are
well advised not to fiddle with these things.
Grex has been through no less than three password encryption algorithms.
The original one was the standard Unix one, which takes the first eight
characters of your password, and converts them into a 14 character
gobbilty gook string (of which only 12 characters really count).
When we switched over to the shadow password system, we also started
using the "encrypt" password encryption algorithm that came with that.
This wanted to use more than eight characters of your password, so it
encrypted the first eight, and then the second eight with the old crypt
algorithm, giving two 12 character strings, and stored them both.
That's better, right? Wrong. In practice, if people's password is
longer than eight characters, it is usually only a few characters long.
So the second crypt is usually an encryption of strings only a few
characters long - hence easy to crack. Knowing the last few letters of
someone's password actually makes guessing the first eight easier. So
the net effect of this "improved" algorithm is that it is weaker than
the original.
Marcus replaced that with his own algorithm, which also uses more than
the first eight letters, but does it much more intelligently. It's
based on a well-established encryption algorithm called SHA.
If you want to know everything there is to know about how Grex encrypts
and stores passwords, see
http://www.cyberspace.org/staffnote/passwd.html
I've seen some talk about Linux systems using MD5 password encryption,
and various other Unix versions have used various other password
encryption techniques.
|
mdw
|
|
response 142 of 222:
|
Jun 8 03:47 UTC 2000 |
For a long time, the "standard" unix crypt() function used a version of
DES that had been hacked by the bell labs folks to randomly permute the
S table 4096 different ways (using a 12-bit value randomly generated and
stored as the first two characters of the hashed password). Many years
after the initial algorithm, after some of the properties of DES were
better understood, it was found that scrambling the S box the way bell
labs had done it actually weakened DES, but I don't think anyone ever
came up with a serious attack on crypt() based on this. More serious
problems (in practice) included the fact that since crypt() used des,
the US gov't claimed jurisdiction based on ITAR, which complicated
distribution. This wasn't a problem for binary-only distributions of
Unix though since crypt() is only used for authentication not encryption
and there are special loopholes in ITAR for authentication-only systems.
This was an issue for linux and 386bsd however. Other problems included
the inherent weakness of DES (against today's greatly enhanced CPU
power, which renders DES vulnerable to brute-force attacks), and the
widespread deployment of "crack", which made des-based crypt Unix
password files the stuff of dreams for vandals. Since there are "only"
4096 different salts, "crack" could be optimized for attack against
large password files. An additional weakness of crypt() is that it only
uses 56 bits of key information from the user password - meaning it only
works with passwords of up to 8 characters in length. Indeed,
getpass(), which is the "standard" unix function to get a password, also
has this 8 character limit wired in.
Modern versions of bsd, and very probably some versions of linux by now,
support a number of other hash algorithms in addition to the standard
des based crypt - these additional algorithms often include a larger
salt (making it harder to optimize crack), use of stronger cryptographic
functions such as md5, sha-1, or blowfish, and support for passwords of
more than 8 characters.
The hash algorithm we use here on grex differs from bsd, because the bsd
functions use the same keyspace on every machine and because they
weren't obviously adaptable for use with kerberos. The grex function
was designed to faciliate its use with kerberos in the future, so when
we migrate to that, we should be able to just dump the current shadow
file into kerberos and and not require that people change their
password.
|
keesan
|
|
response 143 of 222:
|
Jun 9 00:54 UTC 2000 |
I had no trouble getting grex to accept a password from a language that has
dictionaries (in transcription) and another account accepted a password from
another language that uses the Latin alphabet. I don't see why grex should
scan every language of Europe into its password computer. Grex might,
however, want to prevent people from using passwords with an obvious relation
to logins. Is there some program to prevent this?
It is taking much longer than usual for the login script to appear when I dial
in, or maybe it only seems that way because there is no wait message.
|
jmsaul
|
|
response 144 of 222:
|
Jun 9 01:49 UTC 2000 |
There are a number of potential bad passwords that it's very hard to scan for.
Words in languages other than English are a problem, because it's difficult
to put every language in the world into your scanning program, but you never
know what some script kiddie will come up with a handy Basque dictionary or
something. Other bad passwords are only bad for a specific user -- words
related to their loginid, names of pets, words with significance obvious to
anyone who reads the person's web page, etc. -- and they're pretty much
impossible to check for. That's why some password programs insist on numeric
characters and/or characters that aren't alpha-numeric: it cuts down on the
worst possibilities.
|
mdw
|
|
response 145 of 222:
|
Jun 9 02:08 UTC 2000 |
passwd does check for passwords that bear an "obvious" relationship to
the loginid. When I was collecting word lists out on the web, I didn't
succeed in finding a word list for every european language, nor every
language that can be transcribed using the latin alphabet. I do see in
checking that I actually do have a much better word list that somehow
never made it onto grex. Perhaps I'll do so in due course (my best
collection of words does include japanese & some swahili, among other
things.)
|
gull
|
|
response 146 of 222:
|
Jun 9 04:36 UTC 2000 |
I was going to change my password on a RedHat system, but got frustrated and
ended up leaving it. The reason is that it kept insisting my new passworld
was "too similar to the old one." They had practically nothing in common
that I could see, except for both using a capital letter as their first
character. Bah. :P I have better things to do than play "guess what I want
you to do" with a program that wants to pretend to be smarter than it is.
Grex's passwd program is quite tolerable by comparison.
|
bdh3
|
|
response 147 of 222:
|
Jun 9 04:55 UTC 2000 |
Any password that is a 'word' as spelled in a dictionary
in any language is a bad password as crack can be used
to crack it. Years ago when I ran against a large unix
password file it cracked about 25% with just an english
dictionary. When I added spanish, french, german, russian,
and a 'jargon/technical' dictionary the crack rate was close
to doubled.
|
steve
|
|
response 148 of 222:
|
Jun 9 05:51 UTC 2000 |
I believe that. Recently I have seen dictionary files for
most (and I do mean most) of the languages in Africa, eastern
european languages, and some native american. No password that
is a word in any language is safe. Not any more.
|
bdh3
|
|
response 149 of 222:
|
Jun 9 09:52 UTC 2000 |
(perhaps a separate item discussing the pitfalls of
any password that is a 'word'?)
|
