Anope IRC Services
Anope Development => Feature Requests => Topic started by: 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.
-
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
-
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.
-
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...
-
An alternative to that to save space, simply write to a second DB which nicks and channels passwords have been converted.
-
i think djGrrr meant something like this (correct me if i'm wrong):
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.
-
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 (http://forum.anope.org/images/smilies-new/kwijl.gif)
[Edited on 21-6-2007 by Viper]
-
bump...
I'd be really interested in a module like this. It would save us losing hundreds of user records during the conversion.
-
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.
-
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.
-
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.
-
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...
-
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.
-
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
-
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]
-
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.
-
Consider this a technology preview :P
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 :)
-
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.
-
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.
-
I have attached a diff patch, FYI. I ran
diff -ur anope-1.7.21-old anope-1.7.21 > anope-oldenc.txt
-
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 :)
-
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!
-
mostly done already.. just not tested/published...
-
Great! Thanks for the update. Let me know if you need help with testing. :)
-
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.
-
Any news regarding the 1.8.0 version?
-
I've heard nothing about it, but I can tell you that for 1.9.x, we have a pending patch from DukePyrolator that'll be part of the core. It's only pending because I'm waiting for more devs other than myself to look over the patch before committing it.
-
Hadn't really had anyone ask about the functionality in 1.8 but if there's enough interested parties it might be doable given Adam has just completed an atheme > anope converter for 1.8 with encryption etc.
-
I present my thesis on monday.. after that I hope to have a bit more time... :)
-
Be good to see more of you again Jan, good luck :)
-
ok.. I ve been looking at how far an update was and it seems it was almost complete before I had to put it in the freezer.. the only thing I need to finish is a new feature which allows you to keep track of which passwords have been converted and which haven't..
once finished I will need people to test it though as I am not at home and I only have my laptop here.. so no test systems or VMs to play around in...
-
I finished 1.1 which should work with anope 1.8, however since I'm not at home in Belgium I can't do all the testing myself..
So I need some volunteers to try it out on a testnet or so...
-
I don't have a testnet but my net is using enc_none so It wouldn't be harmful to test it switching to end_md5 I don't mind testing i keep backups for weeks so no worries there
-
Any update on this? I have a 1.8 test net with some 3000 registered users which this module can be tested on. Fed up of enc_old and really want it converted.
Phil
-
Well I found v1.1 at http://81.11.186.179:6662/~viper/enc_switchover.c - Google is my friend. I loaded it onto the test net and had a few people log out and in. Their hashes updated correctly in nick.db - so winhex tells me, anyway. We did some php -r 'echo sha1("pass");' outputs to compare and it appears to be hashing into sha1 correctly.
After restarting services without the module the users who identified with it loaded can identify correctly under the new encmodule.
Phil
-
Quick update to this. We've tested it further and it works fine for converting passwords. However, if a user with an unconverted password tries to do something to their nick, it fails - e.g. NS GHOST, NS GROUP, etc.
Not a massive issue on our net (700odd users) but I can see it causing issues on larger nets and bombarding support with people complaining they can't group, ghost, etc.
Phil
-
I will look into hooking the module to a bit more commands to avoid these issues if possible..
and i thought i had already published 1.1 on the modules site, but apparently that s not the case.. will make the changes and publish it.
-
I will look into hooking the module to a bit more commands to avoid these issues if possible..
and i thought i had already published 1.1 on the modules site, but apparently that s not the case.. will make the changes and publish it.
Any updates on this? 1.0 is still on the modules site.
-
Yea, is there any update to this? I remember asking a *long* time ago and nice to see it was actually worked on.
-
I originally planned to add conversion for the broken windows sha1 to the corrrect *nix sha1, but don't have enough time atm to do proper testing on that...
but yes I do have a (supposedly) working copy on my HD, but since my employer dumped me in India I lack the resource to properly test anything..
I am not sure about posting a module that hasn't been properly tested on the modules site.. If there are any takers, that are willing to try 1.2, i ve attached it to this post.. if someone can report to me whether it works I ll add it to the modules site..