SSH honeypot: nincs támadás?

 ( janoszen | 2019. március 14., csütörtök - 6:25 )

Sziasztok,

úgy döntöttem, hogy játszom egyet: építettem egy SSH honeypotot ami minden jelszót és SSH kulcsot beenged és bevágja egy hálózat nélküli Docker containerbe. (Igen, ismerem a biztonsági oldalát, ezen kívül is vannak még védelmi mechanizmusok.)

A honeypot mindent fejlegyez, bináris szinten a különböző adatstreameket is, de végig fésülve kb két napnyi adatot, szinte kizárólag ilyeneket látok:

{"timestamp":"2019-03-14T00:58:54.679","sessionId":"LgnlsPWXPJUzMzBhRad1NxjIRXQ7SEvZaP1MG2MOjfw","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:5127","username":"admin","password":"admin"}}

Ezen kívül semmi. Nem kért shellt, nem küldött parancsot, semmi. Vagyis csak végig próbálják a jelszavakat, de semmit nem csinálnak vele. Ez miért lehet? Mi értelme ennek?

Köszönöm

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Gondolom későbbi DDOS támadáshoz ez is elég :)

Leírnád, hogy hogyan csináltad?

Apache MINA + Docker API. Reszletesebben is leirom majd a blogomon, de meg takaritasra szorul.

--
Pásztor János

+1 :D

+1 És ne engedd be minden jelszóval! Próbálkozni fog az sokat, ha nincs fail2ban..

Szerintem pont az a cél, hogy próbálkozzon jó sokat :D

Igen, csak a poster ezt írta:
"ami minden jelszót és SSH kulcsot beenged"

Jaa, értem már. Szerintem nem fognak leállni az első pozitív találatnál. Egyrészt mert tippre rém buta (egyszerű) scriptek szaglásznak körbe, másrészt meg ahol egy admin:admin van, ott hátha van egy root:root is. És lesz is! :D

"A zeneiparban bármi megtörténhet!" – zuutty, egy hulla – "és rendszerint meg is történik!"

Fail2ban esetén otthon az van, h ha egy nap betalálnak, akkor onnan mocsok sok IP címről jön még próbálkozás, gondolom valami botnetet használnak erre a célra. A fail2ban nyilván kizárja az egyes címeket idővel, de ilyenkor szépen teli vele a log.

Miért jó ilyet csinálni?
Nézed, hogy hol tart a világ plusz foglalod a támadók erőforrásait, vagy miért?

pl tuzfalat tanitani belole

A kérdéséből ítélve arra kíváncsi, hogy a betörők milyen scriptecskéket helyez(né)nek a gépeken, amik aztán majd ügyeskednek mindenfélét.

De egyelőre még csak ott tart, hogy felkerült a lehetséges célpontok közé.

Értem, köszi.

Egy példa: Felteszel egy honeypot-ot egy(az összes) belső hálózati LAN-ba. És ha megtörnek egy gépet kívülről, és már benn vannak a LAN-ban el fognak kezdeni felderíteni pl. nmap-al hová lehet tovább lépni ssh/samba/rdp akármi protokollon. Ekkor ugye egy portscannel betalálnak a honeypotra is. És megy a riasztás a SIEM-be, vagy akár tűzfal szabály, switch port letiltás akármi lehet belőle.

Ehhez miért kell honeypot?

nem egyszerűbb/praktikusabb e helyett n db failed login attempt után reportolni/karanténozni? Meg ott van az intelligens tűzfalazás ha a user gyanús időpontban lép be/ adott user gyanús/szokatlan parancsokat futtat, etc.

Ez egy példa volt, van ezer más lehetőség is nyilván.

Tobb okbol, de tobbnyire azert, hogy felmerjem az aktualis tamadasi megoldasokat, exploitokat, stb.

--
Pásztor János

Nem akarod megosztani a címet? :)

Meg a vegen szethekkelnek a hupperek :D

Elkuldtem privatban.

--
Pásztor János

Gyáva! :)

Tipp #1: Én ha kormány/ddos célpont/cloudflare lennék, akkor folyamatosan scannelném az ipv4 címeket könnyen törhető célpontok után kutatva hogy esetleges támadás esetén ezeket a címeket blokkoljam.
Tipp #2: Valószínű van aki abból csinál pénzt, hogy felderíti ezeket a könnyű célpontokat és eladja a listát másoknak

Ezek jo valaszok, koszi!

--
Pásztor János

ezek csak sima botok amik aldozatot keresnek. van egy ip lista (vagy csak lepkednek vegig a tartomanyokon), es nezik mibe lehet belepni. aztan lesz egy "hasznalhato gepek listaja", amit a rosszfiu elad vagy felhasznal tovabbi tamadaskor. nem egy ember es nem egyfelekeppen keresik az aldozatot.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Gyanítom az adott zombi gép csak ssh törési feladatot kapott, a sikeres belépéseket pedig vissza jelenti a központi rendszernek valami proxyn vagy más zombi gépen keresztül, aztán az majd kiadja a parancsot valamelyik másik zombinak később hogy az adott ip/login adatokkal álljon neki új zombikat gyártani.

Fentebb egy dictionary attack van, azaz simán próbálgat N darab sűrűn juzer+jelszó párost. Ezt azért csak jóindulattal nevezzük feltörésnek, mert simán egy trehány jelszó miatt beléptek. Ettől még teljesen életveszélyes, mert számolatlanul tudnak ezek szaporodni.

Lehet hogy honeypot-nak érzékeli a bot, ha elsőre be tud jutni? False pozitív találatnál veszi és eldobja mint potenciális végpont.
Azóta volt másik próbálkozás?

Igen, volt olyan amelyik nemi elteressel ugyanazzal a usernevvel/jelszoval belepett tobbszor is:

{"timestamp":"2019-03-14T08:04:59.464","sessionId":"wmf22qayquHfcN8qzd+9kSARpVRQn3x7+Goqlv7y9xI","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:63031","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T11:20:18.892","sessionId":"cosCR-5tU3MnOAs89zdnhKUKvfVu0tfDDODNOuSKwFw","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:44877","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T15:34:35.429","sessionId":"nb7D+J+tmlc6bBncP7q68JF+Hn8CRS0EVSPOgaU2RUw","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:62626","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T06:37:58.961","sessionId":"D-S9j16WFlkI2isBXvfxvoq7l9WtwwDeN2dJzNlcP4g","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:37202","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T12:07:29.906","sessionId":"9fS3YEv4-ORAtdgkZu9DC+bGC8chQg5JzAsFHWmT2So","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:40883","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T13:36:41.45","sessionId":"Lt-NXiVfB3IZ6OfVMRQESDiixVXkgVrdE3WZpknbWAc","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:21716","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T09:50:36.28","sessionId":"ltn4OVC3MZlzqprZjHdHVc0eEWTFnUPI+GNw2f1s6CY","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:6928","username":"admin","password":"admin"}}

A sorok nincsenek sorrendben sajnos.

--
Pásztor János

Ami meg erdekes: eleg sok bejelentkezes van "pi" usernevvel. Gondolom rpi-kre vadasznak, csak nem tudom miert.

--
Pásztor János

Biztos rpi-re mennek, abból is sok lóg a neten és nem hivatasos rendszergazdák telepítik.

Március 14, pí-nap. Ennyi az egész :)

triviális a magyarázat: a gyári Raspbian lemezképen a nonroot de sudoer júzer neve pi a jelszava meg raspberry.

sok kis nokedli meg anélkül akasztja rá a világhálóra hogy ezt megváltoztatná, SSH meg ugye nyitva a huszonkettesen.

IIRC volt egy Monero bányász botnet ami kizárólag raspberryket fertőzött ezt a logikát követve.


"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."

Biztonság, de tök más téma:

Tudtok olyan browser plugin-ról ami azt figyeli egy oldal forrásában, hogy az authentikáció alatt van-e kliens oldali hash képzés?

Tehát, hogy plain textbe megy-e a jelszó az adott oldalon.

Ilyenről nem tudok, de ha létezne, akkor azért elég sok módszerrel át lehetne verni.

Nem HTTPS-es oldalon ne adj meg jelszót és kész! Ha HTTP, akkor úgyis buktad MITM lehetősége miatt, kivétel ha OTP-t (vagy tokent) használsz, de akkor is csak akkor, ha minden művelethez szükséges és biztonságos csatornán kapod a jóváhagyandó műveletet. De akkor meg mi értelme? Visszakanyarodtunk a HTTPS-hez :) Bár elméletben kiírhatna egy QR kódot, amiben benne van a művelet, majd beolvasod telefonnal és így látod a műveletet és annak a hash-ét írod alá és ezt adod meg mondjuk egy formon, így HTTP-n is lehet az oldal. Persze az időt is bele kell kódolni, hogy ne lehessen ismételni.

Nem az SSL hiánya a lényeges, ha nincs hash képzés és elküldi a jelszót, akkor úgy tekintem, hogy azt plain text tárolják.
Függetlenül attól, hogy titkosítva közlekedik-e, vagy sem.

Már miért tárolnák plain textben? Elküldöd a jelszót, majd szerver oldalon a megfelelő salttal együtt hashselve összehasonlítják az általuk tárolt hashsel.

"akkor úgy tekintem, hogy azt plain text tárolják."

Azért mert megtehetnék..

Nem ertem az egeszet. Mitol jobb az, ha hashselve kuldod? A WWW MD5 auth (amit SIP-nel is alkalmaznak) ugy mukodik, hogy kapsz egy noncet (mindig valtozik), amivel hashseled a jelszot es az megy el a szerver fele (csak a hash). A szerver ezutan a maganal clear textben tarolt jelszot szinten hashseli a nonceszal es ha egyezes van, akkor authentikal. Nesze neked hash!

Szerk:
Ráadásul azt sem tudod megállapítani, hogy a jelszó biztonságosan hashselve van elküldve. Lehet hogy szimmetrikus vagy nyílvános kulcsú titkosítással küldi el a script vagy direkt valami gyenge hasht alkalmaznak, hogy vissza lehessen fejteni. Ezt egy program nem tudja eldönteni.

Ha már jelszót kell megadni egy nem saját adminisztráció alatt lévő felületen (tehát nem nálad old fel valamit), akkor már eleve nincs biztonságban. Ezért használnak komolyabb helyeken tokent, SSH esetén PKI-t, HTTPS-en kliens oldali tanúsítványt, stb.. Ugye ezeket is fel kell oldani valami jelszóval vagy/és biometrikusan, de akkor már a te eszközöd biztonsága számít.

Annyiban jobb lenne, hogy ha a szerver vagy a http proxy biztonsága sérül és pl. logolni tudja valaki a https lekérdezéseket, akkor csak a hashelt jelszóhoz férne hozzá. (persze ez esetben megtehetné, hogy módosítja a hashelő js-t, de ez esetben a lebukás esélye nagyobb)

Jelenleg a pl. cloudflare elvileg megtehetné, hogy az összes rajta átfolyó jelszót lementi. Ha a jelszavak hashelve mennének át, akkor csak aktív javascript módosítás után.

Ja értem. Ha kizárjuk a MITM módosítást, akkor valóban lehet értelme.
Ekkor ha:
- találunk clear textben jelszót, akkor állíthatjuk hogy a jelszavunk nincs biztonságban, ha a csatornát 3rd party dekódolni tudja
- ha nem találunk clear textben jelszót, akkor semmit sem tudunk jelszavunk biztonságáról

Biztonság az nem 0/1 skálán mozog. Nem is olyan régen még standard volt, hogy titkosítás nélkül, http-n utazik a jelszó.

Ha kliens oldalon hashelődik a jelszó, akkor biztosak lehetünk benne, hogy nem clear text-ben (vagy md5-el hashelve) tárolódik a szerveren, egyébként csak meg kell bízni a szolgáltatást nyújtó cég becsület szavában.

Igazából nem látom hátrányát, hogy így a kliens oldalon hashelődjenek a jelszavak. (max egy kis extra cpu tekerés bejelentkezéskor)

"Ha kliens oldalon hashelődik a jelszó" -> ebben soha nem lehetünk biztosak (korábban írtam miért), tehát a mondat második feléről sem tudunk semmit
"egyébként csak meg kell bízni a szolgáltatást nyújtó cég becsület szavában." -> így is csak ennyit tehetsz, ugyanis ő bármikor cserélheti a szkriptet

"Igazából nem látom hátrányát, hogy így a kliens oldalon hashelődjenek a jelszavak."
Azért a sémán kicsit változtatni kell. Mert akkor a szerver oldalon hashB(hashA(jelszó,saltA),saltB),saltA,saltB lesz. A kliens oldalnak el kell küldeni saltA-t, hogy tudja generálni hashA(jelszó,saltA)-t és elküldeni a szervernek. Ezzel persze nem zártuk ki, hogy 3rd party ne tudjon belépni a szolgáltatásba, mert hashA(jelszó,saltA)-t ismerheti a támadó, ami elég az azonosításhoz, de tény hogy magát a jelszót, így nem látja és nem tudja felhasználni esetleg más helyen. Ha még bonyolítjuk és egy nonce-t is keverünk hozzá (és MITM módosítás lehetőségét kizárjuk), akkor még azonosításra sem tudja később felhasználni.

De hiába is ez az értekezés, mert minden a szolgáltatást nyújtó cégen múlik.

A szerveroldalon tárolhatod akárhogy a jelszót, meg a kliensen is lehet próbálkozni, de onnantól, hogy egy csomóan elmentik a kedvenc appjukban, már veszett történet bármi. Levelező fiók fronton a következőket láttuk:

- Jött a klasszikus dictionary próbálkózás, ahol mondjuk az alma@ fiókba az alma és alma123 szerű jelszavakkal próbáltak, és persze ügyes felhasználók sikerült is belépni. Láttunk olyan szervert, ahol a levelezést beállítóknak sikerült eleve ilyen remekül felvenni a jelszavakat. Aztán kaptak jelszópolicyt a nyakukba, illetve a rossz jelszavas fiókok letiltását, mert anélkül ezek szerint nem megy.

- A legnagyobb a sláger a kliens appokban tárolt jelszavak kinyerése és valamilyen zombigépekről rögtön utána a spammelés indítása. Gondolom a böngészős jelszavakat ugyanúgy kigyűjtik, ha az ember belementi, mint egy levelező kliensbelit. Innentől maga a kód és a jelszótárolás a feje tetejére is állhat, akkor is meg fogják szerezni a támadni szándékozók és pont a kliensről.

Hash ügyben leírták, hogy kevés hash-elve küldeni a jelszót, illetve nem szerencsés. Jelenleg ott járunk, hogy egy salted sha512-nél gyengébb, de lehet már az is, elég hamar visszafejthető. Látok olyan levelező szervert is, ahol DES-től (igen) kezdve van mindenféle jelszó hash. Hiába írtak a felhasználóknak, akkor esetleg pattintsanak egy új jelszót, mert jó lenne nem a 10+ éveset használni, a 200+ kövületből olyan 10-en reagáltak a 2.-3. email környékén (látszott a hash változás, meg a módosítás ideje).

És mi van azokkal az oldalakkal, kötelező jelszó változtatás van és nem engedi hogy olyan jelszót adj meg amit már egyszer használtál vagy hasonlót sem. Ezt a HASH-ből elvileg nem tudnák megmondani, akkor most ezeknél plain text-ben is eltárolják a jelszót?

Miért ne tudnák? Megjegyzik az előző N darab jelszavad hash-ét, a jelszóváltáskor meg végigfutnak rajta és megnézik, ugyanazzal az algoval/salttal/beállításokkal ugyanarra mappel-e az új jelszó...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

hasonlót sem

Annál jogos :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem tudok olyan publikus szolgáltatásról, ami erre figyelne.
Nyilván ez már túl nagy versenyhátrányt jelentene a konkurenciával szemben.

... és ehhez tényleg kéne plaintextben a user összes korábbi jelszava...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Jártam már így: a jelszóban kisbetű-nagybetű váltás: nem jó. Az utolsó néhány ("logikailag" egybefüggő) karakter az elejére: nem jó.
Hogy ez hol volt, nem tudom, de elég régen volt, azóta már lehet, hogy ott is jó.

Persze, de ilyet tipikusan csak az előző jelszóhoz képest néz, márpedig ha megváltoztatod a jelszavadat, akkor az előző jelszót is bekéri, így tudni fogja hozzá hasonlítani...

Ah, mondasz valamit :)
Egyébként nem emlékszem már, hogy csak az előzőhöz nézte-e, hogy hasonló, vagy többhöz is.

Na akkor sorban:
* lentebb már megbeszéltétek, hogy semmi értelme nincs, mert innentől kezdve az auth tokened a hash lesz és simán működik a pass-the-hash (lásd még: Windows-os authentikáció)
* ha ezt te az oldal _forrásában_ akarod megnézni, akkor alaphangon meg kell oldanod a megállási problémát (megáll-e egyáltalán a JS kód, ami a form submitkor lefut) és fel kell ismerned _minden_ hash algoritmust (md*, sha*, bcrypt, ...), kapcsolódó módszert (salting, nonce használata, ...), hash reprezentációt (bináris, hexa ASCII, ...) stb. (sok sikert)
* ha mondjuk a kicsit vállalhatóbb megoldást csinálod és a form submitjakor kezded figyelni, hogy az elküldött form-on van-e jelszó mező, aminek az értéke szerepel-e a mezők között... már előrébb vagy, de ezt is triviális átvágni (pl. hozzácsapom a jelszót a usernévhez és kivágom a jelszó mezőt valamelyik event handlerben)

És ezzel az egésszel annyit értél el, hogy minden belépéskor kapsz egy figyelmeztetést, hogy jajúristenmindnmeghalunkplaintext!!!négy! (pl. hupolni se tudnál :( ), mert én pl. nem is tudnék mondani olyan oldalt fejből, ahol ne a plaintext jelszó menne át (illetve egyet igen, valamelyik géniusz kitalálta, hogy egy HTTPS felett kiszolgált oldalon zseniális lesz az oldal forrásában kiküldeni egy RSA kulcsot, amivel lekódolja a kliens oldali JS a jelszót submitkor - már ha lefut, mert a plaintext jelszót is elfogadja a rendszer, de még ha nem is fogadná el, akkor sincs semmi értelme, mivel 1) fix kulcsot használ és 2) HTTPS felett megy, tehát aki a plaintext jelszót látta volna, az tudja módosítani a kulcsot, mielőtt kiadja a sajátjára és tudja a plaintext jelszót is MITM-özni... de gondolom valaki jó sokat fizetett ezért a feature-ért, hogy ki lehessen pipálni, hogy de milyen ügyes crypto-t használ a rendszer...).

Szerk.: sőt, kifejezetten káros is lehet a biztonságra, mivel innentől kezdve nem tudnál betartatni a jelszó erősségére vonatkozó előírásokat.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Lentebb is meg lett beszélve, hogy lenne értelme: passzív MITM ellen véd, illetve a cég így bizonyíthatná, hogy nem clear text-ben tárolja a jelszavakat.

> sőt, kifejezetten káros is lehet a biztonságra, mivel innentől kezdve nem tudnál betartatni a jelszó erősségére vonatkozó előírásokat.

Ezt (remélhetőleg) minden oldal eddig is kliens oldalon végezte, így nem lenne változás.

Idézet:
passzív MITM ellen véd,

Ez a megtörik a proxy-t use case? Ha igen, akkor továbbra sem védett semmi ellen, mert a tényleges auth token ott van a támadó kezében.

Idézet:
illetve a cég így bizonyíthatná, hogy nem clear text-ben tárolja a jelszavakat.

Ez az egyetlen "előnye" (csak vedd hozzá az _implementációval_ járó összes hátrányt)...

Idézet:
Ezt (remélhetőleg) minden oldal eddig is kliens oldalon végezte, így nem lenne változás.

Wut? És a kliens oldal küldött egy flaget, hogy "égre-földre esküszöm, hogy igaz minden előírás a jelszóra" és a szerver ezt (értsd: felhasználói inputot) simán elfogadta? Vagy ezt így hogy?

Remélhetőleg kliens oldalon azonnali feedbacket adott a usernek és elmondta, mi a baj, de utána a szerver leellenőrizte és nem hitt el semmit bemondásra a kliensnek. Mert amelyik oldal _bármit_ elhisz bemondásra, az máshol is el fog, és törhető lesz.

(de egyébként is: valaki linkeljen már egy oldalt, amelyik jelszavakat kliens oldalon hashel)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Ez a megtörik a proxy-t use case? Ha igen, akkor továbbra sem védett semmi ellen, mert a tényleges auth token ott van a támadó kezében.

Az adott oldalra valóban beléphetnek, de hashelés nélkül az összes oldalra beléphetnek, ahol az user ezt a jelszót használta. Szerintem nyugodtan feltételezhetjük, hogy az userek 90+%-a ugyanazt a jelszót használja a legtöbb oldalra. A jelszó hashelt tárolásának is ez az egy oka van.

> Wut? És a kliens oldal küldött egy flaget, hogy "égre-földre esküszöm, hogy igaz minden előírás a jelszóra" és a szerver ezt (értsd: felhasználói inputot) simán elfogadta? Vagy ezt így hogy?

Ha valaki gyenge jelszót akar használni, és ezért hajlandó a kliens oldali javascriptet megváltoztatni...hát legyen. Egyébként használhatja "1q2w3e4r5t" -t is jelszónak ami valószínű megfelel a legtöbb oldal előírásának mégis egy dictionary based attack esetén ott lesz az első 50 próbálkozásban.

Idézet:
Az adott oldalra valóban beléphetnek, de hashelés nélkül az összes oldalra beléphetnek, ahol az user ezt a jelszót használta. Szerintem nyugodtan feltételezhetjük, hogy az userek 90+%-a ugyanazt a jelszót használja a legtöbb oldalra. A jelszó hashelt tárolásának is ez az egy oka van.

Fasza, de eléggé szűk a köre a hash algóknak (és jó esetben a randombt.hu nem talál ki saját kriptót... ugyebár). Vagyis ha ugyanazt a jelszót használja, akkor lesz kb. 5 kategóriányi oldal, amik közül az egyik kategóriába (ahol ugyanaz a hash van) a törött proxyból kiszedett "már-nem-jelszó-de-újra-jelszó"-val be lehet lépni.

Ha a leakelt jelszavak újrafelhasználása ellen akarsz védekezni, akkor használj jelszókezelőt és mindenhol random jelszót. Vagy mindenhol TFA-t/MFA-t. Vagy valami id szolgáltatót (google, facebook, ...).

--

Egyébként abban kiegyezhetünk, hogy a G legalább időnként figyel arra, hogy távolról védhető legyen az auth rendszere, igaz? Akkor ők miért plaintext jelszót küldenek loginkor, ha "dehátahasheltbiztonságosabb"?
És továbbra is: tudtok akár csak egy oldalt mondani, ami kliensoldalon hasheli a jelszót?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Azert nem ugyanaz a salt vagy/es a nonce. Nem kell tobb hash algoritmust hasznalni ahhoz, hogy kulonbozzon.

Idézet:
Nem kell tobb hash algoritmust hasznalni ahhoz, hogy kulonbozzon.

De, különben az egyetlen különbség a salt lehet. Így meg oda kéne adnod a fiók-specifikus salt-ot a kliensnek, ezzel leakelve azt az infót, hogy az a fiók használt -> csökkent a biztonság (Innentől ügye nem állíthatod, hogy hibás felhasználóinév _vagy_ jelszó) [vagy site-specifikus salt, de az meg bad practice, mert az így leakelt tábla utána (site-specifikus, de akkor is) szivárvány táblával törhető]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ezt (remélhetőleg) minden oldal eddig is kliens oldalon végezte, így nem lenne változás.

Hát, meg is baszhatjuk azt a rendszert, ami kliens oldalon validál csak...

szerintem meg csak gyujtogetik, esetleg eladjak.
webmail-eken talalkoztam olyannal, hogy egyszercsak elkezdtek spammelni 1-1 accountrol minden elojel nelkul, majd a logokat visszakeresve kiderult hogy 2-4 hettel korabban beleptek mar egy orosz ip-rol egyszer es 1db teszt mailt kuldtek, benne az user jelszavaval. ott is ez lehetett, hogy az egyik banda hozzafereseket gyujtott, majd eladta azt egy masiknak, aki hetekkel kesobb elkezdett spammelni vele (tok mas ip-rol es orszagbol).

esetleg egy biztonságosabb honeypot projekt, ami még statisztitákat is gyárt, kereshető sessionokkel.
https://haas.nic.cz/

https://haas.nic.cz/session/91975348/672a2d68a86f/ itt egy példa session az elmúlt napokból

Gondoltam, ezt kipróbálom. Be is jött egy ilyen kétszer is:

https://haas.nic.cz/session/117852416/57a45ffa617d/

ez amugy mukodik nektek? egy orat szoptam mire minden dep-jet kitalaltam, azota ezt irja connectnel:
ssh: connect to host haas-app.nic.cz port 10008: Connection refused
es tenyleg, nem lehet arra a portra csatlakozni, megneztem tobb geprol is.

Nekem is elment rá egy csomó időm, mire sikerült működőképessé tenni, de ahogy elnézem, most nem stimmel valami, mert a weboldalon én teszt belépésem az utolsó, amit még éjfél után csináltam. Azóta semmi.
Most tettem egy próbát megint: szépen be is engedett, tehát az a rész működik. Kiváncsi leszek, a weboldalon is meg fog-e jelenni.

nekem kesobb volt hogy beengedett, de a weboldalon az se latszik... amugy se tunik tul securenek ez az egesz (pl hibanal kidobja a stack tracet a hackernek, meg pl. sshpass utilt hivja meg execve-el), ennel szerintem jobbat irok egy delutan.

Már látszik a próbálkozásom a weboldalon. Nehéz elhinni, hogy több, mint 12 órája nem volt egy sem.
Van egy VPS-em a gyereknek, a haverokkal szoktak minecraftozni. Percenként minimum 1 próbálkozás van.

Már látszik a próbálkozásom a weboldalon. Nehéz elhinni, hogy több, mint 12 órája nem volt egy sem.
Van egy VPS-em a gyereknek, a haverokkal szoktak minecraftozni. Percenként minimum 1 próbálkozás van.

ennel szerintem jobbat irok egy delutan

Ó, ismerős életérzés! :D