For those of you currently using MD5 encryption in your FUSS packages, the SHA-256 encryption code here: https://smaugmuds.afkmods.com/files/sha-256-password-support-2/ will perform the update and allow your existing MD5 users to log on and have the passwords converted over.

The FUSS packages will only contain the SHA-256 encryption as those downloads are intended for first time installs and there would be little point in having MD5 conversion there.

One caveat to be aware of:

In the DevC++ environment the endian.h file does not exist and this causes the results of the encryption to break. I don't know how to fix that problem right now but if anyone knows another way to access the information needed that would be cool.

Had anyone else heard that SHA-1 (160 bit hash) had been broken as of February of last year? I hadn't even been aware of that, sort of just came up on it at random while searching for some information on hash table lookup schemes. Not quite related to what I was looking for, but interesting none the less.

By the way, was any solution for that endian.h problem in DevC++ ever found by anyone?

Check the page on Wikipedia.

Attacks have been found for both SHA-0 and SHA-1. No attacks have yet been reported on the SHA-2 variants, but since they are similar to SHA-1, researchers are worried, and are developing candidates for a new, better hashing standard.

Zeno said:

Check the page on Wikipedia.

Attacks have been found for both SHA-0 and SHA-1. No attacks have yet been reported on the SHA-2 variants, but since they are similar to SHA-1, researchers are worried, and are developing candidates for a new, better hashing standard.

How odd. That was the place where I had found the first blurb about it too.

Of course I wasn't trying to say anything was wrong with using SHA-256. It'll be a cold day in a warm place before anyone successfully hacks a MUD using SHA-256 by trying to produce a collision for the imp's password.

Well if you have access to get the SHA-2 hash for the Implementor's password then you have access to create your own character, erase the password, or change the password (replacing the hash). It's really a moot point. The original intent was to keep people from being able to see plaintext passwords of their players (to protect the player). Your passwords are sent plaintext through telnet anyway.

Pretty much, yes. The SHA-256 is meant to stop prying eyes from getting ahold of passwords. Just because you're able to read a file you shouldn't be viewing doesn't mean you can also edit the file. The standard crypt() method was replaced for portability reasons. MD5 was replaced because it's more or less no good now. If someone wants into SHA-256 badly enough, they will eventually break it, but chances are by the time that happens there will be a new generation of mudders who will need to deal with it.

Anyone that would be prying into passwords would just turn off the encryption of the password. Next time the user logs in, the admin would be able to see his password. I'm not really concerned for password safety as I am for shell safety. Most MUD owners would not care to do anything. But some people with access might. Its always a good idea to change your passwords and don't use them repeatedly. I always make new passwords for most things. Including these forums.

Unfortunately, Kigen, the simple reality is that you're then using a much better practice than most people ever do. Personally I have a large list of different passwords that I use for different things, but it's certainly not a unique password for each unique thing that requires a password, I'd need a database solely for maintaining all my passwords. Instead I find myself using one of three passwords for forums, one of five other passwords for muds, one of about a dozen passwords for BBSes, one of 6 passwords for email, etc.. so I have quite a few passwords that I have to keep track of, but not quite as close to a limitless number of them. Frankly, I'm probably one of the minority who even go to that measure. For all too many folks the password they use for every mud, forum, email, web site, etc is the same one that they use on their ATM card's pin and so forth as well unless they encounter a site that requires them to use a bigger password, so securing their password on the off-chance that your mud/site will be the one that gets hacked is a good idea to ensure that it's not your fault that someone discovered their password to everything even if they shouldn't have had just one to begin with. On the other hand, I do agree that making sure that your shell access is equally or even more secure than their passwords is just as important too.

Well, I have encountered a situation were a immortal's password was compromised because a MUD owner let someone have the guys password or the person who did the hacking was the MUD owner, either way they went around saying "Oooh, I've hacked this account." then did "shutdown mud now". And he used the same password for both muds. I of course have a log of it all since a long time ago we had problems with cheating, so I made a Immortal Logger as I like to call it. It simply logs all commands executed with an account above level 50 as specified by get_trust. So I reported them and banned them off the mud. I had the immortal change his password and everything went fine after that.

That would have been a bad mud owner then, cause he should not have given out passwords.

Good for you, but just cause you have had a problem with passwords, does not mean everyone does or will. *shrug*

I'm not say people will. I'm just saying be cautions. Even the highest encryption can fail because of the human.

Well of course the best encryption is useless if you con someone out of their password. That's not what this was meant to protect. You can't protect people from their own stupidity. But you can take precautions against random snoopers and dedicated hackers on the same system by not just leaving a plain text password lying about that someone might have used on 20 different sites.

I do not doubt the reasons behind putting the encryption there. I'm just saying we should warn people to be careful.

Perhaps its time for a new protocol, where the client can enter an encrypted password and the MUD use that, the true password never going into the mud.

Um, yeah, Kia, let's rewrite every client and mud out there to use a new protocol that's more secure.. of course the encrypted version of the password still has to be stored where the mud can verify it and it still doesn't prevent someone from just giving it out..

it can be optional...

Actually, they have one. It's called ssh. Unfortunately, very few muds support using it for connections (there's some LPC code for doing so, I believe). If you supported the full ssh 2 protocol, you could even avoid passwords entirely and do key exchange to validate logins.

Of course, the downside is that folks who like using custom clients would no longer be able to do so unless the author of said client added ssh as a connection method.

Quixadhal said:

If you supported the full ssh 2 protocol, you could even avoid passwords entirely and do key exchange to validate logins.

That's not really solving the problem; instead of having passwords, you have a key. And then you have to have your key with you when you want to connect to the MUD. I certainly couldn't remember my keys.

Quixadhal said:

Of course, the downside is that folks who like using custom clients would no longer be able to do so unless the author of said client added ssh as a connection method.

The host could provide a connection tunnel, although that requires extra work for everyone.

DavidHaley said:

That's not really solving the problem; instead of having passwords, you have a key. And then you have to have your key with you when you want to connect to the MUD. I certainly couldn't remember my keys.

It solves the problem only in that a public/private key pair is (normally) unique to an individual. If the mud generates a key pair, and when you create an account, you upload (or otherwise exchange) the public side if your keypair, it becomes associated with that account. So the only way someone can log in as you is to have both your public and private keys. Unlike a password, these aren't things that can be tossed about unless you have a photographic memory.

Of course it can be sabotaged by the user, just like I can give you the physical keys to my house, or a DNA sample to use... but most passwords are hacked because the owner told their friend, or they used their girlfriend's name, or (in the case of my old University) it gets reset by an admin to the day of the week and they never change it.

DavidHaley said:

The host could provide a connection tunnel, although that requires extra work for everyone.

I suppose, although it would still require the end user to run their client inside another client (which would do the authentication and ssh protocol layer). Not something I'd expect to see often.