Login
User Name:

Password:



Register

Forgot your password?
Changes list / Addchange
Author: Khonsu
Submitted by: Khonsu
6Dragons mp3 sound pack
Author: Vladaar
Submitted by: Vladaar
AFKMud 2.2.3
Author: AFKMud Team
Submitted by: Samson
SWFOTEFUSS 1.5
Author: Various
Submitted by: Samson
SWRFUSS 1.4
Author: Various
Submitted by: Samson
Users Online
AhrefsBot, Google

Members: 0
Guests: 26
Stats
Files
Topics
Posts
Members
Newest Member
488
3,788
19,631
595
Khonsu

Today's Birthdays
There are no member birthdays today.
» SmaugMuds » General » General Discussions » Changeover to SHA-256 encrypt...
Forum Rules | Mark all | Recent Posts

Changeover to SHA-256 encryption
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2 next >>
Post is unread #1 Jan 14, 2006 9:56 pm   Last edited Apr 24, 2019 2:40 am by Samson
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002

 
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.

Post is unread #2 Jan 15, 2006 2:31 pm   
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002

 
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.

Post is unread #3 Mar 15, 2006 10:53 pm   
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts413
JoinedMar 7, 2005

 
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. :cool:

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

Post is unread #4 Mar 15, 2006 11:00 pm   
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

 
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.

Post is unread #5 Mar 15, 2006 11:17 pm   
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts413
JoinedMar 7, 2005

 
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. :stare:

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. :wink:

Post is unread #6 Apr 23, 2006 10:52 am   
Go to the top of the page
Go to the bottom of the page

Noplex
Apprentice
GroupMembers
Posts62
JoinedAug 30, 2005

 
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.

Post is unread #7 Apr 25, 2006 9:38 am   
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002

 
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.

Post is unread #8 Nov 4, 2006 2:58 pm   
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

 
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.

Post is unread #9 Nov 4, 2006 5:50 pm   
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

 
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.

Post is unread #10 Nov 4, 2006 7:13 pm   
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

 
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.

Post is unread #11 Nov 4, 2006 7:47 pm   
Go to the top of the page
Go to the bottom of the page

Dragona
Fledgling
GroupMembers
Posts26
JoinedMay 25, 2006

 
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*

Post is unread #12 Nov 4, 2006 7:58 pm   
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

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

Post is unread #13 Nov 4, 2006 10:12 pm   
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002

 
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.

Post is unread #14 Nov 4, 2006 11:18 pm   
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

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

Post is unread #15 Nov 6, 2006 6:24 pm   
Go to the top of the page
Go to the bottom of the page

kiasyn
Magician
GroupMembers
Posts121
JoinedJun 30, 2006

 
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.

Post is unread #16 Nov 7, 2006 3:04 am   
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

 
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.. :rolleyes:

Post is unread #17 Nov 8, 2006 6:17 am   
Go to the top of the page
Go to the bottom of the page

kiasyn
Magician
GroupMembers
Posts121
JoinedJun 30, 2006

 
it can be optional...

Post is unread #18 Jan 4, 2008 3:07 pm   
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

 
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.

Post is unread #19 Jan 4, 2008 3:14 pm   
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

 
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. :smile:

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.

Post is unread #20 Jan 4, 2008 9:35 pm   
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

 
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. :smile:


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.

Pages:<< prev 1, 2 next >>