90 new of 222 responses total.
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.
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.
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.
The one-way Hash function on Unix password systems are all the same, correct? If so, why?
I don't think that is correct, actually..
I was wondering, I had a suspicion they were, but not sure. Marcus? (:
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.
Yep, thanks Steve. Like I thought.
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.
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.
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.
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.
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.)
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.
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.
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.
(perhaps a separate item discussing the pitfalls of any password that is a 'word'?)
Why would machines allow hundreds of attempts on an account without shutting down the connection? Anything beyond 5 attempts is reason to disconnect.
Grex accepted a common Bulgarian word (in BGN transcription). I have not tried it yet on Albanian or Latvian or Finnish or even Romanian. How long would it take someone to find my password if they were told it was in a language of Europe, even one that does not need to be transliterated? English, German, Dutch, Swedish, Norwegian, Danish, Icelandic, French, Basque, Romansh (sp?), Portuguese, Spanish, Italian, Romanian, ten Slavic languages, Finnish, Hungarian, Latvian, Lithuanian, Latin, modern and ancient Greek, Albanian, Turkish, Welsh, Scots Gaelic, Irish Gaelic - and let's not forget every possible verbal ending (I used a verb with an ending in some other account) and plurals and adjective endings. Grex does accept combinations of English words with numbers. Like tpryan says, if you only give someone 5 guesses, there is no need to worry about other languages.
In a sophisticated attack, the encrypted password file would be taken off of Grex so the thief could play with it as long as he wanted.
WHat he said. If you care about the security of your account, do not use words in other languages.
So why would anyone want to waste time feeding every dictionary in the library into their scanner so as to be able to read my email? After that, theywould need several dictionaries to read the email (and grammar books).
They don't necessarily care about you personally. They may just want an account to work from so some other sucker gets the blame for what they're doing. They'd use other dictionaries simply because more dictionaries will bag them more passwords. As for whether they could read your email if they wanted to, keep in mind that the US does not have a monopoly on computer access or skills. The intruder who hits you might be a native speaker of whatever language your email is in. There are a heck of a lot of Russian script-kiddies out there, and there are even some working out of other slavic-speaking countries as well.
'sides which, they'd already have the dictionaries they need - they used them in the crack program.
re 154 There are things called scanners which can enter dictionaries without too much effort.
Re 157, I mentioned scanners in 154. :] For what it is worth, i am not currently using a Bulgarian password.
Most vandals would not care about keesan in particular. They would merely be trying the largest collection of words they can acquire against what they hope are the hashed passwords from grex. If they acquire the password to a real account, they hope to be able to log in, read through your e-mail to see where else you might have an account, or who your friends are, and they may then try to leverage your access to also gain access themselves to that machine. This is, in fact, how gryps was initially compromised - a site elsewhere was compromised, a grex staff member happened to have access at that site, and the vandal discovered the grex staff person's password was the same on gryps. Obviously, this is now fixed, but this is a good illustration of the line of attack many vandals pursue.
Does this mean we should not use the same passwords on grex and elsewhere? (How does one keep straight all ones passwords if they are different?)
(1) yes. (2) don't use a system that would be obvious to a vandal. Ie, "this is my grex password" would probably pass the grex password test, but a vandal might well guess that your nether.net password is something along the lines of "this is my nether.net password".
one way to keep track of passwords is to make them out of phrases which are meaningful to you, but which others, especially complete strangers, are not likely to guess. for instance, if your great-aunt from poughkeepsie always called you her little pink snickerdoodle, or something equally silly, you could easily turn that into a password along the lines of "ltpnksnrdl," assuming a system allowed passwords that long. you'd also have a built-in mnemonic for remembering the password. or, if for some reason you had managed to strongly associate grex with, say, fast-food restaurants, you could turn "would you like fries with that?" into "wylfwt?" and have another sort of built-in mnemonic for remembering the password.
I suspect neither of those examples would be accepted by most real password programs, since they consist entirely of lowercase letters.
Re #160: Don't use the same password on more than one system.
re resp:163: well, yeah, but they're not supposed to be real passwords.
Grex will accept all lower-case, if it's long enough. Generally speaking, length is more important than the number of classes of characters used for increasing the size of the key search space.
Can't telnet in. Here via web.
Stuggling with the controls.
Is this pistachio. Over.
<chsssch> Roger we read you 5x5 <chsssch> inetd had died. I restarted it.
Since the reboot the terminal server doesn't say "It may take a few moments to connect". It does take a while, though, but it just sits there appearing to have hung.
The terminal server downloads its half it's brain from gryps when it powers up. Gryps is gone, so the terminal server is running on half a brain. I am pleased to believe that some of the other staff people are working on a replacement for gryps.
does anybody know how the recent hack on the system was done? what hole they found? what process they used to exploit it?
We don't know the whole story, but we know enough to prevent a repetition. Short version: a grex staffer had the same password on grex/gryps, as well as at another well-respected "serious" site. The local site got hacked, this staffer's password was stolen (probably sniffed off the wire), and the hacker proceeded to exploit all the systems the staffer was using. Gryps was one of them. Gryps was running a very old version of freebsd. It was probably well enough hardened against an attack from "outside", but it wasn't at all hardened from an attack on the "inside". So, the vandal was able to get root on gryps. The vandal then proceeded to install a "rootkit", which was apparently designed to protect the vandal against unintended discovery. Unfortunately for the vandal, gryps was probably running a much older version of freebsd than what the rootkit was designed to run on, so it became obvious that something was broken (the "ls" command, of all things, had an obvious "off-by-4" error reading directories.) The vandal had also copied over a rather bad network sniffer. It appears to have been designed to steal passwords, but would *probably* have been very tedious to use in practice. We ran the sniffer long enough (after taking appropriate precautions) to satisfy ourselves that it *could* be used to steal passwords. The evidence suggests that the vandal was rather stupid, and we don't know that he ever actually got around to running the sniffer. So, we can *hope* he didn't have the time. Nevertheless, we don't have any proof this is so, and it's conceivable he could have stolen any # of passwords (perhaps even using another better tool) before we noticed. Gryps is down for the moment. It will probably be replaced by much better hardware running openbsd, so hopefully we won't ever need to know more about all the exact details of how the vandal compromised gryps. Also, the staff member who unluckly got compromised claims to now be using different passwords everywhere, so hopefully that will not be a problem as well.
A delightful soul in Labanon filled up /c with millions and millions of "y"'s today, courtesy of the yes program. I found it just after the last bit of disk had been eaten and got rid of it all.
Lab-anon? Is that that support group for those who want to kick their technical and scientfic habits?
What is the yes program?
Try "man yes" to see.
I just did "man yes" on my Linux system. It says:
NAME
yes - output a string repeatedly until killed
SYNOPSIS
yes [OPTION]... [STRING]...
DESCRIPTION
Repeatedly output a line with all specified STRING(s), or `y'.
--help display this help and exit
--version output version information and exit
SEE ALSO
The full documentation for yes is maintained as a Texinfo
manual. If the info and yes programs are properly
installed at your site, the command
info yes
should give you access to the complete manual.
Note that the "full documentation" in "info" is shorter than the
instructions to look in "info" for full documentation. Gnu software is
a wonderful thing, but sometimes I think the authors would benefit from
electroshock treatments.
Well, I'd expect a silly program to have silly documentation. (The last paragraph of the man page was probably auto-generated from a template that's used for all GNU software. Major GNU programs do tend to have more extensive info documentation than man documentation.)
Any ideas why the queue to log in to Grex has soared this week?
M-Net's being down? I think thats it. I've seen a slew of new logins and I kinda get the feeling that we're handing more mail than we usually do, too.
I thought of the M-net outage too, but the queue surge has just been in the last couple of days.
Trying 204.212.46.130... telnet: connect to address 204.212.46.130: Connection refused telnet: Unable to connect to remote host
inetd was dead. I just restarted it.
Is there any legitimate use for the "yes" command (other than for filling a disk)?
Long long ago, some Unix admins would flick a switch that made "rm" ask "do you really want to delete this file?" everytime you did "rm file". This was really annoying because there was then no way to turn the prompt off, so when you did "rm *" in a directory with 1000 files, you had to type "y" 1000 times. So someone wrote "yes". "yes | rm *" worked. These days you can turn on the prompt in "rm" without making it impossible to turn off, so I haven't seen anyone do "yes | rm *" for about 17 years now. I presume "yes" is still there for backwards compatibility. Lots of unix systems don't have it anymore.
Basically it's a program to pipe stupid answers to programs that ask stupid questions.. I've used it on occasion on certain installer programs when I knew in advance that everything which was going to be asked would take the same answer.
It's also funny to use in party... "if ur from bangalore and u like american girls with big booms, type !yes now"
When I tried to retrieve my mail just now here is what happened: Ok: !mail /tmp: write failed, file system is full panic: Message temporary file corrupted /tmp: write failed, file system is full terminated: IOT Should I panic? Could someone check this out? Thanx!
when I logged in just now, it took my login and passwd, started to log me in and then before giving me a prompt it went back to the login prompt complete with beep and I had to log in again. In light of recent events should I be worried about another passwd sniffer?
only if it is around your crotch... hahaha
Dave: Sounds like /tmp filled up. This shouldn't have caused you to lose any mail. Chris: I don't know what caused that, but it wouldn't have been a password sniffer. I think those just monitor packets on the network, without interupting their flow. A password sniffer would normally not be noticable.
Yeah, bad choice of word, I was thinking more of a passwd "grabber".
Trojan horse, that pretends to be the login program, but instead grabs your password, saves it, prints a "password incorrect" message, and drops you to the real login prompt so you'll never guess what happened. I haven't heard of this being done on a modern Unix system. Normally telnetd won't allocate a pseudo-tty to a new person connecting in if there are still any processes open on it, so for as long as the Trojan hangs around, nobody else would connect to that pseudo tty so nothing would happen. You'd probably have to do something clever like exploit a race condition to get the Trojan in on a pseudotty that was actually connected to someone. I don't know enough about this stuff to say it can't be done, but I'd be surprised.
An easier way: modify .login to mimic the prompt a second time. An easy way to promulgate the modified .login is with a message like "for a great time, telnet to trojan-source.com and login as sucker with the password gotcha."
I've seen programs that closely mimic the NT login screen and xlockmore
being used to troll for student passwords (and occsasionally, for the bold,
lab administrator passwords), before.
Is this why you're supposed to hit Ctrl-Alt-Del before logging into NT?
What is the proper procedure for someone who changed their password but apparently typed it wrong to obtain the correct spelling? Our friend read the book and typed in trouble at the login prompt, Wednesday, and says nobody has gotten back to her to help, or if they have, they emailed and she cannot read her mail. (I emailed staff to send me her password or phone her). Does anyone else have to dial three times on average to connect rather than getting 'no carrier'?
re: 197 -- Yes.
No, it's not. The three-fingered salute is required because it seemed a good idea to Microsoft.
Actually, that *is* the reasoning behind the Ctrl-Alt-Del combo being used for NT login. Since that's one of the few (only?) keypress combos that a user program can't catch, it's a great choice for login. It's one of the better non-obvious ideas in NT
re: 200 -- I really hope you're being sarcastic. Otherwise, I'd suggest finding someone with a two-by-four and asking them to smack the ignorance out of you.
Re #201 - You would have laughed at me during my first day at UMI. To start my computer (NT), it told me to hit Ctrl-Alt-Del to bring up the login prompt. I thought it was a practical joke until my boss assured me that it would not restart the computer. =)
I continue to get non-connections upon dialing in, also.
No, I wasn't being sarcastic. Microsoft does a lot of things that make absolutely NO sense to anyone else. Why not this? #201 explains something I didn't know, much more usefully than a 2x4 would.
Actually, under windows & dos, it's perfectly feasible to catch ctrl-alt-del. I gather under NT it's a "SAK" key - the one that engages the attention of some "trusted" part of the OS that is presumably harder to compromise, but I sure wouldn't want to bet it's impossible to compromise.
My understanding is that an OS could make *any* keystroke combination uncatchable...so long as it's a real protected-mode OS that doesn't let applications programs play with the keyboard controller, interrupt tables, etc. (like DOS, Win3.X, etc. do). Ctrl-Alt-Del is treated as special by the PC BIOS - but the BIOS stuff pretty much goes away when a protected OS takes over. The big reason to use Ctrl-Alt-Del as the uncatchable key combination in NT is that *very* few old DOS, Win3.X, etc. programs that one might want to run under NT have any legit need to intercept it.
The modem server is finally able to get the rest of its brain from the new gryps box, so modems should be working normally again.
Thank you for the fix-up. I noticed it this afternoon.
Thanks Scott!
Thanks Scott. Also thanks to Charles (arthurp) who built the new gryps for us.
THanks Charles!
can't telnet in
in via modem
only two users
beep beep
(time for a "look who's on" item!)
"Can not stop the Dancin' Chickens"
Think I'll try TalkBack or whatever it is
I couldnt get to Grex from UM using telnet. I tried several times over a two hour period. Connection was refused, and connection timed out. Came home, dialed in, no problem.
And here I thought the drop in agora activity was a big parcell of people waiting for the summer edition to show up.
Nope, net is down.
Anyone working on this? Is mail affected?
just tested email: negative function
Not sure if anybody is on this. Normally scg would be handling it, but he's on his way to the west coast at the moment. STeve sent mail to our provider, but the provider may be the place with the problems. Hm.
I hope the mail was sent from somewhere other than grex.
You have several choices: