Rejestrowalne kanały

Wydaje siÄ, Ĺźe rejestracje kanaĹĂłw moĹźna zrobiÄ bardzo prosto, w
dodatku globalnie w caĹej sieci i bazujÄc na istniejÄcym protokole.
MĂłj pomysĹ opiera siÄ na dodaniu dwĂłch nowych trybĂłw kanaĹowych i
jednego polecenia i oczywiĹcie nowego typu kanaĹĂłw.

* Nowy tryb K *

DziaĹaĹby podobnie do k, z tÄ rĂłĹźnicÄ, Ĺźe:

- Nie byĹby oczywiĹcie widoczny dla nikogo na kanale (opcja:
mĂłgĹby byÄ pokazywany na zasadzie podobnej do np. i -- tylko sam
tryb)

- Klucz (hasĹo) mogĹyby ustawiÄ/zmieniÄ/usunÄÄ wyĹÄcznie osoby
pasujÄce do N, przy czym Ĺźeby go zmieniÄ/usunÄÄ naleĹźaĹoby
oczywiĹcie go znaÄ i podaÄ jako parametr

- Klucz (hasĹo) byĹby trzymany w pamiÄci w postaci zakodowanej
nieodwracalnym algorytmem i po prostu porĂłwnywany

- Tryb byĹby opcjonalny, tzn. ustawione K nie byĹoby koniecznie do
dziaĹania tego, o czym niĹźej. DziÄki temu moĹźnaby go uĹźywaÄ bez
hasĹa na maĹych, prywatnych kanaĹach (bardziej user-friendly), a na
wiÄkszych uĹźyÄ dodatkowo hasĹo zwiÄkszajÄc tym samym bezpieczeĹstwo.

* Nowy tryb N *

DziaĹaĹby podobnie do b/e/I/R, z tÄ rĂłĹźnicÄ, Ĺźe:

- JeĹli lista N byĹaby pusta, to maskÄ mĂłgĹby dodaÄ kaĹźdy operator

- JeĹli na liĹcie bÄdzie choÄ jedna maska, to kolejne mogĹyby
dodawaÄ (lub usuwaÄ) wyĹÄcznie osoby pasujÄce do N, w dodatku musiaĹyby
podaÄ hasĹo z K (chyba, Ĺźe K nie jest ustawione)

- Lista N byĹaby widoczna wyĹÄcznie dla osĂłb pasujÄcych do N (opcja:
istnienie listy mogĹoby byÄ pokazywane na zasadzie podobnej do np. i --
tylko sam tryb)

- OczywiĹcie osoby pasujÄce do maski N mogĹyby wejĹÄ na kanaĹ pomimo
b/i/l/k czy czegokolwiek innego i nie dziaĹaĹby na nie KICK, w koĹcu to
owNerzy.

* Nowe polecenie RECOVER *

MogĹaby go uĹźyÄ tylko osoba pasujÄca do N, jako parametr podawany
byĹby K (chyba, Ĺźe nie byĹby ustawiony). Serwer deopowaĹby wtedy
wszystkich operatorĂłw i dawaĹ opa tej osobie.

* PrzykĹadowe uĹźycie *

/join %nowykanaĹ
/mode %nowykanaĹ +K kaczukaczu

(w miÄdzyczasie ktoĹ zrobiĹ t/o)

/join %nowykanaĹ
/recover %nowykanaĹ kaczukaczu

* Analiza pomysĹu *

Zalety:

- Przy rozsÄdnym uĹźyciu (ustawiony K, w dodatku odpowiednio dĹugi)
zapewnia prawie 100% bezpieczeĹstwa kanaĹu

- Jest logiczny, Ĺatwy do zrozumienia i uĹźywania nawet dla newbies
(skoro radzÄ sobie z bardziej skomplikowanym ChanServem)

- Ĺatwy do zaimplementowania, nie ingeruje w zasadzie w protokĂłĹ, nie
wymaga tworzenia dodatkowych baz danych itp.

- Nawet t/o z konta pasujÄcego do N nie powoduje straty kanaĹu, o ile
oczywiĹcie K jest ustawione i abuser go nie zna

- DziaĹanie RECOVER powoduje moĹźliwie najmniejszy zamÄt na kanale, jest
takĹźe odporne na desynch (w razie czego moĹźna tego polecenia uĹźyÄ
ponownie)

Wady:

- Nieuczciwy (i o sporej wiedzy) admin serwera IRC mĂłgĹby popsuÄ hurtowo
duĹźÄ iloĹc kanaĹĂłw (ale to moĹźe zrobiÄ i teraz, w dodatku Ĺatwiej)

Autor	Wiadomość
Neas	Posted: 5 Wrz 2005 13:32:53 Wydaje siÄ, Ĺźe rejestracje kanaĹĂłw moĹźna zrobiÄ bardzo prosto, w dodatku globalnie w caĹej sieci i bazujÄc na istniejÄcym protokole. MĂłj pomysĹ opiera siÄ na dodaniu dwĂłch nowych trybĂłw kanaĹowych i jednego polecenia i oczywiĹcie nowego typu kanaĹĂłw. * Nowy tryb K * DziaĹaĹby podobnie do k, z tÄ rĂłĹźnicÄ, Ĺźe: - Nie byĹby oczywiĹcie widoczny dla nikogo na kanale (opcja: mĂłgĹby byÄ pokazywany na zasadzie podobnej do np. i -- tylko sam tryb) - Klucz (hasĹo) mogĹyby ustawiÄ/zmieniÄ/usunÄÄ wyĹÄcznie osoby pasujÄce do N, przy czym Ĺźeby go zmieniÄ/usunÄÄ naleĹźaĹoby oczywiĹcie go znaÄ i podaÄ jako parametr - Klucz (hasĹo) byĹby trzymany w pamiÄci w postaci zakodowanej nieodwracalnym algorytmem i po prostu porĂłwnywany - Tryb byĹby opcjonalny, tzn. ustawione K nie byĹoby koniecznie do dziaĹania tego, o czym niĹźej. DziÄki temu moĹźnaby go uĹźywaÄ bez hasĹa na maĹych, prywatnych kanaĹach (bardziej user-friendly), a na wiÄkszych uĹźyÄ dodatkowo hasĹo zwiÄkszajÄc tym samym bezpieczeĹstwo. * Nowy tryb N * DziaĹaĹby podobnie do b/e/I/R, z tÄ rĂłĹźnicÄ, Ĺźe: - JeĹli lista N byĹaby pusta, to maskÄ mĂłgĹby dodaÄ kaĹźdy operator - JeĹli na liĹcie bÄdzie choÄ jedna maska, to kolejne mogĹyby dodawaÄ (lub usuwaÄ) wyĹÄcznie osoby pasujÄce do N, w dodatku musiaĹyby podaÄ hasĹo z K (chyba, Ĺźe K nie jest ustawione) - Lista N byĹaby widoczna wyĹÄcznie dla osĂłb pasujÄcych do N (opcja: istnienie listy mogĹoby byÄ pokazywane na zasadzie podobnej do np. i -- tylko sam tryb) - OczywiĹcie osoby pasujÄce do maski N mogĹyby wejĹÄ na kanaĹ pomimo b/i/l/k czy czegokolwiek innego i nie dziaĹaĹby na nie KICK, w koĹcu to owNerzy. * Nowe polecenie RECOVER * MogĹaby go uĹźyÄ tylko osoba pasujÄca do N, jako parametr podawany byĹby K (chyba, Ĺźe nie byĹby ustawiony). Serwer deopowaĹby wtedy wszystkich operatorĂłw i dawaĹ opa tej osobie. * PrzykĹadowe uĹźycie * /join %nowykanaĹ /mode %nowykanaĹ +K kaczukaczu (w miÄdzyczasie ktoĹ zrobiĹ t/o) /join %nowykanaĹ /recover %nowykanaĹ kaczukaczu * Analiza pomysĹu * Zalety: - Przy rozsÄdnym uĹźyciu (ustawiony K, w dodatku odpowiednio dĹugi) zapewnia prawie 100% bezpieczeĹstwa kanaĹu - Jest logiczny, Ĺatwy do zrozumienia i uĹźywania nawet dla newbies (skoro radzÄ sobie z bardziej skomplikowanym ChanServem) - Ĺatwy do zaimplementowania, nie ingeruje w zasadzie w protokĂłĹ, nie wymaga tworzenia dodatkowych baz danych itp. - Nawet t/o z konta pasujÄcego do N nie powoduje straty kanaĹu, o ile oczywiĹcie K jest ustawione i abuser go nie zna - DziaĹanie RECOVER powoduje moĹźliwie najmniejszy zamÄt na kanale, jest takĹźe odporne na desynch (w razie czego moĹźna tego polecenia uĹźyÄ ponownie) Wady: - Nieuczciwy (i o sporej wiedzy) admin serwera IRC mĂłgĹby popsuÄ hurtowo duĹźÄ iloĹc kanaĹĂłw (ale to moĹźe zrobiÄ i teraz, w dodatku Ĺatwiej)
Piotr KUCHARSKI	Posted: 5 Wrz 2005 14:17:31 Wydaje się, że rejestracje kanałów można zrobić bardzo prosto, w dodatku globalnie w całej sieci i bazując na istniejącym protokole. Mój pomysł opiera się na dodaniu dwóch nowych trybów kanałowych i jednego polecenia i oczywiście nowego typu kanałów. ...i wszystko na nic, gdy kanał zniknie (wszyscy użytkownicy zostaną wyDDoSowani) i zostanie zapomniany. Przy okazji: nowy typ kanału, który by miał być globalny, a który by był rejestrowalny... może po prostu nie przejść przez innych ircopów. p.
Jakub Jankowski	Posted: 5 Wrz 2005 15:15:22 - Nawet t/o z konta pasującego do N nie powoduje straty kanału, o ile oczywiście K jest ustawione i abuser go nie zna Abuser przejmuje jedno konto pasujące do listy +N, deopuje wszystkich poza sobą, usuwa całą listę +N, dodaje do +N maskę siebie. Co wtedy?
Neas	Posted: 5 Wrz 2005 15:15:29 Wydaje siÄ, Ĺźe rejestracje kanaĹĂłw moĹźna zrobiÄ bardzo prosto, w dodatku globalnie w caĹej sieci i bazujÄc na istniejÄcym protokole. MĂłj pomysĹ opiera siÄ na dodaniu dwĂłch nowych trybĂłw kanaĹowych i jednego polecenia i oczywiĹcie nowego typu kanaĹĂłw. ...i wszystko na nic, gdy kanaĹ zniknie (wszyscy uĹźytkownicy zostanÄ wyDDoSowani) i zostanie zapomniany. Przy okazji: nowy typ kanaĹu, ktĂłry by miaĹ byÄ globalny, a ktĂłry by byĹ rejestrowalny... moĹźe po prostu nie przejĹÄ przez innych ircopĂłw. MoĹźna pamiÄtaÄ kanaĹ (i niektĂłre tryby, np. wĹaĹnie N i K) przez jakiĹ, dĹuĹźszy czas, bo na zawsze raczej nie ma sensu. MyĹlÄ, Ĺźe miesiÄc to rozsÄdny okres, nikt nie bÄdzie tak dĹugo ddosowaĹ iluĹtam serwerĂłw Ĺźeby zdobyÄ kanaĹ (poza tym dawno odpowiedni ISP by taki DDoS przez ten czas wyfiltrowali).
Neas	Posted: 5 Wrz 2005 15:30:51 Abuser przejmuje jedno konto pasujÄce do listy +N, deopuje wszystkich poza sobÄ, usuwa caĹÄ listÄ +N, dodaje do +N maskÄ siebie. Co wtedy? Po pierwsze lista N byĹaby dla niego niewidoczna, wiÄc musiaĹby trafiaÄ, jakie to konto, po drugie musiaĹby dodatkowo znaÄ hasĹo (K). W praktyce sytuacja jest raczej nierealna. Ostatecznie zawsze istnieje jakaĹ luka, abuser moĹźe np. porwaÄ ownera, porozmawiaÄ z nim po swojemu, a potem zakopaÄ w lesie.
Piotr KUCHARSKI	Posted: 5 Wrz 2005 15:30:57 ...i wszystko na nic, gdy kanał zniknie (wszyscy użytkownicy zostaną wyDDoSowani) i zostanie zapomniany. Można pamiętać kanał (i niektóre tryby, np. właśnie N i K) przez jakiś, dłuższy czas, bo na zawsze raczej nie ma sensu. Myślę, że miesiąc to rozsądny okres, A (L)DCTL to taki straszny hack, mówiłeś... nikt nie będzie tak długo ddosował iluśtam serwerów żeby zdobyć kanał (poza tym dawno odpowiedni ISP by taki DDoS przez ten czas wyfiltrowali). Przykład DALNetu pokazuje, że można, niestety. p.
Piotr Niżyński	Posted: 5 Wrz 2005 15:42:47 Abuser przejmuje jedno konto pasujące do listy +N, deopuje wszystkich poza sobą, usuwa całą listę +N, dodaje do +N maskę siebie. Co wtedy? Napisał, że do zmiany aktywnych +N trzeba podać hasło jako drugi parametr mode.
Neas	Posted: 5 Wrz 2005 15:43:16 ...i wszystko na nic, gdy kanaĹ zniknie (wszyscy uĹźytkownicy zostanÄ wyDDoSowani) i zostanie zapomniany. MoĹźna pamiÄtaÄ kanaĹ (i niektĂłre tryby, np. wĹaĹnie N i K) przez jakiĹ, dĹuĹźszy czas, bo na zawsze raczej nie ma sensu. MyĹlÄ, Ĺźe miesiÄc to rozsÄdny okres, A (L)DCTL to taki straszny hack, mĂłwiĹeĹ... (L)DCTL to przecieĹź co innego. ProponujÄ pamiÄtaÄ przez miesiÄc, a nie zawsze dlatego, Ĺźe nieobecnoĹÄ kogokolwiek na kanale przez caĹy miesiÄc najprawdopodobniej oznacza, Ĺźe kanaĹ zostaĹ po prostu opuszczony i nie jest juĹź potrzebny (przypuszczam, Ĺźe informacje o kanaĹach takĹźe w services nie sÄ przechowywane wiecznie). nikt nie bÄdzie tak dĹugo ddosowaĹ iluĹtam serwerĂłw Ĺźeby zdobyÄ kanaĹ (poza tym dawno odpowiedni ISP by taki DDoS przez ten czas wyfiltrowali). PrzykĹad DALNetu pokazuje, Ĺźe moĹźna, niestety. NaprawdÄ sÄdzisz, Ĺźe ktoĹ by DDoS-owaĹ tak dĹugo jakiĹ kanaĹ? Poza tym szansa na to, Ĺźe DDoS-erowi uda siÄ doprowadziÄ do sytuacji, w ktĂłrej na kanaĹ nikt przez miesiÄc nie wejdzie jest w zasadzie zerowa. Tak wiÄc byĹoby to dziaĹanie z zakresu przeszkadzania (a nie t/o), co moĹźna robiÄ zawsze, gdy znane sÄ prawdziwe hosty osĂłb z kanaĹu.
Krzysztof Kowalik	Posted: 5 Wrz 2005 16:21:41 [...] : W praktyce sytuacja jest raczej nierealna. Ostatecznie zawsze istnieje : jakaś luka, abuser może np. porwać ownera, porozmawiać z nim po : swojemu, a potem zakopać w lesie. Ach, ta wszechobecna przemoc. A wystarczy włamać się na serwer IRC. Albo na odpowiednią maszynę blisko serwera IRC, albo...
Jakub Jankowski	Posted: 5 Wrz 2005 16:21:51 Abuser przejmuje jedno konto pasujące do listy +N, deopuje wszystkich poza sobą, usuwa całą listę +N, dodaje do +N maskę siebie. Co wtedy? Po pierwsze lista N byłaby dla niego niewidoczna, więc musiałby trafiać, jakie to konto, Napisałeś, że lista N byłaby widoczna dla osób pasujących do N? po drugie musiałby dodatkowo znać hasło (K). W praktyce sytuacja jest raczej nierealna. Skoro już założyliśmy, że abuser dostał się na konto ownera, to dlaczego miałby tam nie znaleźć hasła? To tak bardzo nierealne? Mógł je też tydzień wcześniej wysniffować.
Piotr Niżyński	Posted: 5 Wrz 2005 18:48:36 Skoro już założyliśmy, że abuser dostał się na konto ownera, to dlaczego miałby tam nie znaleźć hasła? To tak bardzo nierealne? Mógł je też tydzień wcześniej wysniffować. Heh, próbka mądrości pl.irc. Zresztą już kiedyś o tym pisałem. Neas, nie łudź się, Twoje rozwiązania nigdy nie wejdą w życie. Nie w tej sieci przynajmniej. Zresztą Jakubie, mnie na przykład nie obchodzi co się stanie, gdy ktoś się włamie na moje konto albo wysniffuje jakieś hasło. Moja intuicja podpowiada mi, że przynajmniej w przeciągu najbliższych lat to nie nastąpi i w tym przypadku ufam jej w pełni.
Neas	Posted: 5 Wrz 2005 18:48:56 Po pierwsze lista N byĹaby dla niego niewidoczna, wiÄc musiaĹby trafiaÄ, jakie to konto, NapisaĹeĹ, Ĺźe lista N byĹaby widoczna dla osĂłb pasujÄcych do N? To co, N jest abuserem? Zdecyduj siÄ. : Chodzi mi o to, Ĺźe abuser, Ĺźeby w ogĂłle zaczÄÄ abusowaÄ musiaĹby siÄ dowiedzieÄ, co jest na liĹcie N, co mogĹoby stanowiÄ dla niego nielada problem. A potem jeszcze zdobyÄ hasĹo. po drugie musiaĹby dodatkowo znaÄ hasĹo (K). W praktyce sytuacja jest raczej nierealna. Skoro juĹź zaĹoĹźyliĹmy, Ĺźe abuser dostaĹ siÄ na konto ownera, to dlaczego miaĹby tam nie znaleĹşÄ hasĹa? To tak bardzo nierealne? JeĹli ktoĹ przechowuje na koncie hasĹo... MĂłgĹ je teĹź tydzieĹ wczeĹniej wysniffowaÄ. ....albo uĹźywa go ciÄgle to juĹź jakby jego problem. Na tej zasadzie moĹźna skrytykowaÄ niemal kaĹźde zabezpieczenie: "a co, jesli sobie przyklei hasĹo pod klawiaturÄ?". Proponowane przeze mnie rozwiÄzanie daje przynajmniej podobny poziom zabezpieczeĹ jak ChanServ, a zaryzykowaĹbym nawet stwierdzenie, ze wyĹźszy (bo trudniej zgadnÄÄ co jest na liĹcie).
Neas	Posted: 5 Wrz 2005 18:49:05 [...] : W praktyce sytuacja jest raczej nierealna. Ostatecznie zawsze istnieje : jakaĹ luka, abuser moĹźe np. porwaÄ ownera, porozmawiaÄ z nim po : swojemu, a potem zakopaÄ w lesie. Ach, ta wszechobecna przemoc. A wystarczy wĹamaÄ siÄ na serwer IRC. Albo na odpowiedniÄ maszynÄ blisko serwera IRC, albo... To samo tyczy siÄ services czy innych podobnych rozwiÄzaĹ. ZresztÄ wysniffowanie hasĹa byĹoby w moim rozwiÄzaniu bardzo trudne, bo przecieĹź w typowej sytuacji byĹoby ono uĹźywane niezwykle rzadko.
Stanisław Halik	Posted: 5 Wrz 2005 19:03:24 - Klucz (hasło) mogłyby ustawić/zmienić/usunąć wyłącznie osoby pasujące do N, przy czym żeby go zmienić/usunąć należałoby oczywiście go znać i podać jako parametr czyli wiązałoby to się z zaimplementowaniem timestampów? przy burscie serwery zamieniają się +l, mam nadzieję, że nie byłoby tak z +N, oczywiście jeśli propozycja przejdzie.
Derek KuliĹski / takeda	Posted: 5 Wrz 2005 19:41:35 : W praktyce sytuacja jest raczej nierealna. Ostatecznie zawsze istnieje : jakaĹ luka, abuser moĹźe np. porwaÄ ownera, porozmawiaÄ z nim po : swojemu, a potem zakopaÄ w lesie. Ach, ta wszechobecna przemoc. A wystarczy wĹamaÄ siÄ na serwer IRC. Albo na odpowiedniÄ maszynÄ blisko serwera IRC, albo... ... uprowadziÄ borysa? ;
Derek KuliĹski / takeda	Posted: 5 Wrz 2005 21:27:51 - Jest logiczny, Ĺatwy do zrozumienia i uĹźywania nawet dla newbies (skoro radzÄ sobie z bardziej skomplikowanym ChanServem) Zapominasz, Ĺźe ChanServ ma jakĹźe pomocne polecenie HELP, gdzie wszystko jest wytĹumaczone w miarÄ dokĹadnie. MoĹźe ten pomysĹ jest OK, ale IMO prowadzi sieÄ w zĹym kierunku (nowe flagi sprawiajÄ, Ĺźe sieÄ jest coraz bardziej zawiĹa, a to jest niedobre).
Jakub Jankowski	Posted: 5 Wrz 2005 22:50:35 Po pierwsze lista N byłaby dla niego niewidoczna, więc musiałby trafiać, jakie to konto, Napisałeś, że lista N byłaby widoczna dla osób pasujących do N? To co, N jest abuserem? Zdecyduj się. : Chodzi mi o to, że abuser, żeby w ogóle zacząć abusować musiałby się dowiedzieć, co jest na liście N, co mogłoby stanowić dla niego nielada problem. W takim razie doprecyzuj swoją wypowiedź: #v+ - Lista N byłaby widoczna wyłącznie dla osób pasujących do N (opcja: istnienie listy mogłoby być pokazywane na zasadzie podobnej do np. i -- tylko sam tryb) #v- Co to za "opcja"? Włączana per serwer? per kanał? A potem jeszcze zdobyć hasło. OK, tu się może trochę zagalopowałem. Proponowane przeze mnie rozwiązanie daje przynajmniej podobny poziom zabezpieczeń jak ChanServ, a zaryzykowałbym nawet stwierdzenie, ze wyższy (bo trudniej zgadnąć co jest na liście). To jeszcze może poproszę o wytłumaczenie, w jaki sposób można tę listę zobaczyć.
xec	Posted: 6 Wrz 2005 10:40:58 To samo tyczy się services czy innych podobnych rozwiązań. Zresztą wysniffowanie hasła byłoby w moim rozwiązaniu bardzo trudne, bo przecież w typowej sytuacji byłoby ono używane niezwykle rzadko. Po wydosowaniu jednorazowo z kanaly wszystkich bylo by ono uzyte niezwykle szybko ;)
xec	Posted: 6 Wrz 2005 10:41:03 Heh, próbka mądrości pl.irc. Zresztą już kiedyś o tym pisałem. Neas, nie łudź się, Twoje rozwiązania nigdy nie wejdą w życie. Nie w tej sieci przynajmniej. Pewnie Neas sie nie ludzi tym ze to wejdzie w zyciu, on chcial tylko zeby cos sie na grupie dzialo... i dzieje sie :]
Neas	Posted: 6 Wrz 2005 18:30:48 To samo tyczy się services czy innych podobnych rozwiązań. Zresztą wysniffowanie hasła byłoby w moim rozwiązaniu bardzo trudne, bo przecież w typowej sytuacji byłoby ono używane niezwykle rzadko. Po wydosowaniu jednorazowo z kanaly wszystkich bylo by ono uzyte niezwykle szybko ;) Zastanów się. Abuser nie zna N, psuje operatorów, N wchodzi i używa K ale... przecież abuser nie wiedział z czego wejdzie, więc nie mógł sniffować. Zresztą sniffowanie to trochę zbyt skomplikowana i zależna od różnych czynników kwestia, żeby zakładać, ze zawsze będzie to możliwe jeśli abuse pozna zawartość listy N. Gdyby tak nie było, to wiele istniejących zabezpieczeń nie miałaby sensu (może nawet większość, w każdym razie wszystkie nieszyfrowane).
Neas	Posted: 6 Wrz 2005 18:31:08 Neas, nie łudź się, Twoje rozwiązania nigdy nie wejdą w życie. Nie w tej sieci przynajmniej. Pewnie Neas sie nie ludzi tym ze to wejdzie w zyciu, on chcial tylko zeby cos sie na grupie dzialo... i dzieje sie :] Ani się za bardzo nie zastanawiam, czy ma szansę, ani nie zależy mi szczególnie na tym, żeby na grupie coś się działo.
Neas	Posted: 6 Wrz 2005 18:31:18 W takim razie doprecyzuj swoją wypowiedź: #v+ - Lista N byłaby widoczna wyłącznie dla osób pasujących do N (opcja: istnienie listy mogłoby być pokazywane na zasadzie podobnej do np. i -- tylko sam tryb) #v- Co to za "opcja"? Włączana per serwer? per kanał? Opcja, w tym sensie, ze nie jestem pewien, czy warto to implementować. Proponowane przeze mnie rozwiązanie daje przynajmniej podobny poziom zabezpieczeń jak ChanServ, a zaryzykowałbym nawet stwierdzenie, ze wyższy (bo trudniej zgadnąć co jest na liście). To jeszcze może poproszę o wytłumaczenie, w jaki sposób można tę listę zobaczyć. Tak jak napisałem widziałyby ją wyłącznie osoby pasujące do któregoś z N.
Neas	Posted: 6 Wrz 2005 18:36:19 - Klucz (hasĹo) mogĹyby ustawiÄ/zmieniÄ/usunÄÄ wyĹÄcznie osoby pasujÄce do N, przy czym Ĺźeby go zmieniÄ/usunÄÄ naleĹźaĹoby oczywiĹcie go znaÄ i podaÄ jako parametr czyli wiÄzaĹoby to siÄ z zaimplementowaniem timestampĂłw? przy burscie serwery zamieniajÄ siÄ +l, mam nadziejÄ, Ĺźe nie byĹoby tak z +N, oczywiĹcie jeĹli propozycja przejdzie. Moim zdaniem to nie ma istotnego znaczenia. Zaimplementowanie czegoĹ w rodzaju timestampĂłw czy skorelowanie K z detekcjÄ splitĂłw rodzi inne problemy.
Piotr KUCHARSKI	Posted: 6 Wrz 2005 18:39:48 przy burscie serwery zamieniają się +l, Bo może być tylko jedno, myśl. :) mam nadzieję, że nie byłoby tak z +N, oczywiście jeśli propozycja przejdzie. +beIR się sumują. W sumie tu widzę największe zagrożenie. Nie ma co się do tego nawet zabierać, póki nie będzie ostatecznie rozwiązany problem nethack op. p.
Jakub Jankowski	Posted: 6 Wrz 2005 21:32:46 Proponowane przeze mnie rozwiązanie daje przynajmniej podobny poziom zabezpieczeń jak ChanServ, a zaryzykowałbym nawet stwierdzenie, ze wyższy (bo trudniej zgadnąć co jest na liście). To jeszcze może poproszę o wytłumaczenie, w jaki sposób można tę listę zobaczyć. Tak jak napisałem widziałyby ją wyłącznie osoby pasujące do któregoś z N. Czyli abuser, który przejmie jedno z kont pasujących do N, nie będzie musiał zgadywać, co sugerowałeś w poprzednim poście.
Derek KuliĹski / takeda	Posted: 7 Wrz 2005 11:00:51 Po wydosowaniu jednorazowo z kanaly wszystkich bylo by ono uzyte niezwykle szybko ;) ZastanĂłw siÄ. Abuser nie zna N, psuje operatorĂłw, N wchodzi i uĹźywa K ale... przecieĹź abuser nie wiedziaĹ z czego wejdzie, wiÄc nie mĂłgĹ sniffowaÄ. ZresztÄ sniffowanie to trochÄ zbyt skomplikowana i zaleĹźna od rĂłĹźnych czynnikĂłw kwestia, Ĺźeby zakĹadaÄ, ze zawsze bÄdzie to moĹźliwe jeĹli abuse pozna zawartoĹÄ listy N. Gdyby tak nie byĹo, to wiele istniejÄcych zabezpieczeĹ nie miaĹaby sensu (moĹźe nawet wiÄkszoĹÄ, w kaĹźdym razie wszystkie nieszyfrowane). No jednÄ z pozycji +N moĹźna Ĺatwo poznaÄ. Wystarczy wyddosowaÄ kanaĹ i poczekaÄ aĹź ktoĹ zrobi RECOVER.
xec	Posted: 7 Wrz 2005 11:01:49 Ani się za bardzo nie zastanawiam, czy ma szansę, ani nie zależy mi szczególnie na tym, żeby na grupie coś się działo. Wiem ze trudno sie byloby zgodzic, wiekszosc ludzi tutaj ma takie charaktery ze poprostu nie dopuszczaja do siebie mysli ze mogliby sie z kims zgodzic ;]
Neas	Posted: 7 Wrz 2005 12:22:35 (...) Mówi się, że programista NIGDY nie powinien tworzyć interfejsu dla użytkownika. Coś w tym jest. Więc dlatego się tym nie zajmuj... wypisujesz głupoty sugerując, że userom w IRCnecie będzie łatwiej poznać nowe narzędzie którym jest ChanServ, zupełnie nową składnię poleceń i całą filozofę działania niż po prostu dwa nowe tryby działające analogicznie do tych, których używają od lat. Nie wspominając już o tym, że obsługa ChanServa jest obiektywnie dużo bardziej skomplikowana, bo ma on mnóstwo niepotrzebnych przeciętnemu klikaczowi funkcji. A najlepiej stworzyć klienta specjalnie przygotowanego dla danej sieci. (...) Tu masz racje pod warunkiem że byłby to klient dostępny z poziomu www, napisany w Javie na przykład.
Neas	Posted: 7 Wrz 2005 13:33:22 No jedną z pozycji +N można łatwo poznać. Wystarczy wyddosować kanał i poczekać aż ktoś zrobi RECOVER. Tak... a potem wyddosować drugi raz i zupełnie przypadkiem wysniffować hasło, a na końcu zapuścić ping-of-death i tsunami-flood.
Neas	Posted: 7 Wrz 2005 14:17:57 jeśli ten chanserv byłby tak beznadziejnie zaimplementowany jak u was, to ja zdecydowanie wolę +N(eas). A widziałeś tego na QuakeNecie? Jest chyba jeszcze gorszy i mniej intuicyjny i bardziej zagmatwany. Ciekawe co palili jak go projektowali...

Forum IRC