Topic: A way for converting to different EncModule's (read before you disregard) (Read 42043 times)

djGrrr · « **on:** January 03, 2007, 03:20:40 PM »

I've been thinking this ever since the enc modules first showed up in svn.

Since the old md5 implementation is broken, it would be nice to be able to convert to the newer md5 module (or even sha1).

NOW, obviously you can't just convert them, so what i was thinking is, a new directive in the conf file, something like EncConvFrom where you would specify the hash type you want to convert from (for example, enc_old) and in EncModule you would specify the new module (for example, enc_md5)

then, when the users identified, it would first check the password against the EncModule if it is incorrect, then check with the EncConvFrom module, and if correct, regenerate the hash with EncModule and update it in the database.

While this won't likely get many channel passwords converted, with would most definetly get all nickname password hashes converted within the nick expire time.

Although this might seem a little messy using 2 types of password hashes at once, it would definetly be a big help for security with people who have been using the old md5 method for a long time.

djGrrr · « **Reply #1 on:** June 12, 2007, 05:37:44 PM »

Is there any chance of this happening, I honestly think this is an extremely vital feature for 1.8, i really don't want to have to keep using enc_old

Pieter Bootsma · « **Reply #2 on:** June 15, 2007, 10:14:10 AM »

It's not trivial at all. As far as i'm aware the database does not store what kind of hash is used to encrypt the password with (just that it is encrypted), so you can't really know what people have the old hash and what people have the new hash. Detecting this automatically also won't work, since it is very likely that the new and old md5 modules have hashes that they both accept.

SNU · « **Reply #3 on:** June 15, 2007, 07:33:15 PM »

hmm.
But what about creating a 2nd database-file that could simply be renamed whan the time is right?
I mean: the "convertmodule" does following:
The oper loads the module and the module creates a nick2.db (and a chan2.db). And on an user identifying the module reads/copies always from nick.db to nick2.db but writes the password as like registering with the new encryption-method into nick2.db... and maybe after a month of running (also old nicks might be expired) you simply unload the module and rename the nick2.db to nick.db and restart anope with the setting of the new encryption method. so nobody really will take notice on it. maybe on small/medium networks possible. I dunno how it works on large networks...

Jobe · « **Reply #4 on:** June 15, 2007, 08:19:25 PM »

An alternative to that to save space, simply write to a second DB which nicks and channels passwords have been converted.

xander · « **Reply #5 on:** June 21, 2007, 03:57:02 PM »

i think djGrrr meant something like this (correct me if i'm wrong):

Code: [Select]


user identifies {
	current encryption = broken md5
	new encryption = sha1 (or whatever)
	if (sha1(password given by user) == password currently in the database) {
		user has correctly identified
	}
	else if (broken_md5(password given by user) == password currently in the database) {
		user has correctly identified
		update password in database to be sha1(password given by user)
	}
	else {
		password incorrect
	}
}

i agree that this would be a great feature. my predecessor on the network i manage set up anope with no encryption. i have had an instance of a user downloading the webwizforum database (i wasn't the one who set it up, don't blame me..) and gaining access to plain-text passwords, which wasn't a fun experience, but i really don't want to wipe my ns/cs databases to get encrypted passwords.

Jan Milants · « **Reply #6 on:** June 21, 2007, 04:42:06 PM »

well to get encrypted passwords you can just specify the encryption you want to use and all passwords will be encrypted when anope starts (note that this cannot be undone)

as for converting the passwords, it sounds like an interesting idea and may not even be that hard, but atm i don't even have time to take a look at how hard it would be (doesn't mean i ll have time to actually write it...) since midsummer (tomorrow) s like the biggest party of the year around here so

[Edited on 21-6-2007 by Viper]

ngage · « **Reply #7 on:** November 18, 2007, 06:25:05 PM »

bump...

I'd be really interested in a module like this. It would save us losing hundreds of user records during the conversion.

Jan Milants · « **Reply #8 on:** November 18, 2007, 09:05:15 PM »

i wrote one a while ago but i still got several compiler warning which also turned out to be present in the anope core. the functionality worked though, at least as far as i tested it...
I decided to postpone releasing it untill anope 1.7.20 is released.

fez · « **Reply #9 on:** March 12, 2008, 06:54:17 AM »

Yes it is a real bitch.

Luckily, I have a solution.

http://wrongway.org/work/anope-1.7.21-fez.tar.gz

I have modified it to enable a new directive, "OldEncModule".
Whenever a password matches the hash specified by OldEncModule, it is automatically rehashed (only in /ns identify and /cs identify, not /ns ghost or /ns drop or /ns recover).
A log notice is then sent out.

Developers of Anope, please consider doing a diff on 1.7.21 official and including the patch in future versions.

fez · « **Reply #10 on:** March 12, 2008, 06:58:00 AM »

also, developers, you'll probably want to make it more elegant. I freely admit that my modification was a 'get'er'done' method, not a 'make'it'pretty' method.

Maybe you should allow a list of "old" encryption modules, so you aren't just limited to one.

Jan Milants · « **Reply #11 on:** March 12, 2008, 08:49:30 PM »

Anope 1.7 is under a feature freeze untill 1.8 stable is released.
This can be easily handled by a module anyways... reminds self to press "publish module" someday...

fez · « **Reply #12 on:** March 12, 2008, 10:33:04 PM »

said module would have to either replace src/encrypt.c or src/core/ns_identify and src/core/cs_identify, as well as of course adding the encryption capabilities (e.g., not a module, unless by module you mean replacement for *identify).

The current architecture is pretty strict in only allowing and using a single encryption module.

Jan Milants · « **Reply #13 on:** March 12, 2008, 10:44:47 PM »

Correct... it requires the enc part to be reimplemented, but since it is possible in a module, it s unlikely it will be added.. maybe in 1.9.. up to the devs

Jobe · « **Reply #14 on:** March 12, 2008, 11:00:57 PM »

There is nothing to stop you making your own custom enc_* module, in which you can do all the hash changing code yourself. And that's without modifying the source too.

Same logic, and can work on ANY password validation too.

Just check each hash type individually, and then use a simple config param to specify the new hash type.

Also out of curiosity, do your DB's after conversion, still work in un-modified Anope?

[Edited on 12-3-2008 by Jobe1986]

katsklaw · « **Reply #15 on:** March 12, 2008, 11:09:28 PM »

Quote

Originally posted by fez
said module would have to either replace src/encrypt.c or src/core/ns_identify and src/core/cs_identify, as well as of course adding the encryption capabilities (e.g., not a module, unless by module you mean replacement for *identify).

The current architecture is pretty strict in only allowing and using a single encryption module.

Modules can hook any known command already. Modules are processed before the core code is so if you re-write a feature, like say ns identify, your 3rd party module will trigger before the core module will. So if you just want your module to handle all behavior it can without altering the core coding.

Jan Milants · « **Reply #16 on:** March 12, 2008, 11:18:59 PM »

Consider this a technology preview

http://vips.hopto.org/~viper/enc_switchover.c

It s mainly still missing the support for chanserv identify and migrating from enc_none since this used to be handled by anope, but no more, i decided to add it too...

DONT USE IT!!!
it hasn't been properly tested

fez · « **Reply #17 on:** March 13, 2008, 12:07:42 AM »

katsklaw: point taken. One could override ns/cs identify to acheive this functionality... it would be a bit more work but that's OK.

Jobe1986: Not really. You could write a module that accepts any of numerous password hashes without modifying the code, however, in order to UPDATE a password hash for a user (e.g., update the database with the new hash), the module must have some knowledge of who the user is (e.g., the encryption module would have to be passed a User* pointer when calling check_password_hash). Because the current system has no way of telling the encryption module who a user is when it is asked to encrypt/decrypt a password, the encryption module would have no way of converting the hash stored in the user database from an old hash to a new hash.

Also, writing a module that overrides IDENTIFIES to accept multiple encryption schemas may require in fact writing several modules, one identify override module for each encryption method you wish to convert. Meh.

katsklaw · « **Reply #18 on:** March 13, 2008, 12:19:22 AM »

No one said it would be easy, in fact GeniusDex admitted that it isn't a trivial task, but if you want that functionality in Anope before sometime in the future after all the top priority stuff is done, which can take months or a 1+ years, you'll have to write it your self.

As stated Anope is and has been under a feature freeze while we prepare for Anope 1.8 to roll out and it is far too late in the game to drop in any new feature, simple or complex.

fez · « **Reply #19 on:** March 13, 2008, 12:56:23 AM »

I have attached a diff patch, FYI. I ran
diff -ur anope-1.7.21-old anope-1.7.21 > anope-oldenc.txt

Jan Milants · « **Reply #20 on:** March 16, 2008, 04:13:17 PM »

no reason to put something that s rarely gonna be used in the core if it might as well be a module... http://modules.anope.org/viewmod.php?id=110

CuttingEdge · « **Reply #21 on:** March 30, 2009, 06:31:45 PM »

Whats the remote chance that someone can convert this module to 1.8.0 ?

I'd be very grateful if someone could help. I'm using enc_old on my network, and I'd like to switch to enc_none, as I'd like to integrate some sort of web frontend to services on my site. If there is any other way that anyone can think of to achieve this, please let me know.

Thanks in advance!

Jan Milants · « **Reply #22 on:** March 30, 2009, 08:13:05 PM »

mostly done already.. just not tested/published...

CuttingEdge · « **Reply #23 on:** March 31, 2009, 07:01:32 PM »

Great! Thanks for the update. Let me know if you need help with testing.

zEkE · « **Reply #24 on:** April 01, 2009, 06:29:54 PM »

JFYI, I used the enc_switchover under 1.7....21? I think? to switch from either enc_md5 or enc_old to enc_none. It seemed to work seamlessly, and the only problems I've noticed are the one or two user-accounts that were unused, and those can be fixed with a setpass if/when necessary.

News:

Author Topic: A way for converting to different EncModule's (read before you disregard) (Read 42043 times)

xander

ngage

katsklaw

katsklaw

CuttingEdge

CuttingEdge