View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001681 | unreal | documentation | public | 2004-03-27 19:00 | 2004-03-28 11:45 |
| Reporter | JasonTik | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Summary | 0001681: A suggestion for modification of the Eyes SNOMASK reporting of mkpasswd by non opers | ||||
| Description | when +e is notified on non-oper mkpasswd tell us the hashed part and the auth method | ||||
| 3rd party modules | |||||
|
|
why? |
|
|
Indeed, why? The only possibly reason I can think of is so you can then go and attempt to hack whatever the person is doing... And that's certainly not something we're going to add. |
|
|
sha1 and md5 are secure hashes so hacking would hardly be a concern My reason is to make it easier on new opers, they just have to do /mkpasswd sha1 theirpass, and I can do the rest |
|
|
If you're "new opers" are too stupid to "/msg yournick <the output from /mkpasswd here>" then perhaps they are too stupid to be opers in the first place. I don't see how requiring someone to send a private message is so difficult... |
|
|
They arent to stupid to do that, its just for convenience, and mkpasswords's output contains the plaintext so your simple /msg Jason output of /mkpasswd isnt entirely correct. Although i see your point, I simply thought that this would be more conveniant nm |
|
|
Well the thing is, people might be using /mkpasswd for more than just to give you oper passwords. Nothing really stops regular users from using it for their own purposes. |
|
|
Maybe this is all the more reason for an snotice? MKPASSWD, like anything else, has the potential to flood/crash the server. Especially if someone finds a MKPASSWD input that enters buggy code. If an snotice was sent, opers could find and g-line the guy that crashed the server. |
|
|
umm, ok, so should we also display all the user's privmsg's on the off chance that some special character string is going to cause a crash? |
|
|
On a sidenote, password hashes are not THAT secure that you should show them to everyone... I can crack an alpha (a-z 1-8 chars) and certain alphanumeric (a-z0-8 1-7) passwords within 15-30 minutes (both MD5), and in general a lot of passwords can be cracked within hours or days. |
|
|
Sorry I don't think I understood this thread at first, but after reading it all again, I think I do. SNoticing on PRIVMSGs would be too spammy for opers, and it's overkill. Plus, I don't see how PRIVMSG could crash the server anyway. MKPASSWD is different however. The hashing process is complex, and can take some time to execute. I'm assuming the MKPASSWD process is asynchronous because of this (so as to avoid blocking), so a user could possibly run 500 MKPASSWD at once. Imagine this at 5000 or 5,000,000. If each MKPASSWD is a seperate thread, eventually you'll hit either the thread limit or the malloc limit, whichever is smaller. And IIRC, in either case the result is a nasty SEH exception on MSVC (on other C systems, I don't know). Plus, what happens if someone specifies a hash algorithm that does crash the server (intentionally or otherwise), or maybe one that is implemented by a alpha or beta quality module? The inputs provided could be useful in tracking down the bug, and if the opers are snoticed with the hash+algorithm, they can report the bug to the appropriate developers. IIRC it already snotices to eyes but doesn't send the hash/algorithm. This should be sufficient for maintaining sanity levels on the server. If it were my network, I wouldn't have MKPASSWD for non-opers anyway because there's no need for it. |
|
|
Aquanight, do some research before posting. ------- SNoticing on PRIVMSGs would be too spammy for opers, and it's overkill. Plus, I don't see how PRIVMSG could crash the server anyway. ------- Why not? regexec() is a very complex function. If badwords and/or spamfilter is in use, it is called for each PRIVMSG. Isn't it conceivable that they will cause a crash? ------- MKPASSWD is different however. The hashing process is complex, and can take some time to execute. ------- The hashing process is simple and takes a relatively small amount of time to compute. To compute a 160bit hash (which is the largest Unreal supports) on at most 499 bytes will take less than 500us on even a slow system. Additionally, the hashing algorithms used have been in use in some cases for 10+ years, they are pretty much stable. ------- I'm assuming the MKPASSWD process is asynchronous because of this (so as to avoid blocking), so a user could possibly run 500 MKPASSWD at once. ------- Your assumption is wrong, it is not asynchronous. ------- If each MKPASSWD is a seperate thread, eventually you'll hit either the thread limit or the malloc limit, whichever is smaller. ------- Unreal doesn't even use threads for anything. And, do you think we're stupid? If we did use threads we'd add checks to prevent those kind of things. We're not idiots, we're smart enough to limit it to say 1 /mkpasswd per user. ------- And IIRC, in either case the result is a nasty SEH exception on MSVC (on other C systems, I don't know). ------- First off, C doesn't even have exceptions, that's an MS extension. Second, running out of memory does not generate an exception, it causes malloc() to return NULL. Thirdly, hitting the thread limit will cause the thread create function to fail, not generate an exception. Neither of these situations generates an exception even under MSVC. ------- Plus, what happens if someone specifies a hash algorithm that does crash the server (intentionally or otherwise), or maybe one that is implemented by a alpha or beta quality module? ------- Unreal supports at most 4 hashing functions. crypt (uses libdes or libcrypt), md5, sha1, ripemd-160 (all provided by openssl). If the system libraries are intentionally adding crash bugs, then you should find a new OS. ------- The inputs provided could be useful in tracking down the bug, and if the opers are snoticed with the hash+algorithm, they can report the bug to the appropriate developers. ------- Not a single bug has ever been reported in /mkpasswd. We, as the developers feel no need to have this for "debugging" purposes, so don't speak for us. ------- If it were my network, I wouldn't have MKPASSWD for non-opers anyway because there's no need for it. ------- Which is why the feature is optional and disabled by default. You seem to know next to nothing about how Unreal works internally, so please refrain from commenting on things you know nothing about. |
|
|
Lol ;). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-03-27 19:00 | JasonTik | New Issue | |
| 2004-03-27 19:02 | syzop | Note Added: 0005612 | |
| 2004-03-27 19:23 |
|
Note Added: 0005613 | |
| 2004-03-27 20:07 | JasonTik | Note Added: 0005616 | |
| 2004-03-27 20:15 |
|
Note Added: 0005617 | |
| 2004-03-27 20:30 | JasonTik | Note Added: 0005618 | |
| 2004-03-27 20:31 |
|
Note Added: 0005619 | |
| 2004-03-27 20:48 | aquanight | Note Added: 0005620 | |
| 2004-03-27 20:50 |
|
Note Added: 0005621 | |
| 2004-03-27 20:55 | syzop | Note Added: 0005622 | |
| 2004-03-28 01:20 | aquanight | Note Added: 0005623 | |
| 2004-03-28 01:32 |
|
Note Added: 0005625 | |
| 2004-03-28 11:45 | syzop | Status | new => closed |
| 2004-03-28 11:45 | syzop | Note Added: 0005628 |
