Critical Kerberos Flaw Revealed 200
doi writes "ZD Net is carrying a story about '...a critical flaw that could allow hackers to circumvent the secure networking system...The problem lies with software in MIT Kerberos 5 called kadmind4 (Kerberos v4 compatibility administration daemon), which allows compatibility with older administrative clients. A buffer stack overflow allows an attacker to use a specially formed request to gain access to the KDC with the privileges of a user running kadmind4.' It affects all MIT-derived versions of Kerberos 4 and 5."
A distinction... (Score:5, Insightful)
Fortunately, all we have to do is download a patch, which is much better than having to find something other than Diffie-Hellman key exchange...
Re:A distinction... (Score:5, Insightful)
Re:A distinction... (Score:3, Insightful)
Re:A distinction... (Score:4, Funny)
Breathe... breathe... it's just a buffer overflow...
Re:A distinction... (Score:2)
Kerberos does not use Diffie-Hellman (Score:5, Informative)
Just a slight nitpick, but AFAIK, Kerberos never used any public key cryptography at all, Diffie-Hellman or otherwise. They use the Needham-Schroeder key exchange protocol which only requires symmetric key cryptography.
Re:Kerberos does not use Diffie-Hellman (Score:2, Informative)
Diffie-Hellman Key Exchange for Kerberos V5
Abstract
The Kerberos protocol [RFC1510] currently establishes session keys by the assertion of one party (usually the KDC). This document describes a method for using the Diffie-Hellman algorithm to establish the shared secret between a Kerberos client and application service. For the purposes of this document, the Ticket Granting Service is considered an application service.
[excerpted from --
http://www.ietf.org/proceedings/99mar/I-D/dra
Re:A distinction... (Score:2)
It's not a flaw in Kerberos, it's a bug in kadmind4.
Re:A distinction... (Score:3, Funny)
Hey, it worked - at least, it sure got me to read the blurb in a hurry. (While hyperventilating, but whatever.) Maybe they did it on purpose. At least the panic attack only lasted a couple sentences. If they'd made me actually read the article to find this out....
it is only MIT Specific … (Score:4, Interesting)
Re:it is only MIT Specific … (Score:1)
Re:it is only MIT Specific … (Score:1, Funny)
Re:it is only MIT Specific … (Score:4, Informative)
Also, note that the vulnerability is not just theoretical.
Re:it is only MIT Specific … (Score:1)
heimdal because it does not support Kerberos IV which is supported by KTH.
Really about time to get a Mac."
Both the MIT and KTH implementations of Kerberos are open source.
The version that ships with MacOS is MIT Kerberos.
Re:it is only MIT Specific … (Score:2)
Re:it is only MIT Specific … (Score:2)
I know people will disagree. But, then it would have been extremely hard to have open source cryptography until recently....
Re:it is only MIT Specific … (Score:2, Informative)
Export of software employing encryption from the United States of
America may require a specific license from the United States
Government. It is the responsibility of any person or organization
contemplating export to obtain such a license before exporting.
wrong: Re:it is only MIT Specific … (Score:2)
Obsd uses Heimdal, and seemingly the krb4 compatiblity is built into the kadmind daemon. Only MIT-based sites running the kadmind4 daemon are affected, while seemingly all heimdal KDC's running kadmind were. In any case the code flaw in both cases has a similar patch / fix.
Bad News for Mutants (Score:1)
Old news (Score:2, Informative)
Re:Old news (Score:3, Insightful)
Is this really pertinent? (Score:3, Insightful)
Re:Is this really pertinent? (Score:5, Funny)
Re:Is this really pertinent? (Score:1, Offtopic)
Re:Is this really pertinent? (Score:4, Insightful)
-- gid0ze
Then turn off security articles :P (Score:5, Insightful)
If we're going to have articles on what dangerous server rooms look like, we can have an article on how if you don't patch that KDC server fast, tens of thousands of user accounts might be compromised. Kerberos is at the HEART of many large multi-user distributed systems. (Universities, hospitals...) A critical flaw possibly compromising hundreds of thousands of accounts worldwide is a big story.
Yes. It's what everybody uses (Score:2)
By the way, this interacts with the Quantum Computing discussion threads, because if it's possible to factor big numbers, public-key crypto no longer works, so the fallback for authentication is to use symmetric-key systems like kerberos.
No worries... (Score:1)
Guess I was wrong... (Score:1, Funny)
Kerberos Authentication (Score:4, Funny)
Re:Kerberos Authentication (Score:2, Funny)
What would really be appreciated (Score:5, Insightful)
like, just say "if you type
A lot of the time it's kind of hard to remember which version exactly you have, and much UNIX software offers no quick, clear way to tell what version you have installed. Hell, i don't even know if i have kerberos. I know i've never consiously used kerberos. But for all i know my linux distribution installed kerberos as part of another package. Now i, and a bunch of other people, are going to be poking around manpages and wierd directories for awhile trying to figure out, uhh, do we have kerberos, what version/brand, do we need to disable or patch anything.. this is not the hardest thing in the world, but it isn't exactly easy when you consider it's 11:12 PM and at my college, we start drinking on thursday night. I'm not exactly in the mood to think logically at this exact moment.
So, a quick 'heads up, here's the quick way to tell if you're affected' on the part of the slashdotty people at the end of these story blurbs would be much appreciated
Re:What would really be appreciated (Score:2)
party on woo!
Re:What would really be appreciated (Score:3, Insightful)
Then you're not affected.
This is a bug in the Kerberos admin daemon, which only runs on KDCs, which are centralized Kerberos servers. Clients are not affected. Furthermore, it only affects KDCs that have enabled version 4 backwards-compatibility.
If you don't know what Kerberos is, you don't have to patch your system. Only people that run KDCs have to patch their systems. I've never seen Kerberos installed with less than a few thousand users, so you would probably know if you're the admin of a KDC.
Re:What would really be appreciated (Score:2)
Every article on a security flaw should include a quick test on how to determine whether or not you are affected.
If I had mod points right now, he would have gone up. I would probably even have experimented to see if I could mod the same comment more than once. He should be at "+6 insightful: Editors please note!"
Re:What would really be appreciated (Score:2)
If you're running an RPM based system, "rpm -qa | grep kerb" is a quick way to determine if you've installed Kerberos. This works for any other RPM you've installed.
Backwards Compatibility? (Score:3, Insightful)
(I'm not posting this in an attempt to prove I know anything, I just think a clearly worded reply might benefit a few folks, e.g. me)
nah (Score:5, Informative)
I mean, they exist only within the program that they effect. All that a buffer overflow is is that someone was writing a program, and they put in some place that they read a value from one place and put it in another-- say, they have a web server, and they recieve some data from the client requesting a web page. And let's say that when they accept this data, they're going to put it into a little memory space that can hold 2000 bytes. A buffer overflow would be what would happen if the web client sent more than 2000 bytes of data, maybe 3000 bytes, and the program stupidly attempted to fit all 3000 bytes into that 2000 byte space. What you get is a buffer overflow; quite literally, that 2000-byte buffer "overflows", spilling an extra 1000 bytes of data into memory. The problem is that those 1000 bytes of memory it overwrites could quite possibly contain very important things. So if you exploit a buffer overflow by accident, say by sending a server more information than it can handle, you'll probably get a crash. But if you know a bit about the way that the program with the buffer overflow bug works, you can do some kind of clever things-- for example, you could send 3000 bytes, but very carefully sculpt those last 1000 bytes so that the program keeps running, doesn't crash, but suddenly has a bunch of your information in its memory. Do this right (hulk smash stack! smash!), and you can
literally send a very small program into the memory of the server and trick the server into running this program.
Now, this is a programming error; you can't build a buffer overflow into a protocol. Why? Because it's just a programming error. In our example above, the programmer of the web server made the mistake of not taking steps to prevent a buffer overflow. And preventing a buffer overflow is *easy*; you just make sure that whenever you copy data from one place to another, that you never put into a single memory space more data than it can hold. Like, you're writing that web server, and you have a network socket through which the client is sending you a request? Use fgets(SOCKET, space, 2000); instead of gets(SOCKET, space); (i think that's the right syntax). fgets() is a special version of gets(), with the special condition that you can give it a number of bytes and say "if the data coming in from this filehandle is more than this number of bytes, i don't want you to give me the rest". So fgets() will just read in 2000 characters and then stop, preventing a buffer overflow. It's that simple, you just carefully pick the ways in which you copy memory. the problem is that C is hard and people are lazy and people keep doing things like using gets() and lazily coding their fscanf() statements.
Now, there is one sort-of-exception to my "you can't code a buffer overflow into a protocol" rule: AOL actually did! That is to say, at one point AOL was trying to figure out how to lock Jabber and MSN users out of using the OSCAR protocol to access AOL instant messenger. (Third party clients are supposed to use TOC instead.) So AOL looked at their program and realized, hey, we accidentally put this buffer overflow in this one place in our AIM client, and neither MSN or jabber have that overflow. So (and they may have undone this change since then, i don't know, it was a wierd month) they changed the OSCAR protocol to the point where you literally can't connect to AOL instant messenger without that buffer overflow there! Becuase the OSCAR server would buffer-overflow-attack the AIM client, and send it code where, if the overflow was successful, the AIM client would send back a specific packet. If the OSCAR server didn't get this packet, it would disconnect you. Creepy, huh? Now, this wasn't very unsafe, becuase the way that the client was set up the only way that the buffer overflow could be exploited was by data recieved from AOL's computers.. but, then, it was also pretty stupid, becuase the buffer overflow was still exploitable by someone doing a man-in-the-middle attack and impersonating AOL's servers!
But, uh, yeah, that story doesn't have anything to do with backward-compatibility. kerberos didn't have to have the buffer overflow to bebackward compatible, that just isn't the way protocols work. i am guessing the overflow cropped up in backward-compatibility code because one, backward-compatibility code is usually really, really nasty and hard to debug, and two, it's possible that the backward-compatibility code in v5 could have been largely copied out of v4, and the code with the buffer overflow copied along with it.
That answer your question any?
Yeah. You see? you see all this typing above?? this is the extents i will go to to find some distraction so that i don't actually have to do my homework. God, remind me never to go to grad school, i'd never get my thesis even started.
--super ugly ultraman
Re:nah (Score:4, Funny)
Re:nah (Score:1)
Make it with two levels of access; there should be memory that can be writen to by the programmer and memory that can hold executable instructions, and keep them shielded from each other at the OS level.
I'm not an OS designer; what complications would this carry? Would it protect from the current exploits?
Re:nah (Score:5, Informative)
This is theoretically a good idea - and in fact it has been done as a Linux patch, more than once. Google for "solar designer" linux non-executable stack. There are a couple of problems:
Some code needs to be able to write a stream of instructions that it will then jump to. This is called a "trampoline" and can accomplish tricks which are otherwise difficult to do within the confines of a compiled language. I think GCC emits trampolines for certain C++ constructs on certain architectures, but I seem to remember there was some noise made awhile back about migrating to other methods so as to work with non-exec stacks.
Just-in-time (JIT) compilers for languages such as LISP and Java have to be able to write executable code at runtime, though it's not really called a trampoline in that case.
It is possible to exploit a buffer overflow without actually executing code directly. Hard to explain, but the gist is that you overwrite bits of the stack which represent the function return address, so that the function "returns" to somewhere other than where it came from - say for example into the C library's system() function. Craft the rest of your overflow properly and you can dictate the arguments to said function - say system("/bin/sh").
I believe it has been demonstrated that any buffer overflow which can be exploited to execute code directly can also be exploited to execute code via the indirect method outlined above. At least on certain architectures. RTFG.
So, if Linus (for example) were to incorporate Solar Designer's non-exec stack patch into the Linux kernel, the exploit writers of the world would spend a week or so re-learning how to build buffer exploits to use nonexecutable means.
This is the main reason people oppose the non-executable stack patches. If widely used, we would in the long run be no better off than before. The added complexity in the Linux kernel would buy nothing. Naturally, those who have to battle kernel complexity generally oppose it. But - note that as long as only a few people use Solar's patch, they are better off, because the exploit writers do not focus on them. (Same reason there are more viruses for Windows than for MacOS 9, which had little significant virus resistance.)
Ahem. I also feel compelled to mention (since someone else will if I don't) that in combination with other techniques, such as relinking libraries with random load addresses on each machine, the non-exec stack patch may actually be effective. I am nowhere near enough of an expert to say for sure. (Jakub Jelinek's ELF prelinker sounds rather interesting in that context....) Also, architectures (like the HP PA-RISC) whose stacks grow upward instead of downward are probably resistant to most common buffer overflow techniques, but again I don't have the skillz to say whether such techniques could be adapted.
Re:nah (Score:2)
When you make a function call, the last thing that goes on the stack (think of the stack as scratch space for a running program) should be the address to return to after that function is done ... so you overwrite *that* address to execute additional instructions you've placed on the stack.
The fix is to design the CPU so it refuses to run code in an area designated as stack space, pretty much what you've said but most CPU's differentiate between code and data only (because code has different cacheing rules then data). I'm pretty sure sun/sparcs can keep track of stack space as well if you supply some weird option in the bios. I would imagine other cpus are capable of this as well.
Re:nah (Score:4, Informative)
Not to say the argument isn't entirely valid, but Microsoft uses this as an argument for Pallidium and "trusted" code. Be cafeful about asking for restrictions on how code can run on a user's computer.
Re:nah (Score:3, Insightful)
Re:nah (Score:2)
Modern CPUs do this. You can specify whether certain pages are executable or not, so you just set a couple of different bits in page table entries for pages allocated for stack to make the stack non-executable. The kernel will always know what pages are allocated for a program's stack because the kernel allocates the initial stack and sets the stack pointer, and the way a program's stack grows is by accessing an address lower than what is available, which generates a page fault, which in turn lets the kernel know that the program needs more stack space. Somewhere in the kernel there's some heuristic for determining whether or not a page fault is due to the stack growing. (eg, what happens if you just access memory right in between the stack and top of heap? Try it on your favorite Unix, then try incrementing that address until it no longer segfaults.)
The short of it is that modern CPUs do not require any additional hardware support to make the stack non-executable.
I'm pretty sure sun/sparcs can keep track of stack space as well if you supply some weird option in the bios
Sparcs don't have a BIOS. It's called Open Firmware, and it's completely different from a PC BIOS (for one thing, Open Firmware implements a real programming language in ROM).
Re:nah (Score:2)
Re:nah (Score:2, Informative)
Since a buffer overflow attack overwrites with data memory addresses filled with instructions, why not designing an operative system that isolates the executable memory from the data memory?
The x86 is what we call a Von Neumann (maybe not spelled that way) architecture machine, meaning memory is memory and you can put whatever you want there. A Harvard architecure machine separates program and data memory. There are tradeoffs and advantages to each architecture.
The operating system you suggest running on a Von Neumann machine would essentially emulate a Harvard machine on hardware not designed to do that. To avoid buffer overflows, just use a Harvard machine with an OS designed for it. But you lose the advantages of a Von Neumann machine, like self-modifying code, simpler executable formats, simpler memory management.
In simple terms, all your questions could be answered with "It's a hardware thing."
Re:nah (Score:2)
You just gave me an idea-- Secure Client Authentication Protocol. Will file for RFC status on April 1, 2003!
Good idea -- needs a better acronym though... (Score:2)
Critical Flaw?? (Score:4, Insightful)
So all I have to do is update the software and I'm good to go. Just like any other buffer overflow.
Actually I don't use Kerberos at all, so it really doesn't matter. But the title really caught my attention..
Re:Critical Flaw?? (Score:2)
When are we going to switch to languages that don't have buffer overflow problems? Solutions have been around for years. It stuns me that buffer overflow is still an avenue of attack.
Re:Critical Flaw?? (Score:2)
If the language you're using does not automatically check array indices, then you have to do it yourself. The Kerberos implementation flaw proves it. So you pay for bounds checking anyway, and chances are, the compiler constructed check will be faster than the one you wrote.
Furthermore, with the right language a compiler can omit most of the checks because it can easily prove that the value will always be in range.
The idea that bounds checking = slow is just so 60s.
Re:Critical Flaw?? (Score:2)
Now, you say, this can easily be done in the compiler. However, what if someone decides to write the bytecode themselves. This could allow a buffer overflow in a Java virtual machine, for example. So Java checks array bounds on every access, so that a rogue applet can't gain elevated privs. Plus for security, minus for efficiency.
Re:Critical Flaw?? (Score:2)
Re:Critical Flaw?? (Score:3, Insightful)
You seem to be thinking in C++
for I in Array_Variable'Range loop
-- do stuff with Array_Variable (I)
end loop;
No bounds check required, because the compiler knows that I is always in range.
Furthermore, the ability to restrict variable ranges removes a whole bunch of other bounds checks. You'd be surprised at how little is actually required.
It's also much harder to have buffer overflows with extra-long input; in general, an exception will be raised (in this case by the run time), which, if uncaught, terminates the process. No security risk.
Language design has come a long way since the 1970s. You'd be doing yourself a favour to see what else is out there, even if you never program in anything other than C.
Re:Critical Flaw?? (Score:2)
M@
is this for real (Score:5, Insightful)
Re:is this for real (Score:2)
Re:is this for real (Score:2)
Important considerations! (Score:3, Funny)
Is this just a warning of a potential hole.
Or has somebody actually made an exploit.
Does anybody know of a warez site from which I can get the security patch for free.
Re:Important considerations! (Score:2)
a first in the security world (Score:5, Funny)
actually, this is old news (of sorts) (Score:3, Informative)
In other words, this latest advisory is the *first* specific bug of this type found since the problem was first discovered (and numerous other bugs of this type have presumably been fixed by now).
I think it's safe to assume that it won't be the last, so if you really want to be secure, take the original advisory to heart and avoid krb4 compatibility code.
Re:a first in the security world (Score:2)
Krb5 was recently found to have a flaw in the xdr_array function, the last kerberos bug I know of before that was the kerberized telnet daemon -- same bug that was in standard telnetd, the 'ayt' sequence I think. Again, no telnet, no flaw.
Those are the only two flaws I can think of in krb5 in the past 3 years, but yes there were more in the krb4 implementation.
Nawww.... (Score:4, Funny)
---
How is everybody spent todays' slashdot meetup?
Re:Nawww.... (Score:2, Interesting)
Re:Nawww.... (Score:1)
Re:Nawww.... (Score:5, Informative)
http://public.support.unisys.com/aseries/docs/h
patch available (Score:5, Informative)
So.... don't run kadmind4? (Score:4, Informative)
So basically, all you have to do to avoid the vulnerability is just not run kadmind4, correct? I certainly can't speak for other KDC admins, but I haven't had much of a use for krb4 compatibility for a long time now - I disabled it at LEAST a year ago. Are there still many systems and/or applications that don't support Kerberos5? In any event, yay for me, my KDCs are unaffected!
Re:So.... don't run kadmind4? (Score:3, Insightful)
You may sleep easier tonight than some other people, and you may not be racing to log in and patch it like some other admins are, but come the morning you probably should be planning on patching it. But I'm sure that's already on your schedule.
Re:So.... don't run kadmind4? (Score:3, Insightful)
1-- all unusdes services are disabled
2-- Of course acive services are always patched.
NOTE-- we do not assume that backwards-compatible components to be necessarily patched unless active and maintained by IT.
3-- If we need a backwards compatible patch, we usually upgrade the entire package (testing first, naturally).
4: We keep a database of all vulnerabilities found about our software and how they were resolved. This enables us to query what vulnerabilities are found on inactive services and what computers could be affected.
Look-- the point is plan. There are many ways of doing things, but the point is to have a plan and be thinking about things. Security is more a way of live than a set of precautions.
Oh No... (Score:2)
(Yes, I'm aware that they probably have lots of undergrads helping. Still, the concept is quite large.)
Re:Oh No... (Score:2, Informative)
but even if there was a security patch that needed to be applied to all public workstations, there is an automatic update deployment procedure... so no, sysadmins wouldn't ever have to go from computer to computer, replacing software...
If only... (Score:4, Funny)
Re:If only... (Score:2)
(Yah, I know it was legal. So was bastardizing the protocol. But it was still quite impolite.)
Security is Pointless (Score:4, Funny)
Me, I spend the money my boss gives me for security on beer and better video cards for my office mates that like unreal tournament.
Oh, I should also mention that in addition to not providing any type of network secuity you must also not supply any type of network monitoring. Can you imagine...you're two frags from godlike and some system monitor (that you don't understand anyway) starts paging your beeper like a crazy x-girlfriend.
You might just lose concentration.
Why this is big.... (Score:5, Informative)
I wonder how much you could do before you got noticed, but even if you managed to copy over the encrypted password files, I'm sure you could find some that fell to cracking software.
The ramifications of a flaw in a kerberos implementation is a great deal more important than a flaw in outlook. (The importance of this though means this flaw is probably going to be patched faster than a speeding bullet!)
Re:Why this is big.... (Score:2, Insightful)
Just copy the Kerberos secrets database and you can grant yourself tickets to impersonate anyone you want. I am not a Kerberos admin, but I believe in general changing said secret is far from trivial, because every single service provider on the network must be updated.
(This is by design - the whole K architecture is designed around an ultimately trusted KDC which is known to the services via some sort of shared secret.)
kadmin4 has a history of buffer & security bug (Score:5, Informative)
Unless you need backward compatibility with Kerberos v4 (most people should use v5 nowadays), disable it.
Lose kadmin4 and disable starting krb524d in /etc/init.d/
C programming (Score:4, Insightful)
Re:C programming (Score:2)
The point is that if a programmer wants to be sloppy and stupid, s/he'll find a way to be sloppy and stupid, no matter what strange constraints the language imposes.
Re:C programming (Score:3, Informative)
Ada*, Python, Ruby, Pascal, Clean (well, that's windows only), Eiffel, OCaML, APL, PL/1**.
Some of these languages are relatively slow. Ada is as fast as C, and as powerful as C++, but a pain to learn. Eiffel differs greatly between implementations, and is *extremely* dependant on how you specify compile time options. If you have all possible checks on, then it is slow. If you turn them off, then it is fast. And you can fine-tune it so that some routines have check on and others don't. Python and Ruby are "reasonably fast", but certainly not speedy. I don't know Clean or OCaML, but for some things OCaML is quite fast. APL is... well, it's APL. The original write-only language. I never learned it well, so I can't speak to it's advantages and disadvantages, but at one point CDC was considering choosing it as the language that it's STAR computer would be designed for. I think that meant that a macro processor would be able to translate it into the binary, but I'm not sure. So it must have some capabilities as a systems language.
* In Ada you can have buffer overflows, but it takes extra work. No automatic garbage collection however.
** In PL/1 it depends on the kind of variables allocated. Your programming style determines whether or not buffer overflows are prohibited. But this doesn't mean the kind of constant attention that C requires, as you can control it at variable declaration time.
Re:C programming (Score:2)
C++ has it; it's called, strangely enough, <string>.
Re:C programming (Score:2)
They exist, but are not standardized. Until something like this becomes part of ANSI C I doubt many people will use it or even be aware of its existence.
OTOH, DJB's stuff is notorious for having licesing problems. That in itself may cause poeple to be wary of this particular implementation.
Somewhat offtopic, that's a pretty sweet library. Somebody did a GPL re-implementation (why oh why couldn't they have made it LGPL?)
How do they find these? (Score:2, Interesting)
Re:M$FT too? (Score:2, Funny)
Re:M$FT too? (Score:2, Interesting)
-dk
Re:M$FT too? (Score:2, Informative)
Note that this only affects you if you have enabled Kerberos IV backward compatibility support.
Michael
Re:Question (Score:3, Informative)
...and when you stop laughing... (Score:3, Informative)
Re:Question (Score:3)
Re:Question (Score:5, Funny)
Kerberos makes it really difficult to do any work at MIT. It's a software product designed by faculty to slow up research projects by students.
The reasons for this are twofold: ensure longer paths to tenure, and keep smart students from publishing too quickly and making their profs look bad.
Re:Question (Score:5, Informative)
That being said, here's kerberos in a nutshell. You log on to the network, and authenticate with the main kerberos server. This server grants you a "ticket", which you just pass to the machines you want access to. After so long, your tickets expire and you'll need to re-authenticate. (It would be bad if you left your desk for work, and evil joe cracker stole your ticket during the night and read your email and so forth). There's really a lot more to kerberos then that, but the basic idea is that you authenticate to one machine, then use that machine to authenticate to any other machine on the network. It's a rather nice way of doing things, but it is pretty much overkill for anything less than a network of at least 100 users.
Re:Question (Score:3, Informative)
One really nice part of Kerberos is that your password never used. When you authenticate, the authentication server encrypts your ticket with your password as the key. So, your password NEVER passes over the network. If you put in the right password, then it's decrypted just fine, and you have your ID with you.
The other unique part of Kerberos is that the servers must also prove their identity. When you ask the mail server for your mail, it asks the auth. server if you are who you say you are, and the auth. server will verify that you're a user on the system. Only a mail server with it's own ticket to the kerberos auth server can do this. Therefore, the mail server doesn't have to touch your password, and you can be certain that the mail server is safe to use.
The idea is that all transmission of your personal data is minimized, and restricted to trusted sources only.
Re:Question (Score:2)
Re:Question (Score:2, Funny)
Re:Question (Score:5, Funny)
Kerberos is a three-headed dog that guards the gates of hell. A flaw in Kerberos is a serious situation because if it fails, all hell could break loose.
Re:Question (Score:2)
Do you have kadmind4, though? (Score:2)
I have access to several boxes, all with Kerberos 5 on them, but none of them have kadmind4 (not in any bin directories or in inetd, at least).
If you do have kadmind4, go to CIAC [ciac.org].
Specifically, go here [ciac.org]