Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[stealth62]

last night i changed the encryption from md5 to sha1... after that none of the nicks passwords worked.
when they re registered there nicks, logged out, then back in... it still didn't work.

this morning i reinstalled the services because i figured that the nickerv database was probably screwed,
the same problem still exists.


thx,
stealth

[Jan Milants]

is your OS 64bit?
the sha1 implementation in version .21 doesn't properly function yet on 64bit systems. this was fixed in svn, but it s waiting for a new release..

and you can't simply change encryption from md5 to sha1... when using md5 anope makes md5 hashes of the passwords then when you change that anope  is suddenly told that it s all sha1 and of course the md5 and sha1 hash of a password won't match... would only work for newly regged nicks.
with clean db's it should work though... well maybe not on 64bit..

[spaceship9]

the services were not simply reinstalled
The entire directory was removed (After everything being properly shutdown) and a new install from scratch was setup.

The Services are running in a SliceHost VPS, which are all supposedly x64

[stealth62]

yea hes right, im running debian 4.0 etch... its 64 bit....are you telling me the only one that would work is md5?

[Jobe]

On the 64 bit arch, it's believed the MD5 encoding module works properly. However, in all honesty you're better off using enc_none anyway. If you're worried about a malicious user getting hold of the DB and using the passwords, then if they were able to get the db in the first place, you will have far more to worry about then nick/channel passwords being compromised.

[Jan Milants]

enc_none is imho just asking for trouble... usually the shell isn't the only place where db's are stored.. backups for example.

and yes on 64bit md5 and the old md5 implmentation (no reason to use that one though) are the only ones that will work for certain atm.
your other option is going with an svn version of anope.. there the 64bit issue should be fixed.

as for

the services were not simply reinstalled
The entire directory was removed (After everything being properly shutdown) and a new install from scratch was setup.

if you keep the same databases that makes no difference, you cannot switch encryption types on databases in anope...

i did write a module that does gradually migrate databases from one type to another, but it s still under development.. though should already work.. just not exactly foolproof yet.

[katsklaw]

enc_none is imho just asking for trouble... usually the shell isn't the only place where db's are stored.. backups for example.

Those that have back-up access almost always have direct access to the originals so the backups thing is rather moot.

Jobe is correct, if someone can get your db's then they can get to far more damaging things than IRC passwords. Even if the passwords are hashed, any malicious person that can su, hack or otherwise gain access either authorized or not can still wreak total havoc. One example is copy your db's to their shell, start their copy of Anope from it .. using your enc_switcher module to reset all, most or even some of the passwords. Shut down your services, replace your db's with theirs and start your services again .. all done in the middle of the night. Give themselves uber access on YOUR network or anything else they can think of out of sheer bordom .. so getting plain text passwords is trivial compared to the other stuff that can be done.

Additionally if the malicious user happens to have root access on the shell server, it doesn't matter if passwords are hashed or not. Some of the Top 10 networks have plain text passwords so they can be retrieved. If they can survive for 15+ years with tens or even hundreds of thousands of users without having major issues with password theft other than users compromising their password themselves, why can't the other 99.9% of the IRC population?

It is completely possible to over accessorize something, and it's been happening to IRC since the mid 90's ... I can probably write out a list of hundreds of commands and features that aren't really needed or were written to "simplify" something by someone that didn't truely know how to use the basic IRC cmd set to start with.

</rant>

[Jan Milants]

I actually meant that backups often end up in much less secure places then the running db's.. like users' own pc's or so.. so like only read access to the db's not the ability to modify the db's anope uses.

And of course if any1 ever gets full access to the shell or so, encryption is of fairly little use, but my main issue with unencrypted databases is that imho no1, not even network admins, should ever need to know users' passwords. there is not a single valid reason for any admin to be able to recover a users' pass... the ability to reset them should suffice.
Should anyone ever manage to get read access or get a hold of a backup copy, encrypted db's pose less of an issue.

As for the large networks having plain text passwords... several probably do, and quakenet certainly does.
It s the best example, a year or 2 ago some1 gained read access to their databases.. result... a lot of people with an account on quakenet were told to change their passwords as they may have been compromised.
And or course it still survives, but for people who use the same pass on many nets (like me) it was a pain in the ass and definitely not a good thing for qnet s image..

[Jobe]

If you use the same pass everywhere or on a number of places you're just asking for trouble anyway.