Egy olyan jelszot szeretnek eloallitani, amivel xy user csak bizonyos ideig johet be, azaz az IP-cim es usernev alapjan egy az adott oraban hasznalhato jelszot general.
Az alabbira gondoltam:
sub a {
my($ipaddr, $username) = @_;
my $secret = '2km hosszu kozos titok, amit csak a jelszot generalo / ellenorzo program ismer';
@c = (0..9, 'A'..'Z', 'a'..'z');
my $s = '';
$t = time();
$t -= $t % 3600;
$digest = sha256_hex(sha256_hex($ipaddr . "+" . $username . "+" . $t . "+" . $secret) . $secret);
$digest = hmac_hex($ipaddr . "+" . $username . "+" . $t, $secret, \&sha256);
for($i=0; $i<(length $digest)/4; $i++) {
$a = substr($digest, $i*4, 4);
$s .= $c[hex($a) % @c];
}
return $s;
}
A kerdes az, hol van a gyenge pont (ha van) az algoritmusban?
Hozzászólások
Azt jól írod, hogy a jelszó csak az adott órában használható, tehát pl. ha óra:55-kor generálod, akkor csak 5 percen keresztül. Ez a cél?
Az md5sum biztos olyan, a sha256-ot nem tudom, hogy ha két különböző file-nak azonos az md5-je, akkor azonos suffixet hozzáfűzve mindkét fájlhoz továbbra is azonos lesz az md5. Ha a sha256 is ilyen, és a támadó ismeri az algoritmust (a titok kivételével) (például lenyomozta hogy ki kódolta le és itt a hup-on megtalálta ezt a topikot), akkor elegendő olyan IP-címhez hozzáférnie, usernevet megadnia, és közeli időcímkét találni, melyre ezek összefűzése az eredeti jelszóhoz tartozó ilyen értékek összefűzésével megegyező sha256-ot ad, a secret ismerete nélkül is tudja hogy a digest azonos lesz. Persze ez se könnyű feladat.
A sha256 dupla alkalmazása szerintem nem szokványos dolog, úgy tippelném hogy nem ismeri senki sem igazán a viselkedést. Csak példa: a DES kódolás azt tudja, hogy ha kétszer egymás után alkalmazod, gyengébb titkosítást kapsz mintha csak egyszer.
A titkosítás iszonyatosan nehéz témakör, én sem értek hozzá. Nagyon nem mindegy, hogy mennyire kritikus a rendszer amit készítesz. Ha arról van szó, hogy a 15 éves kisöcsi ne férjen hozzá a 16-os korlátozású filmekhez, akkor szerintem bőven jó amit csinálsz. Ha banki rendszer védelméről, akkor felejts el minden saját gondolatot, kizárólag a szakirodalom tanulmányozása és egy jól bevált ismert algoritmus implementálása jöhet szóba. A kettő között persze nagyon széles a skála...
akkor csak 5 percen keresztül. Ez a cél?
ez inkabb mellekhatas, de egyelore elfogadhato.
elegendő olyan IP-címhez hozzáférnie, usernevet megadnia, és közeli időcímkét találni, melyre ezek összefűzése az eredeti jelszóhoz tartozó ilyen értékek összefűzésével megegyező sha256-ot ad, a secret ismerete nélkül is tudja hogy a digest azonos lesz. Persze ez se könnyű feladat.
Induljunk ki abbol, hogy az IP-cim es a login nev ismert, az ido az adott. A feladat olyan algoritmus fabrikalasa, amivel keszitett jelszot odaadhatsz xy usernek, amivel be tud jonni az adott oraban (vagy +1 oran keresztul), de nem tudja az ugyanehhez az IP-cimhez + loginhoz tartozo kovetkezo orai jelszot kitalalni, sem pedig egy masik loginhoz tartozo ugyanazon orara ervenyes jelszot.
Collision-t talalni vegul is lehetseges, de azert nem md5-ot vagy sha1-et hasznalok, hanem sha256-ot, hogy ez egy kisse nehezebb legyen. Viszont talan megsem csak ennyi a tamado feladata, mert a jelszo ellenorzese ugy tortenik, hogy a program maga allitja elo az ervenyes jelszot ugyanazon algoritmussal, es osszehasonlitja az igy generalt jelszot azzal, amit user xy megad.
Tehat nem az a tamado feladata, hogy collisiont talaljon (mert nem 2 hash-t hasonlitok ossze), hanem a tenyleges jelszot kell kitalalja.
Diktatorok kezikonyve
Ha nem a rendszerbe belépni kívánó user, hanem a rendszergazda kütyüjén generálódik az adott időhöz való jelszó, akkor teljesen felesleges minden algoritmus. Egyszerűen teljesen véletlen jelszó-érvényességi kör párokat kell generálni, és egy táblázatban tárolni a szerveren. A rendszergazda meg odaadja a usernek amit jónak lát. Minek ide trükkös algoritmus?
maceras, kenyelmetlen (legalabbis az en esetemben):
#1: bar valoszinuleg tudom elore az osszes login nevet, de ez nem feltetlen van igy. Akkor pedig nehez elore elkesziteni az osszes lehetseges jelszot x idore elore.
#2: idorol idore ujra generalni kell jelszavakat, egy csomo regit es nem hasznaltat pedig torolni
#3: ha a jelszavakat adatbazisban tartom (ok, egy pici sql szerver nem nagy durranas, de megis), az noveli a komplexitast, ami nem jo
#4: en ugyan tudok generalni jelszavakat, de mi van, ha nem en menedzselem a jelszavak szetosztasat, hanem egy olyan szemely, akinek ez valamiert nem jarhato/kellemetlen/kenyelmetlen. O csak annyit tud, hogy lefuttat egy parancsot, ami kikopi a jelszot.
Diktatorok kezikonyve
Úgy értettem, hogy a szolgáltatást futtató szerveren van az adatbázis, hogy ki mikor léphet be és a hozzá tartozó kulcs. Vagy egy webalkalmazás (amit csak az adminisztrátotok érnek el), amibe belépve létre tud hozni új hozzáférést a rendszerhez pontosan annyi adat felvitelével, mint az általad adott algoritmussal.
Azt is megnyered vele, hogy a rendszerben végzett minden művelet visszakereshető esetleges visszaélés esetén. Vagy pont ennek az elkerülése a cél? :-)
ez is egy lehetseges megoldas, ld. lentebb, de komplikalja az eletemet. Szerintem a jelenlegi verzio egyszerubb.
Diktatorok kezikonyve
"#3: ha a jelszavakat adatbazisban tartom (ok, egy pici sql szerver nem nagy durranas, de megis), az noveli a komplexitast, ami nem jo"
Ez különösen akkor aranyos, mikor elkezdenek elszaporodni a tárolt adatok különféle struktúrában és a végeredmény komplexebb lesz, mintha az elején legalább egy SQLitet használtak volna.
Tudnék sorolni elrettentő példákat dögivel.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
ez egy nagyon jol definialt feladat, ahol nincs szukseg strukturakra, es pont az 'a leheto legegyszerubb, de meg biztonsagos legyen' jegyeben nincs benne sql.
Diktatorok kezikonyve
Magyarul, hiába mondják neked, hogy szar, amit akarsz, inkább picsogsz tovább, hogy de ezt meg azt nem akarsz, holott a feladathoz kellene.
További sok szerencsét.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
te szivsz valamit vagy alvajaras kozben forumozol? LOL...
Diktatorok kezikonyve
Miert is szar?
Csatlakozom az előttem szólóhoz abban, hogy a titkosítás témakör nehéz, biztosat állítani szakismeret nélkül lehetetlen. És én sem vagyok szakértő.
Viszont annyit érdemes lenne végiggondolni, hogy mi ellen véd ez a megoldás?
* egyedi algoritmus, tehát a támadó nem tudja, hol kezdje a támadást -> Security by obscurity, olvas utána, hogy szerinted érdemes-e vagy nem
* A jelszó plaintext közlekedik, tehát ellopható. Emiatt egyszer használatos legyen a jelszó, így ha ellopják is, akkor sem tudnak belépni vele. Ezzel az a baj, hogy "Man in the Middle" támadás ellen nem véd, a felépülő kapcsolatba bárki belekontárkodhat
* A jelszó titkosított és hitelesített csatornán közlekedik, de a helyi (kliens) gépen lévő keylogger ellen védeni kell. Ha a helyi gép kompromittálódott, akkor a helyi gépen futó jelszó generáló algoritmus is kompromittálódhatott, tehát megint csak oda a biztonság.
* A helyi (kliens) gép biztonságosnak tekinthető, és ezen fut a jelszó generálás, illetve az authentikált és titkosított kapcsolat. Ebben az esetben miért ne lenne elég egy "sima" ssh privát kulcs alapú kliens authentikáció? Mitől jobb a jelszó generálás?
* Külön kütyün fut a jelszó generálás, a kliens gép pedig authentikált (a szerver authentikálja magát publikus/privát kulccsal) és titkosított csatornán lép be. De a kliens gép nem számít megbízhatónak, ezért kell a külön kütyü a jelszógeneráláshoz. Ebben az esetben viszont a szerver authentikációja nem lesz megbízható, mert az authentikációt végző gép maga nem megbízható.
Akárhogy is nézzük minden végiggondolásnak az a vége, hogy amennyiben a kliens (titkosítást és authentikációt végző) gép nem megbízható, akkor a kommunikáció sem lesz az. Ha viszont megbízható, akkor a kulcs alapú authentikációnál nem nagyon van jobb. Ezért elméleti szempontból felesleges az ilyen token-szerű jelszó generálás. Persze ettől még egy kicsit nehezítheti a támadó dolgát a gyakorlatban.
Security by obscurity
ha az Interneten publikalsz egy algoritmust, akkor hol van az "obscurity"? :-)
A jelszó plaintext közlekedik, tehát ellopható
nem clear-ben megy a jelszo
de a helyi (kliens) gépen lévő keylogger ellen védeni kell.
ez kevesse szempont. Nalam a user, akinek odaadom a jelszot, potencialis tamado is egyben. A feladat az, hogy 1 orara odaengedni 1 bizonyos eroforrashoz, aztan soha tobbe. Hacsak nem kap egy uj jelszot.
A helyi (kliens) gép biztonságosnak tekinthető, és ezen fut a jelszó generálás,
nem-nem, mert akkor xy barmikor bejohet, de ezt nem akarom, ld. fentebb.
Külön kütyün fut a jelszó generálás [...]
1 kutyun fut a jelszo generalas, 1 masik kutyunk a jelszo ellenorzese, de nem hiszem, hogy ettol az utobbi gep/kutyu ne lenne megbizhato. A bela user egy jelszoval fordul a kutyu fele, a kutyu meg eldonti, hogy johet vagy sem.
a kliens (titkosítást és authentikációt végző) gép nem megbízható,
bocsanat, ezt eddig nem mondtam vilagosan, de a jelszot generalo gep (amihez nem fer hozza xy user), csak en, ill. a jelszot ellenorzo gep megbizhato.
Az meg szerintem reszletkerdes, hogy jelszo vagy kulcs. Mivel a hozzaferes ad-hoc jellegu, igy a kulcsok hasznalata nagyon megbonyolitana a rendszert, es ezert lenne serulekenyebb.
Diktatorok kezikonyve
Félreértettem, arra asszociáltam, hogy ilyen kulcstartó-token szerű belépést akarsz implementálni.
eppenseggel az is mukodhetne, csak akkor meg kutyuazonositokat is generalni kellene, azokat nyilvantartani, lejaratni. Macera :-)
Diktatorok kezikonyve
"nem clear-ben megy a jelszo"
És maga a csatorna titkosított?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
https + radius, ha erre gondoltal
Diktatorok kezikonyve
Nem értem mire fel ez a bonyolult eljárás.
Egy N karakteres véletlen jelszó nem elég?
Szerver oldalon generálod, ott is ellenörzöd.... nem értem mire az a nagy felhajtás a bele kódolt dolgokkal.
A szerver oldalon elég egy adatbázisban eltárolni a jelszót (titkosítva), az IP-t, a usert, meg a lejárati időt.
Aztán ha mindd a 4 azonosítási elem stimmel, a user bejöhet.
A jelszó meg pl. sms-ben kiküldhető, ha egy független csatornát is bele akarsz vinni a dologba.
Egy N karakteres véletlen jelszó nem elég?
de, eleg, es pont ez van most: egy N karakteres jelszo.
A szerver oldalon elég egy adatbázisban eltárolni a jelszót (titkosítva), az IP-t, a usert, meg a lejárati időt.
Aztán ha mindd a 4 azonosítási elem stimmel, a user bejöhet.
Ez is lehetseges, de ez csak bonyolitja az eletem azzal, hogy adatbazis kell hozza, valakinek karban kell tartani az ip+login+pw+ttl kombot. Jelenleg csak egy parancsot kell futtatni, ami ha fuj, ha szakad, megmondja a jelszot.
Diktatorok kezikonyve
Ehelyett ikább megbízol a kliens álltal adott jelszóban. Mert ugye gyakorlatilag csak egy algoritmussal akarod ellenőrizni....
Egyébként meg kinek mit kell karbantartani az adatbázison?
Generáláskor belekerül a jelszó, egy cron job meg 5 percenként törli a lejárt jelszavakat.
Kb ennyi.
szerk: az idő rész nem hibás? Ha óra 59 perckor generálod a jelszót, akkor 1 perc múlva már nem lesz jó.
Vagy tévedek?
Ha egy adatbazisbol veszed a jelszot, akkor is a kliens jelszavaban bizol meg. Azt meg nem latom (ill. pont azt varom, hogy az algoritmust ekezzetek), mitol gyengebb az algoritmussal ellenorzes, mintha egy elore generalt jelszoval vetned ossze?
A torles valoban egy cron muve, de a generalashoz egy (pl. webes) admin felulet kell, amivel maris egy uj komplex elemet hoztunk be (oda szinten authentikalni kell a jelszokiado embereket, securizalni az alkalmazast, stb).
Az ido bug/feature-t jol latod, ez most mellekhatas, ami belefer a specifikacioba. De az nem tilos, hogy a vegen jobb legyen a megoldas...
Diktatorok kezikonyve
"generalashoz egy (pl. webes) admin felulet kell"
Valamivel most is generálod....
"Ha egy adatbazisbol veszed a jelszot, akkor is a kliens jelszavaban bizol meg"
Nem bízok meg benne. Én generálom, eltárolom és elküldöm neki. Ha amit visszaküld egyezik azzal, amit én tárolok, akkor örülünk.
A te módszered viszont az, hogy kapsz egy jelszót, amit egy algoritmussal ellenörzöl, és ha az ellenörzésen átmegy, akkor beengeded. Nincs kontroll, hogy te valóban kiadtad -e bárkinek azt a jelszót.
Abban a pillanatban, hogy az algoritmus bármilyen ok miatt kiszivárog/visszafejtik stb, már tetszőleges jelszó generálható belépésre úgy, hogy a jelszó ellenörző szervert nem kell kompromitálni.
Nyilván a védendő rendszer kritikusságától függően ez a megoldás még elégséges lehet. (Pl. egy noname kis cég ftp site-jának védelmére.)
"Abban a pillanatban, hogy az algoritmus bármilyen ok miatt kiszivárog/visszafejtik stb, már tetszőleges jelszó generálható belépésre úgy hogy a jelszó ellenörző szervert nem kell kompromitálni."
Van benne egy secret, ami ha nem kerül ki, elvileg nem lehet gond.
Én inkább arra lennék kíváncsi, hogy hogy kerül a jelszó a userhez?
pl. telefon, sms, email, skype, whatever...
Diktatorok kezikonyve
Abban a pillanatban, hogy az algoritmus bármilyen ok miatt kiszivárog/visszafejtik stb,
ez mar kiszivargott, de nem az algoritmus ismeretlensegere epitek, hanem a korrektsegere (felteve, hogy az). De az igaz, ha a secret kiszivarog, akkor tetszoleges jelszo generalhato vele.
Diktatorok kezikonyve
Megmondom, mit csinál a Forms Authentication, amit nagyon sokan használnak. Csinál egy ticketet, amiben benne van a júzer neve, a ticket lejárati ideje, meg egyéb tetszőleges adatok, pl. csoporttagságok. Ezt szerializálja, egy kulccsal titkosítja, és ezt adja ki a kliensnek pl. cookie-ban. Pár száz bájtra kell gondolni, ember nem jegyzi meg, de cookie-ban és URL-ben is bőven elfér. Amikor visszajön a kliens, be tudjuk olvasni, hogy ki ő, és érvényes-e még a ticket. Amíg a kulcs biztonságban van, és kellőképpen nagy, addig egy kliens nem képes ticketet módosítani/előállítani, sőt, elolvasni sem tudja a tartalmát. Ha más nem lopja el a ticketet, akkor feltörhetetlen a rendszer, ha ellopja, akkor is csak a másik júzert lehet megszemélyesíteni adott ideig. Olyan is lehetséges, hogy a lejárat közelében automatikusan meghosszabbított ticketet küldünk ki, de e most mellékes. Nagy előnye, hogy szerver szempontjából állapotmentes, legalábbis amíg nem változik meg a kulcs.
--
ez szep es jo, de en csak egy jelszora tamaszkodhatok, nem pedig egy komplex adatszerkezetre. Mert cookie-ban ugye elfer, de user belanak ezt be kell gepelnie, ill. meg ha copy-paste-tel is, nem biztos, hogy a jelszo mezobe belefer annyi adat.
Diktatorok kezikonyve
PHP-ban is lehet stringbe szerializálni, meg vissza. Hogy kapja Béla a jelszót? Ha egy webes felületen belép, visszakapja cookie-ban, URL-ben. Vagy megkaphatja emailben is az URL-t, amire rögtön rákattint. Szóban/SMS-ben már nem lehet ilyet közlekedtetni, az biztos.
Kb. minél rövidebb a titok, annál kevésbé biztonságos. Tudósok százai foglalkoznak ilyenekkel, és biztos sírnak, ha olyat látnak, hogy te egy hash értékének csak a negyedét veszed figyelembe. Ha engem kérdezel, _talán_ lehet ilyet, csak akkor minimum építs a rendszerbe védelmet brute force ellen, és sűrűn cserélgesd a titkos kulcsot.
Én nem vagyok szakértő, de a következő a megérzésem. A normális jelszavak általában azért lehetnek biztonságosan rövidek, mert teljesen véletlenszerűek. Ha te algoritmussal generálsz valamit, akkor valaki más tud írni egy algoritmust, ami kitalálja a titkos kulcsot 1-2 elkapott jelszóból. Ezért kell sok száz bites titkokban utazni. Ha te kevés bitet használsz, és az is generált, akkor bajban vagy.
Mondok egy példát, enyhén kapcsolódik. Egyszer egyedi, de nem sorban egymást követő azonosító számokat kellett generálnom. Gondoltam, hogy hash-elem az adott időt, és veszek belőle x db bitet. Bőven a teljes értékkészlet elérése előtt duplikálódni kezdtek a generált értékek. Lásd születésnap paradoxon.
--
na ez az. Nem egy hagyomanyos php, cgi, jsp, asp, ... weboldalrol beszelunk, amit a kedvemre faraghatok.
Kb. minél rövidebb a titok, annál kevésbé biztonságos.
nyilvan
Tudósok százai foglalkoznak ilyenekkel, és biztos sírnak, ha olyat látnak, hogy te egy hash értékének csak a negyedét veszed figyelembe.
talan megsem. Hanem minden 4 karakterbol (=2 byte) kepezek egy numerikus hash-t (ami majd eredmenyez 1 db karaktert a jelszoban), hogy a jelszo azert megis emberi meretu legyen, es igy lesz 16 karakteres. Szerintem ez nem olyan rossz...
csak akkor minimum építs a rendszerbe védelmet brute force ellen, és sűrűn cserélgesd a titkos kulcsot.
az elobbire biztos ki lehet talalni valamit, viszont az utobbit nem tervezem. Akkor mar inkabb a zwei es masok javasolta modszer. A titkos resz (=secret) eleg hosszu, azt nem fogod kitalalni.
Ha te algoritmussal generálsz valamit, akkor valaki más tud írni egy algoritmust, ami kitalálja a titkos kulcsot 1-2 elkapott jelszóból.
generalj par jelszot, es probald kitalalni belole a titkot. Ugye a digest algoritmusokban az (is) poen, hogy a digest-bol (elmeletileg) nem tudod visszafejteni a kiindulo erteket, es igy a titkot sem.
Ezért kell sok száz bites titkokban utazni. Ha te kevés bitet használsz, és az is generált, akkor bajban vagy.
valoszinuleg kevered a szimmetrikus titkositast es a digest-et, de annyi valoban igaz, hogy a titoknak nem szabad kitalalhatonak lenni...
Gondoltam, hogy hash-elem az adott időt, és veszek belőle x db bitet.
itt inkabb az algoritmust mondanam a leggyengebb lancszemnek :-)
Lásd születésnap paradoxon.
na, ez mar langyosodik. De mi van akkor, ha 2x is hash-elek?
Diktatorok kezikonyve
Biztonságosabb lesz.
Egész jó összefoglaló: http://stackoverflow.com/questions/348109/is-double-hashing-a-password-…
Elsőre nekem korrektnek tűnik.
Az IP cím alapú védelem viszont elég gyenge láncszem, ha valaki hozzáfér a másik személy hash-éhez, akkor már esélyes, hogy az IP címét is tudja spoofolni - miért nem kérsz egy 4 karakteres PIN-t is a felhasználótól?
Jogilag is jobban be lennél védve, a PIN titokban tartása a felhasználó felelőssége, ez evidens, ellenben a hash titokban tartásával.
Az időbélyeget használhatnád kvázi public saltként, akkor megkerülöd ezt a gyengeséget, hogy csak adott órára tudsz kulcsot adni, a biztonságon pedig nem ront.
nincs benne IP-cim alapu szures/vedelem. Amint fentebb irtam, hash-ek csak a programon belul vannak, de a bemenet ill. a kimenet sima jelszo.
Az időbélyeget használhatnád kvázi public saltként,
hogyan?
Diktatorok kezikonyve
a., A jelszó mégis tartalmaz egy IP cím lenyomatot, miért?
b., Valahogy így:
a., A jelszó mégis tartalmaz egy IP cím lenyomatot, miért?
mert tobb szerver van, es a user csak a megadott egyre mehet be. Az IP-cim nelkul akar az osszesre bemehetne, ami biztonsagi incidenssel egyenerteku...
b., Valahogy így:
hmmm, azert furcsa lesz igy a jelszo. Jelenleg 16 elegge random karakter az eredmeny, ami igy a timestamp utan kb. 6-7 karakterre rovidul az effektiv jelszo (ha marad a 16 hossz). Alszom meg ra egyet...
Diktatorok kezikonyve
a., OK, így már világos
b., Tömörítheted bátran az időbélyeget. Pl csak perceket számolsz 2013-tól és 62-es számrendszert használsz (praktikusan A..Z, a..z, 0..9 szimbólumokkal). A lényeg, hogy veszteségesen nem tömörítheted, ahogy az SHA256 hash-sel teszed, hiszen akkor bruteforce-olni kéne.
Mondjuk a bruteforce se rossz megoldás, ha nagyon nem akarod növelni a jelszó hosszát és a hash-t se akarod megtöbb veszteséggel tömöríteni; ha 60 percre akarsz perc alapú elévüléssel hozzáférést adni, akkor legrosszabb esetben is "csak" 60x kell nekifutni az authentikálásnak. Persze ez átlagosan 30x-es overheadet jelent az authentikációban, ami vagy megengedhető vagy nem..
Nem teljesen rossz, de:
- Ha jol latom, itt ujra feltalaltad a HMAC-ot. A megvalositas nem trivialisan rossz, de egy gyors rapillantas alapjan azt sem allitanam, hogy tokeletes. En inkabb a standard HMAC algot hasznalnam.
- Az nem vilagos, hogy mi akadalyozza meg, hogy a tamado bespoofolja a celpont IP-jet, meghivja az alkalmazast es generaljon maganak egy jelszot.
- Nincs elvalasztas az egyes mezok kozott. Pl. a 10.0.0.11-rol jovo "pityu" juzer es a 10.0.0.1-rol jovo "1pityu" juzer jelszava ugyanaz lesz.
--
"You're NOT paranoid, we really are out to get you!"
Van elválasztás, '+' karakter, épp emiatt könnyű volt benézni a kódban. :)
csak most tettem bele, hogy felhivta ra a figyelmet :-)
Diktatorok kezikonyve
- Nincs elvalasztas az egyes mezok kozott.
fixed
igazabol az alabbi tortenik:
user be akar lepni egy szerverre, es megad a szerver https oldalan egy login nevet + jelszot. A szerver ezt a 2 adatot es a _sajat_ IP-cimet kuldi egy radius szervernek. Az authentikalas tehat a radius szerveren tortenik. Elso korben feltelezhetjuk, hogy user nem tudja spoof-olni a szerver IP-cimet, mert nem azonos subneten vannak, akar foldrajzilag is tavol.
A jelszo generalasa 2 helyen tortenik. Egyik a radius szerver (az osszehasonlitas vegett), amirol idealis esetben user nem is tud, hogy letezik. A masik egy cli program, amihez nem fer hozza user, mert pl. egy szamara elerhetetlen gepen fut csak, es o a jelszot mas csatornan, pl. telefon, sms, whatever kapja meg. A jelszo pedig ervenytelenne valik max. 1 ora mulva.
Diktatorok kezikonyve
Ja, hogy az $ipaddr a szervere, ahova a juzer epp be akar lepni. Igy mar ertheto.
Ha feltetelezzuk, hogy a juzer csak a sajat jelszavat tudja lekerdezgetni, es a dupla sha-zast lecsereled rendes HMAC-re, akkor jo lesz.
--
"You're NOT paranoid, we really are out to get you!"
igazabol a user nem tudja lekerdezni a sajat jelszavat, hanem on demand kap egyet. Holnap atdolgozom hmac-ra, kossz a tippet.
Diktatorok kezikonyve
Ami meg esetleg erdekes lehet, hogy hogyan hasonlitod ossze a jelszavakat, mert ha az elso kulonbsegnel megallsz, akkor elvileg mukodhet a timing attack.
--
"You're NOT paranoid, we really are out to get you!"
user megadja a sajat jelszavat, majd eloallitom magam is (=a program), hogy mi kellene, hogy a user jelszava legyen. Ha egyezik jo, ha nem, akkor ujra probalkozhat. Hogyan jon itt kepbe a timing attack?
Diktatorok kezikonyve
Gondolom arra gondolt, hogy lehet olyan eset, hogy több időponttal is stimmelhet a user által megadott digest. Mivel kicsi rá az esély, ez esetben lehetne a usernek kedvezni ha ilyen hiba előállna, és nem a jelenlegi időponttól visszafelé lépkedve generálgatni a szerver oldali digest-et és azzal hasonlítani a user-ét, hanem now()-1h időponttól a jövő felé lépkedve - így ha egyezés lenne, akkor maximum a valóságosnál nagyobb időt kap a user.
További részletek ismerete nélkül én lehet hogy elhagynám az IP infót, mert változhat adott esetben a user címe. Nem ez lesz a gyenge pont valszeg.
Az idő problémát elég lenne 5 perces intervallumokkal megoldani. Vagyis 300-as modulót vonnál ki az időből. Bejelentkezéskor meg lefuttatnád az adott óra minden 5 percére a digest generálást, és összehasonlítanád a user által adottal. (Vagy tetszőleges felbontással, akár perces pontosság és az algo-d 60-szor futna -nem nagy overhead.)
Azért általánosságban merész kijelenteni azt, hogy egy kb 3000%-os overhead nem nagy. :)
Nem ismerem a részleteket, csupán arra gondoltam, hogy az auth rész nem szokott idő kritikus lenni - persze a szerver terhelése nem mindegy.
Ha valaki vissza tudja állítani a szerver óráját (pl. az ntp kérésed eltérítésével), akkor egy régi jelszóval bejöhet.
hmm, ez kevesse sanszos, de akar erdemes lehet nagios-szal figyelni a szerver orajat, es sikitani, ha par sec-nel nagyobb a kulonbseg.
Diktatorok kezikonyve
Nekem egy dolog nem világos - miért kell külön kerberos-t készíteni, pwgen alkalmazással megfejelve? Miért nem jó az ami van? Mármint tikett rendszerű kerberos és a pwgen alkalmazás? *kiváncsiság*
a program 2 helyen futna: a gepen, ami a jelszavakat ellenorzi, es tole "tavol", ahol a jelszavakat generaljak. A Kerberos biletakkal bonyolultabb lenne, imho.
Diktatorok kezikonyve
Ez a két gépes módszer, milyen előnnyel jár?
semmilyennel, hanem azert van 2 gep, mert az authentikacio egy radius szerveren tortenik, es azon fut a program. A masik gep azert kell, mert aki osztogatja a jelszavakat, az nem fer hozza a radius szerverhez. De amugy mehetne az egesz 1 gepen is...
Diktatorok kezikonyve
Jól értem akkor, hogy:
A teljes algoritmus mind a két gépen megtalálható?
igen
Diktatorok kezikonyve
javitottam a perl kodot.
Diktatorok kezikonyve
Fogalmatlanul kerdezem, mert nem tudom, mi a cel: mi a baj a google-authenticatorral? Legalabb 5 fuggetlen nyelvre letezik az implementacioja, ebbol csak 1 Google-fele, ezen felul nyilt es szabvanyos algoritmust hasznal, 30 sec-enkent valtva a kodot. Ma mar nincs olyan eszkoz - a kenyerpiriotot es a mikrosutot leszamitva - ahova ne lenne Google Authenticator applikacio.
Felre ne ertsd, en orulok, ha van valami mas, csak nem biztos, hogy erdemes kitalalni a meleg vizet.
--
Tehat a juzer authorizaciot es authentikaciot is helyezzuk a Google kezebe. Tok jo.
---
pontscho / fresh!mindworkz
errol van szo.
hogyan szabalyozom en, hogy akinek google acc-a van, az mikor es meddig johet be, ill. hogyan akadalyozom meg a csillio google usereket, hogy bejojjenek?
Diktatorok kezikonyve
Mindkettotoknek: a kovetkezo valasz elott keressetek ra, hogy mi az a Google Authenticator. Koszonom.
Tipp: a neven kivul semmi koze nincs a Google-hez.
--