Fórumok
Megoldható-e ,hogy egyszerű és könnyen megjegyezhető jelszavakat használjunk, és mégis megmaradjon a biztonság?
https://sign-el-soft.hu/keygen.html
-------------------------------- Kiegészítés 24.02.09 16:15
Itt nem egy random jelszógenerátorról van szó!
A felhasználó beállítja a saját szabályát, és annak alapján egy algoritmus egy rövid és ezért könnyen megjegyezhető bemenetre, a kívánt hosszúságú és formátumú kimenő jelszót állít elő.
Ugyanarra a bemenetre legközelebb is ugyanazt a választ fogja adni, másik bemenetre egy másikat.
Ha a szabály más, akkor mások a kimenő jelszavak.
Hozzászólások
A jövő nem a jelszóé, hanem az egyéb passwordless megoldásoké (pl SSO)
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @
* Az ilyeneket biztosító oligopol tech-multiké.
Namost alapvetoen nem a jelszoval van a gond; ott csak akkor, ha a stupid user ujrahasznalja a random-forumos jelszavat a bankjanal.
A gond ott van, hogy gyakorlatilag mindenki engedi, hogy random emberek az internetrol tetszoleges szamuszor probalkozzanak belepni vele.
Ha nem lenne tobbmillio probalkozasi lehetosege az attacker-nek, akkor nem lenne gond a 6-8 karakteres jelszo sem.
Ez persze maceras, gondolkodni kell, tamadot azonositani, esetleg egy primitiv ML modellt trainelni, hogy azonositsa per-user, hogy tamado-e vagy sem, meg a szoftverbe geoip limitet rakni ("oroszorszagi korut elott feltetlen engedelyezze az oroszorszagi IP-ket es 2fa-t!"), vagy esetleg VPN-t rogton.
Ezert aztan ma mar ott tartunk, hogy min. 12 karakter, 1 kisbetu, 1 whitespce, 1 spec karakter minimum a szokasos jelszo komplexitas, es persze cracklib-en menjen at, ami egyszeruen nevetseges elvaras az r=1 usertol; 90%, hogy egy post-itre fel van irva a gepe mellett...
https://xkcd.com/936/
Ennek korábban én is bedőltem. Aztán nekiálltam számolni.
12 karakteres jelszó, speciális karakterekkel: 90^12 ~ 2.8e23 variáció.
4 szóból álló passphrase, 7000-es szótárral (nagyjából ezzel a nagyságrenddel szoktak dolgozni a generátorok): 7000^4 ~ 2.4e15 variáció.
A dolog ott bukik el, hogy a passphrase-t nem csak karakterenként lehet törni, hanem dictionary attack segítségével, szavanként (hiszen pont ez a lényege). Persze meg lehet csavarni, spéci szóelválasztó szabályokat alkalmazni, de abból nincs túl sok, és még felszorozva sem éri el a rendes jelszavak nagyságrendjét.
Nyilván nincs erre konkrét szám. 12 karakteres *teljesen* random jelszót ember nem jegyez meg. Szóval itt nem értek egyet a számaiddal. Ha megjegyezhető jelszavakról van szó, még mindig jobb a passphrase.
És nyilván mindkettőtől jobb, ha meg se kell jegyezni, és jelszó managert használsz.
Így van, az első esetben nem lehet 90^12-vel számolni, ha a jelszó alapja valami létező szó, és csak karaktercserék vannak.
Meg mennyi most egy jó jelszó hash komplexitása?
Próbálkoztam én a john-al megtörni csak egyszerű, rövid, 6 karakteres kisbetűs, de random jelszót (yescrypt). Nem jutott dűlőre, nagyon lassú volt. Vagy még azzal talán éppen. Ez lenne ugye 26^6=3*10^8.
Szuperszámítógéppel tud nyerni mondjuk 6 nagyságrendet, de akkor már kormányzati szereplőről beszélünk, akinek lesz egyéb módszere is hogy megszerezze amit akar.
Az pont a 4 random szó határán van.
Erős jelszóval védett jelszómanagert.
De, csak pwgen modra kell generalni vagy 100-at, aztan abbol kivalasztani egyet, amelyik szimpi.
Igen de ha nem csak egy nyelven van irva vagy nem csak szotari szo szerepel benne akkor a dictionary attack az nem fog jol mukodni.
Nem értem, hogy ez miért lenne "vagy-vagy". Miért nem "és"? Miért zárná ki egymást a két módszer?
Fogsz egy 4 szóból álló passphrase-t, amiben minden egyes szót "elkódolsz", mássalhangzókat számokká vagy írásjelekké, magánhangzókat meg ahogy jólesik kisbetű-nagybetű. Máris van egy könnyen megjegyezhető, mégis tutibiztos jelszavad. A 12 karakteres random jelszót tényleg nehéz megjegyezni, de egy szavakból álló mondatot és pár egyszerű csereszabályt nem.
Példa:
1. fogsz egy mondatot, idézetet, verssort mittomén, amit csak akarsz: "Egy gyűrű mind felett"
2. lecserélsz benne tetszőlegesen egy-két szót olyanra, amitől vicces lesz, és jól megmarad a fejedben: "Egy Arcoskönyv mind felett"
3. jöhet a karaktercsere, pár egyszerű szabállyal külalak alapján mondjuk (A=4, E=3, I=1 vagy ! stb.): "3gy 4rc0skönyv M!nd F3l3tt"
4. eredmény: 90^26 ~ baromira sok variáció.
Persze egy jelszótörő is elvégezheti ugyanezeket a cseréket a dictionary szavain (már ha sejti egyáltalán, milyen cseréket használhattál, ugye), csakhogy ekkor a lehetséges kombinációk száma azonnal exponenciálisan a csillagos egekig ugrik. Ha teszem azt a szótár 7000 szavas, és tegyük fel minden szó csak egyetlenegy számcserélhető betűt tartalmaz, már ennél a legegyszerűbb esetnél is egyszavas jelszónál kapásból megduplázódott a lehetséges esetek száma 14000-re... Két lehetséges betű-szám csere szavanként? Megnégyszereződik, máris 28000 szótárelemnél járunk. És hát ugye a szavakat nem önmagukban nézed, hanem kombinációban, tehát ha még azt is tudod, hogy 4 szóból áll a jelszó, akkor is 7000^4-ből lesz 14000^4...
> 4. eredmény: 90^26 ~ baromira sok variáció.
ha szotarazik akkor nem ennyi, de mind1. persze a szotar honnan tudna a nyelvet vagy kisbetu-e vagy nagy, van-e csere vagy nincs, ezek mind hozzaadnak 1-2 bitet karakterenkent, de nem nagysagrendi ugrast.
de igazabol tokmind1, mert manapsag mar senki se szorakozik hash-ek torogetesevel (max megnez egy rainbow tablat de azok meg nem igazan tudnak 10 karakternel tobbet), mikor sokkal egyszerubb es olcsobb modjai is vannak a jelszo megszerzesenek:
- adathalaszat
- tobb helyen ugyanazt a jelszot hasznalo userek, eleg ha 1 helyrol kiszivarog
es ami tenyleg fontos (pl. ahol penz is van) ahhoz ugyse eleg mar 1 jelszo, hanem 2FA van vagy egyeb vedelem...
Olvasd végig, direkt végeztem számolást szótárral is.
Ez tény. De ezekhez az is kell, hogy hülye legyen a júzer (ami mondjuk elég szokszor adott).
Vagy ha csórikám jelszómenedzsert használ, elég ha az az egy mesterjelszó kiszivárog... De még jobb, elég ha bugos a proggi, aztán nesze neked akármilyen generált jelszavak! >D
Ezzel is egyetértek.
Jókat röhögök itt a kollégákon, akik jelszómenedzsert ajánlgatnak, mert igazából csak hamis biztonságérzeted ad, úgyhogy még az éberségük is lelankad...
Így persze. A hozzászólásom a linkelt módszerre vonatkozott, ahogy általában ezt nagy lelkesedéssel elkezdték használni, az eredeti ötlet szerint. Úgy önmagában nem sokat ér. Mint pl:
https://www.useapassphrase.com/
Ez csak akkor igaz. ha full kisbetu+space+nincs special char.
Amint beleveszel ilyeneket, hogy random kis-nagybetu, space itt-ott kimarad vagy pont, vesszo, underscore lesz belole, random helyeken l33t iras / random szamok, akkor a 7000-es szotar hirtelen min. 200-500K -s lesz, az a negyediken meg mar ott van, ahol lennie kell.
Azt honnan lehet tudni, hogy ez a generátor kellően random kulcsokat generál-e? És mi van akkor, ha könnyen kitalálható mesterkulccsal indít a felhasználó?
sehonnan :D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Bár nekem is ez az egyik kedvenc dilbertem (a másik a disaster recovery plan, főleg a video verzió), de a viccen túl egyébként egy random generátorról elég jól be lehet látni a minőségét :)
Sok tesztet végeztem különféle beállításokkal.
A legnagyobb 2 milliárd jelszóval történt 20 karakteres kimenő jelszavakkal. Az eredménye nulla egyezés volt.
Az ilyen vizsgálatok nagyon sokáig tartanak (több min egy nap).
Egy 100 milliós tesztet viszont néhány perc alatt elvégez a program. Mindenki megnézheti maga is.
---------
Ha beállítom paraméterként:
Próba szabály=key1:_KisKutya
akkor a következő kulcsokat kapom:
bemenet >>> kimenet
cica >>> "S"FB-Yt^9s3+,II
kutya >>> /xo77i(li@(t6&w8
123 >>> lda*3KiQOy7)xGCK
"Mindenki megnézheti maga is" - a forráskódot hol lehet megnézni? Mert a security by obscurity az még a weboldalad stílusának az idejét megelőzően is túlhaladott gondolat volt...
Hasznalj rsa tokent a jelszoval vagy valami hasonló megoldást.
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
Köszönöm a javaslatot, de most már megcsináltam a saját megoldásomat.
Én teljesen megbízhatónak tartom, és ezt fogom használni.
Azért tettem itt közzé, mert úgy gondoltam másnak is hasznára lehet.
"Én teljesen megbízhatónak tartom," - De sok biztonságosnak gondolt saját fejlesztésnél hallottuk ezt... Mondhatni mindegyiknél, és kiderült, hogy a valóság meg totálisan másképp gondolja...
"Azért tettem itt közzé, mert
úgy gondoltam másnak is hasznára lehet." ...mert itt sokan járnak, és kell a kattintás :-P Bár aki erre jár, az ismeri a pwgen-t, és annak a forráskódját is megnézheti, ha akarja...Olvasd el még egyszer(, de a rosszindulatodat félretéve), és akkor látni fogod, hogy ez és a pwgen másról szól.
"mert itt sokan járnak, és kell a kattintás"
Miért kellene nekem a kattintás?
Ez arról szól, hogy egyszerű inputból egy nem publikus algoritmussal kreálsz egy stringet, ami csak és kizárólag szerinted jó jelszónak. Az a gondolat, hogy egy _egyszerű_ input legyen az, amiből a valódi jelszó kigenerálható, az per definitem rossz - leírtam miért.
"Miért kellene nekem a kattintás?" - Mert nem először hozod ide a borzalom oldaladat, és ugye a kattintás meg a referer az jó dolog, hogy sok emberhez eljusson. Mondjuk egy GH vagy hasonló forráskódmegosztó... Ja, hogy te a zárt forráskód híve is vagy... De ezt is leírtuk már páran, párszor: biztonsági téren nagyon nem szül bizalmat egy a web eldugott szegletében lévő zárt szoftver...
A "biztonságosnak tartod" kapcsán persze nincs válaszod... Ez nagy kár...
--
> https://sign-el-soft.hu/keygen.html
hu ezt a weboldalt kaputelefonnal irtak? a 90-es evekben?
Ejha... frameset tag. Ez tényleg kövület.
Ezt én is akartam neki írni, hogy sok mindenben elég régimódi a szoftvere (GUI a screenshotok alapján, zárt forráskód erőltetése, de tematika alapján is, DVB-t használó médiaszerver, reklámok kivágása, stb.), meg a weboldala, de nem akartam szemétkedni, főleg, hogy már így is elég sokan durván pesztráljátok. Végül is nem webfejlesztő, meg más az ízlése, így elfogadtam, hogy ő így publikál, meg régi vágású, így elengedtem, retrós ízlésű, jobb inkább nem belekötni feleslegesen mindenbe. Ehelyett inkább a lényegre koncentrálok. Szerintem az a kolléga legfőbb baja, hogy mindenben próbálja saját kútfőből újra feltalálni a kereket.
Eleve azt se értem, hogy egy médiaszerverbe minek titkosítás, de hagyjuk. Meg minek ilyen jelszórövidítős levágással bonyolítani, miért nem lehet a felhasználóra bízni, hogy használjon rövid/gyenge jelszót a saját felelősségére. Ha valaki titkosítást akar, bízza rá a drive-ra, OS-re, erre készült speciális programra (LUKS/GELI, VeraCrypt, stb.), fájlrendszerre.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Az OP-nek szerintem nincs elég kattintás az oldalán, azért hozta (megint) ide a... szóval dogait... :-)
Fú, banyek, ez majdnem olyan rossz, mint az agilemanifesto.org
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Ezt most miért kellett így péntek délután :D
Na, ezeket az agiliseket hajbi legközelebb nem bánthatja, hogy fejlődésmániások, meg babzsákfejleszők, ha egyszer egy 2001-es, statikus, 0 CSS-t használó weboldallal tolják még mindig.
Egyébként modern weboldal nem csak azért fontos, hogy megfeleljünk a fejlődésmániásoknak, hanem pl. sok átlag netező is hiheti ilyen elavultan kinéző oldalról, hogy már nem aktuális, egy régről fentmaradt oldal, ami mögött már nincs semmi, nem frissítik, és zárják is be.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Az a szomorú, hogy az interneten fellelhető valódi információ 90%-a ilyen és ehhez hasonló weboldalakon van.
A többi az már csak "content", de nem információ. Pl. tldp.org rémlik valakinek? :)
Te döntsd el, mi hiányzik belőle jobban:
Az igényesség...
Pedig ha a sárga-barna színvilágot és az erőltetett dőltbetűt levesszük róla, konkrétan igényesebb, jobban strukturált, mint egy mai átlag modern honlap.
Animációk, material design és egyéb webökör anti-patternek helyett az információtartalmával tűnik ki. Ez általában nem mondható el a csiligány, bloated, modern™ weboldalakról.
Tehát ha az alapvetően igénytelen kinézetét eldobjuk, és megsózzuk egy kevés ergonómiával, akkor... Vagyis ha öreganyámnak áramszedője lenne...
A KISS es a Form follows function elvek miatt egyetertek hajbazerrel.
Sallangoktol mentes oldal. Lehet, hogy nem koveti a mobilra optimalizalt trendi feluleteket es megoldasokat (pl. frame es table helyett div) de ettol meg hasznalhato.
Az en szivemnek sokkal kedvesebb egy ilyen oszinte mininalista oldal, mint egy random Wordpress szutyok, ami pedig modern meg minden.
A minimalista az nem azonos azzal, ami "vizuálisan igénytelen, ergonómiáját tekintve nulla".
Es meg is talaltuk a tokeletes jelszot.
Ezekben alapvetően megint igazad van, de nem ártott volna azért, ha az oldal valami kulturált sablon alapján készült volna, validálható HTML5-ben. Attól még nem kellenek a felsorolt végletekhez nyúlni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Szerintem erre a rövid válasz, hogy nem.
Pont erre jöttek létre a jelszótároló megoldások, hogy mindenhová másik, kellően hosszú és bonyolult jelszó kerüljön, amit nem kell fejben tartani. Aki nem bízik a felhős szolgáltatókban, az akár a saját gépén lévő jelszókezelőt és saját gépén tárolt jelszó adatbázist is használhatja.
De valóban a jövő a jelszó nélküli hitelesítő megoldásoké. Viszont amíg ezek mindenhol elérhetőek nem lesznek, addig muszáj a hosszú és bonyolult, egyedi jelszavak használata.
Jelszavak brute-force feltörési ideje, 2023
Ebben a táblázatban azért már durván rosszabb számok szerepelnek a linkelt weboldalhoz képest. Gyakorlatilag 12 karakter és legalább 3-féle jel használata alatt azonnali a megfejtés megfelelő hardveren.
Én speciel 2-3 szóból és még számból+írásjelből álló "jelszavakat" generálok, amik 20-30 karakteresek, és annyit segít a teljesen random karaktersorhoz képest, hogy könnyebb lediktálni, begépelni, ha arra van szükség. Megjegyezni ezt sem lehet szerintem.
Ha megvan a hash, nem? De ha N próbálkozás után percenkénti egyre korlátozza a próbálkozások számát a server, akkor távoli bejelentkezésen továbbra is nehéz jelszót törni.
Igen, csak "mostanában" ez úgy került elő (elém is így került ez a táblázat), hogy lenyúlták a Lastpass-tól szemmel is jól látható számú felhasználó jelszószéf állományát, így gyakorlatilag korlátlan idejük van bármilyen tempóban jelszavakat próbálgatni rajtuk.
Ha élő rendszerről beszélünk, és van ilyen védelme (lassítás, ideiglenes letiltás; sajna nagyon sok helyen nincs ilyen védelem a mai napig), az jelentősen megnehezíti rövidebb/egyszerűbb jelszavak brute-force vagy szótáras "kitalálását" is. De ha nincs ilyen korlátozás, akkor csak a hossz és az összetettség mértéke véd.
Lehet az összetettséget növelni avval, hogy a “kitalálható” usernév helyett is bevezetni valami, a user által megadott egyedi azonosítót, ami szintén valamilyen titkosított módon van eltárolva. Kvázi ez olyan mintha login-kor két jelszót adnál meg.
Ez tényleg elkeserítő, de azért fenntartással kezelném. Nincs ott, hogy milyen megoldással mérték, hogy reprodukálható legyen.
Azzal mindenképp tisztában kell lenni, hogy a titkosítási algoritmusok és jelszavak technológiai természetük folytán folyamatosan gyengülnek. Mert ami ma x idő a mostani hardvereken, az valószínű csak annak töredéke lesz a 10-20 évvel későbbi gépeken, kvantumgépeken, stb..
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Kínai karakterekkel? :D
Van belőlük pár ezer, elég egy rövid karaktersorozat is :D
Esetleg nehezítésként pár emoji :D
Szerintem ha egyszerű jelszót szeretnél, mégis _viszonylag_ biztonságosat, akkor paddeld fel.
Pl.: ne az legyen, hogy Macika, hanem: Macika123456789 vagy Macika222222222222222222222
Az entrópiája nem lesz nagy, de hosszú. És ez bizonyos esetekben többet számít. Pl. ha szivárványtáblával támadnak, a hosszabb kisebb valószínűséggel lesz benne, illetve csak nagyobb táblában.
Sok támadásnál egyébként nem a jelszó komplexitása a gond, hanem a password re-usage.
Felnyomnak valamit egy exploittal, megszerzik a jelszavakat vagy a hash-eket, és kiderül, hogy ugyanaz a jelszavad mindenhol...
Password Manager és egyedileg generált random jelszavak erre az én megoldásom (Bitwarden).
Sajnos nem mindenhol lehet rátenyerelni a paddeléshez, vagy random generáltatni:
Pénzügyi szektorban (név nélkül) több helyen is hasonló szabályokat támasztanak a "nagy cégek": minimum 12 karakter, maxumum 15 (másik példa: minimum 13 karakter, maximum 20)
Azt hiszik, a nyolc karakter tiltásával máris megoldották a biztonsági gondokat, és az egységsugarú felhasználó meg számolgassa a kicsi ujjacskáin, hogy: ez még 11? Vagy már 16??? Mert elfelejtették megvalósítani, hogy a mezőbe ne lehessen a maximumnál több karaktert beírni.
Ja, és meghatározzák, hogy csak ezek a sepciális karakterek lehetnek, punktum: ?:,+%*&
És hol a kötőjel? A pont? Az aláhúzás? Szünetet el se fogad alapból. Ékezetes karakterek? Bővített ASCII/UNICODE??? Ugyan már!
A jelszókezelő javaslatait azért nem is használják az emberek, mert ezen az is megbukik, nem engedi a rendszer.
És amitől legutóbb eldobtam az agyam: egy helyen tiltották a jelszó mezőben a PASTE funkciót!!!
Számomra a NIST ajánlásai szimpatikusak, irányadónak látom: https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
Ez alapján én engedném a 10 karaktert is (ha megfelelő az entrópia), de 64-re emelném a maximumot (ja, és TRUNCATE alkalmazása nélkül, mert viccesen több olyant is láttam, hogy beírhatsz te 128 karakteres jelszót is, de csak az első 20-at veszik figyelembe...). Beépíteném a Have I Been Pwned API-ját, hogy pár naponta futtassa le a felhasználóneveket, e-mail címeket, HASH-eket. Eltörölném az időnkénti jelszófrissítési kötelezettséget, és inkább BLACKLIST-ekkel ellenőrizném beíráskor a kiszivárgott/gyakori jelszavakat, tiltanám a felhasználónév, név, születési év használatát, és mindig vizsgálnám az entrópiát. Ja, és kitetetném a szemecskét a jelszómező végére, hogy közben vizualizálja is a felhasználó, hogy milyen jó jelszót talált ki eddig. Mindenzt kötelező, de szabadon választható 2FA-val megfejelve (TOTP/SMS/Yubikey/U2F/FIDO2).
Magyarán: ha a user jelszókezelőt használ, vagy kreatívan kitalál egy kellően megfelelő kódot (a fent részletezett ellenőrzések mellett), amit fejben is tud tartani, azt hadd használja már szegénykém addíg, amíg nem kompromittálódik.
Ti mit gondoltok?
A password managerek (pl. Bitwarden) jelszógenerálóiban pár kattintással tudod állítani ezeket. Min...max hosszt is, és a karakterkészletet is. Ha rinyál az oldal, odaböksz egyet és generálsz egy másikat. Vagy eltávolítod a problémás karaktert és kész. Nem tudom, miért kell ebből ennyit kihozni.
Ne keverjük most ide a 2FA-t, nem az volt a kérdés. Valahol nincs rá lehetőség.
Nem ez a baj. Azzal egyetértek, hogy ne legyen kényszerített pw change --> így keletkeznek a sorszámozott, billentyűzet aljára felírt, vagy gyenge jelszavak. *
DE! Ne használja ugyanazt a jelszót több szolgáltatásban.
A jelszókezelő pont abban segít, hogy lehetnek akár véletlenül generált jelszavaid, és mindenhol más - hisz nem kell megjegyeznek őket. Cross-device kitölti neked, egy ujjlenyomat megmutatása után.
* Nálunk egyébként az a szokás, hogy a kollégák csak a számot írják fel a monitor aljára, így nem lehet megbaszni őket, hogy oda van írva a jelszó. Vannak function userek is, ezekre is van enforced expiration, és három rossz próbálkozás lockolja az accot. És persze akinél épp lejár, az léptet egyet. Aki ritkán használja, meg eleve nem emlékszik már, hol is tartott a szám. Ezért van odaírva.
De most nem az elbaltázott policy-k volt a téma.
Pont ez a baj, hogy sokan önmagában a karakterszámot nézik, de az nem elég önmagában. Nézni kell a karakterkészletet is. Épp ezért én bitre szoktam megadni a jelszóerősséget, 2 a hányadikon lehetőséget kell végigpróbálgatni hozzá. Tehát ha van egy 20 karakteres PIN kód (0-9 számjegyekkel, ez kb 66 bites erősség), az kevésbé véd, mint egy 17 karakteres hexadecimális string (68 bit), vagy mint egy 12 karakteres base64 (72 bit), vagy egy 11 karakteres megjeleníthető ASCII készlet (72 bit), vagy egy 4 karakteres UTF-8 (84 bit).
Tehát nem baj, ha valahol csak bizonyos karakterek lehetnek a jelszóban, de akkor a minimális hosszát megfelelően emelni kell a jelszónak, hogy kompenzálja.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Mótvá...
Önreklám, a weblap az ő műve szerintem.
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @
Persze , hogy az - a linkelt topicban ott van...
Onnantól kezdve, hogy a "zalgoritmus" (ami titok, mert forráskód az nincs) két bemeneti adatból kihány egy n karakteres stringet, még nem jelszógenerátort csináltál, hanem egy sózott "hash"-t, azaz gakorlatilag ha viszi valaki a bemenetet (ami nem a jelszó ugye...), meg a programodat, akkor megvan a jelszóként használt string. Oké, nem egy random jellegű stringet kell elrakni a jelszószéfbe, csak azt, hogy emzéperix beállításnál köbüki-t kell beírni inputként...
Bár látom a fejlődést, de még mindig nem érted. Próbáld meg elolvasni még egyszer!
Mielőtt hozzákezdesz javaslom tételezd fel, hogy az az ember akit te sértegetsz, és a munkáját sározod, mégsem olyan hülye mint ahogyan gondolod. Tételezd fel azt is , hogy te pedig nem vagy olyan okos, ahogyan gondolod.
Ha nem érted hogyan működik, az persze lehet az én hibám is, ha nem fogalmaztam elég érthetően, de ha pozitívra váltod a hozzáállásodat és meg akarod érteni, akkor sikerülni fog.
Mi csak azt "tételezzül fel", hogy az a webszerkesztés skill valahol a 2000-es évek hajnaláról van, akár csak a technikai tudás.
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @
Remélem azt is észrevetted, hogy a program ingyenes. Jobban érthetően 0.0 Ft/év bevételt hoz -25eFt/év webtárhely és kb ugyanannyi VPS bérlet a teszteléshez.
Ha vállalod, hogy ennek a bevételnek a feléért szebb oldalt csinálsz, tárgyalhatunk a megbízásról.
Akkor át kell gondolni a pénzügyi tervet. Amúgy ez a weblap elfér egy ingyenes helyen is, sőt, bőven elég neki egy Wordpress. Amúgy minek VPS tesztelni ezen bármit?
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @
A pavc-server 1.5 éve fut 17 példányban egy VPS-en.
Felesleges, Virtualboxban elfutna otthon is.
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @
A több szerver teszteléséhez nem kell több gép. A VPS-en is chroot-tal elkülönítve egy gépen futnak. De nem fut az otthoni gép éjjel nappal. Ha futna, az valamivel többe kerülne, mint a VPS bérlés.
A VPS állandó IP címmel rendelkezik, az otthoni gép nem, ... Szóval egyébként is kell a VPS. Egy fix pont, amin keresztül a saját IP-vel nem rendelkező eszközök is kapcsolódhatnak egymáshoz.
Tegyük fel, hogy egy jelszókezelő programmal (LastPass, Firefox, stb.) generálok egy jelszót, pl. aU7%v_aF2nz-d915. Ha nagyon jó minőségű véletlenszámgenerátorral készült, akkor gyakorlatilag soha senki nem fogja kitalálni.
Most tegyük fel, hogy a programodnak beírom mesterkulcsnak, hogy cica, és ez kiadja, hogy a jelszó legyen M!b71-sa17gAFV61. Ez a jelszó elsőre olyan kitalálhatatlannak tűnik, mint az előző. De ha valaki kitalálja a mesterkulcsot, és beírja a programodba, ami bárkinek elérhető, akkor a jelszót máris kitalálta.
Jól értem, vagy nem?
Nem érted jól!
Az algoritmus nem fix!!! Te paraméterezed fel. (key1, key2, ke3, key4)
Nézd meg ezt is:
Miért van benne az import export?
Mit jelent a PORTABLE beállítás?
Én: "tegyük fel, hogy a programodnak beírom mesterkulcsnak, hogy cica"
Te: "Te paraméterezed fel. (key1, key2, ke3, key4)"
Nem ugyanarról beszélünk? Akkor te nem értetted meg, amit én írok.
Kérlek, ha lehet vedd át az oldalon leírt konfig fájl jelöléseit!
Mit nevezel mester jelszónak? Azt hogy a konfig fájlba beírsz egy ilyen sort :
Az én 1. szabályom=key1:_cica ?
Majd amikor használod és be akarsz lépni pl. az OTP-be akkor beírod a jelszó mezőbe, hogy OTP?
Erre a jelszó a default formátum (16 random char) esetén ez lesz:
$D_<9@);UaYR:CNc
Honnan fogja tudni bárki, figyelembe véve, hogy a konfig fájlodat jelszóval védheted, hogy te a key1:_cica argumentummal dolgozol?
Megjegyzem, a key2..4:_cica mind-mind más jelszót fog adni, és beírhattad volna még a key1_:cica mellé, key_2:farka.
Ha nem véded külön jelszóval a konfig fájlodatt (tapasztalat a könnyelmű felhasználókról), akkor is megpróbál védeni a program. Erre való a PORTABLE=0/1 beállítási lehetőségnél leírt rész.
Megjegyzem, aki saját maga semmit nem tesz a védelméért, azt nehéz megvédeni. A másolásvédelem ereje nem korlátlan.
Jó, akkor hívjuk key1-nek, vagy inputnak, vagy bárminek, amit a felhasználó beír. A lényeg az, hogy hiába generálsz te ezer karakteres jelszót, ha az egy sokkal rövidebb karaktersorozatból megfejthető. Tehát kriptográfiai szempontból a kimenet sokkal gyengébb, mint egy igazából random string. Pont olyan gyenge tud lenni, mint az a string, amit a felhasználó megad.
Sajnálom, hogy nem fogalmazok elég érthetően.
A kimenő kulcs generálása 5 szóból (key1...4, amit egyszer beírtál a konfig. fájlba, és az aktuális inputból) áll elő. Ehhez jön még a szintén a konfig fájlba beírt formátum parancsod. A key1..4 közül legalább egynek a használata kötelező! Az, hogy milyen hosszú szót/mondatot írsz be a konfig fájlba a key1...4: mögé, befolyásolja a biztonságodat. A konfig fájlt a program menti (kulcsszóval vagy anélkül, a te döntésed). A kimenő jelszavad ereje kb. a (key1..4+input+2)karakternek felel meg.
A nyereséged az, hogy egy egyszeri beállítás után a jelszavaid könnyen megjegyezhetőek, és mégis biztonságosak (ha gondos a beállításod) lesznek.
Ha több felhasználót kezelsz, akkor ugyanazt a jelszót tudod nekik megadni, ha elfelejtették. Nem fognak újra hívogatni, mert van egy PC, meg egy LAPTOP, meg két mobil, és valamelyiken persze megmarad a régi jelszó, és jön az újabb hívás. Ha a key1...4 erős, akkor az input lehet nagyon gyenge. Pl. username1, username2, ..., valami amit te könnyen megjegyzel, nem kell felírni, keresgélni.
Az input halmazból generálsz egy nem publikus, de szerinted erős és megbízható algoritmussal valamit. Azaz 1:1 megfeleltetés van az input+paraméterek és a kimenet között. Lehet cukrozni, de egy "egyszerű jelszó" +valami "random" de szintén korlátos értékkészletű dologból kreálsz egy randomnak kinéző stringet.
"Ha a key1...4 erős" - Mit jelent, hogy "erős"? mert ugye az algoritmusod nem publikus, így elég nehéz megbecsülni, hogy valójában mi az "erős" és mi nem az...
"Mit jelent, hogy "erős"?"
Ez tényleg kérdés?
Igen, kérdés, mert te állítod, hogy "erős", de ezt semmi nem támasztja alá. Nincs információ arról, milyen algoritmusokat használ, milyen módon van(nak) implementálva, milyen az alkalmazás memóriavédelme (coredump-ból/memória snapshot-ból mi szedhető ki), és hasonlók...
Ha neked kérdés, hogy az "erős", mint önmagában lévő állításra nem az a válasz, hogy "jó", hanem az, hogy ez pontosan mit jelent, akkor tényleg nem kéne biztonsági témában kódot hegesztened...
De akkor, ha jol ertem, igazabol ez tovabbra is egy salt algoritmus. Van a secret (key1..n), es van a salt, amit a user ad meg, amikor "jelszot general". Nem?
"Honnan fogja tudni bárki, figyelembe véve, hogy a konfig fájlodat jelszóval védheted, hogy te a key1:_cica argumentummal dolgozol?"
A konfig fájl jelszavas védelme gondolom valamilyen ismert és bizonyítottan megbízható algoritmust használ? Mert ha nem, akkor goto 10...
Nézz meg egy "titkosítatlan" konfig fájlt előbb és ha nem érted akkor gondolkodj el azon, hogy mit fogsz kezdeni a titkosítottal!
Próbáld meg átmásolni egy másik gépre, és nézd meg ott is!
Amit egy általad "erős"-nek nevezett jelszavas titkosítással védve tárol az alkalmazásod.
Ha jol ertem, akkor azzal noveled az entropiat, hogy tobb helyrol szedsz adatot.
De a rot13( md5("alma"+"korte"+"szilva") + sha1( base64( sha1("alma"+"korte"+"szilva"))) + sha256("alma"+"korte"+"szilva")) hiaba hosszu string, es nem visszafejtheto az "algoritmus" nelkul, nem lesz nagyobb a valtozekonysaga mint az alapjaul szolgalo 15 karakternek. Meg akkor sem, ha a harom, vagy tobb input mezo tartalmatol fugg, hogy milyen hash fuggvenyeket alkalmazol, vagy hogy hanyszor futtatod ra.
Az teny, hogy ad egy gyakorlati vedelmet, de elviekben nem helyes, mert a security by obscurity -n alapul. Kicsit olyan, mint a sozott hash. Ha valaki megtudja a saltot, bukta van. De mindenki arra epit, hogy a salt titokban marad, pont ezert hasznaljak.
Hasonloan "rossz" megoldast en is csinaltam. Webes portal html, js es php alapokon, semmi extra, kivetel az a kattanasom, hogy jelszo input mezo erteke nekem ne keruljon a drotra plain text formaban, mert https ide vagy oda, ez akkor is ciki. Ezert keszitettem egy hash erteket a jelszo + username ertekbol, majd ebbol es egy szervertol kapott ertekbol generalt chaptara adott valaszbol keszult egy ujabb hash, es ez utazott vissza a szerver oldalra.
Jol nezett ki a 40 karakteres sha1 ertek, tok secure-nak tunt, de egy hozzaerto biztosan a pohar utan nyul egy ilyen "megoldas" lattan. En ezzel ugy vagyok, hogy a security by obscurity-t akkor erdemes valasztani, ha az a kisebbik rossz, viszont tulsagosan bizni benne akkor sem szabad. Az ilyen megoldasok olyanok, mint a manko kerek az auton. Sokkal jobb, mint durrdefekt utan harom kerekkel slattyogni, de azert mankokerekkel nem furikazunk, mert az arokban kotunk ki. :-)
Egyetértek, de hozzátenném, hogy éppen az általad leírtak miatt itt 4+1 szó használható (key1...4 + az aktuális jelszó), és a visszafejthetőséget tovább csökkenti, hogy nem mindegy, hogy hol vágod el.
key1:_alma, key2._korte, key3_:szilva != key1._alm, key2:_akort, key3:_eszilva
Mindehhez hozzájön a formátum beállítási lehetőségek igen nagy száma. Ha mindezt összeadjuk az több mint +két karakter.
Azt viszont nem értem, hogy miért probléma az, hogy egyszer az életben a felhasználónak produkálnia kell egy hosszabb szósort. Ezt utána nem kell többször leírnia. Amiket beír azok pedig lehetnek pl ilyen egyszerűek: OTP, CIB, fb, ...
Szerintem nem erted, nem ez a problema. Ez egy sima salt, van millionyi algoritmus ra, ami mar bevalt, es valaki atnezte.
A problema az, hogy:
A sót nem kell titokban tartani. Az egész a szivárvány táblák ellen véd, és azok ellen akkor is véd, ha kitudódik.
Tenyleg. Bakker, ez teljesen kiment a fejembol. :-)
ha annyira okos és büszke/bízik az alkotásában, akkor közzéteszi a forráskódot, az algoritmus leírását, és annak az igazolását, hogy valóban megbízható a jelenlegi matematikai tudásunk alapján.
Egyébként értem? van egy saját hash algoritmusod, amit paraméterezni lehet, és az csinál a lócitromból franciakrémest. Vagy fordítva. De attól még az 1:1 megfeleltetés miatt a paraméter+input ugyanaz a kategória lesz, mint az azokból generált jelszó.
https://hup.hu/comment/3024883#comment-3024883
Nem lehetne megforditani a dolgot, es mondjuk te irnad le, hogy mi tortenik, nem pedig zeller talalgasson, amig bele nem trafal? Szerintem sokkal gyorsabban kozos nevezore juthatnatok.
Mindegy, csak beszéljenek róla az OP hozzáállása - az, hogy mit _akar_ csinálni, az világos, a gáz ott van, hogy ez továbbra is egy zárt, ismeretlen algoritmus(oka)t használó sózott hash, aminek a salt részét lehet az OP által erősnek nevezett jelszavas titkosítással védeni. (Nomostan ha a usernek a kiscica megjegyzése megy, de mondjuk egy vooS_ei3jok4 már nem, akkor vajon az az "erős" jelszavas védelem mennyit fog érni...?)
Ennek mi értelme van? Miért jó, ha az előállított hash hosszúságát állíthatod? Nem látom értelmét.
Egyébként meg, még jódarabig tutibiztos megoldás, de talán még a kvantuumgépek ellen is véd:
Pofonegyszerű, csak a jelszó a bemenete, könnyen előállítható, könnyen ellenőrizhető, gyorsan generálható, minden rendszeren támogatott nyilvános algoritmus, ellenáll a rainbow hashingnek, akkor is biztonságos marad, ha esetleg megtörik az sha512-t, stb. stb. stb. Minek ezt túlcifrázni?
Én is ezt akartam írni. Bár írta a topikindítóban, hogy ez nem egy jelszógenerátor akar lenni, de nekem mégis olyasminek tűnik. Ezt a jelszógenerálást egy pár soros POSIX shell scriptben így oldottam meg. Csak a lényeg, leegyszerűsítve, a script hosszabb azért egy kicsit, mert debug infókat, fejlécet is csinál, meg X vágólapra is teszi a jelszót:
Ez egy alapértelmezetten 64 karakteres random jelszót generál (vagy akárhány karaktereset az $1 paraméter alapján), amiben csak nyomtatható, és nem magyar billentyűzetről is bevihető karakterek vannak, 96 féle. 96^64-es, azaz kb. 421 bites erősségű jelszó. Overkill, lehet sok helyre a 32 karakter is bőven elég lenne. Nyilván ez a megoldás minimalista, de működik minden POSIX rendszeren, nem kell hozzá grafikus felület, a kimenete tovább pipe-olható más parancsokba, használható más scriptekben. Nem is minden oldalon használok ilyet, csak a fontosabb szolgáltatásoknál, meg a Facebook, amit egyszer feltörtek nálam (a FB rendszere megfogta, nem tudták átvenni a fiók felett az irányítást), másodszor, erősebb jelszóra cserélés után is küldte nekem a FB a biztonsági értesítőket, hogy belépési kísérlet, ami nem éntőlem volt, így muszáj volt erre az overkill jelszógenerális sémára rámenni, azután azonnal lakattantak a fiókomról, meg sem kísérelték többet.
Nyilván ezek nehezen megjegyezhető jelszavak, de ezt meg saját jelszókezelővel oldom meg, ami meg egy AES256-tal és egy erős mesterjelszóval jelszavazott text file-ban tárolja, kódolja ki, szerkeszti az $EDITOR változóban lévő szövegszerkesztővel a jelszavakat. Ez is primitív megoldás, de csak pár soros shell script, sose hagyott cserben. Ezt tuti nem fogják feltörögetni. Mivel OpenGPG-vel dolgozik, ezért multiplatformos, használható Android, iOS, Windows, BSD-k, illumos disztrók alatt is.
Még extra pár sorból, pl. yad (Gtk+), zenity (Gtk4), kdialog (Qt5) vagy dialog (ncurses) segítségével gyárthattam volna hozzá GUI vagy TUI felületet, de az már semmit nem adott volna hozzá, csak a függőségeket növelte volna. Sokszor a kevesebb több, és az egyszerűség rugalmasabb.
Természetesen a te hash-elt módszered is teljesen jó, meg pl. lehet azt is, hogy négyzetgyök π-nek (most csak a hasamra ütök, lehet a köbgyöke az e-nek, vagy akármelyik transzcendentális számnak az akárhányadik nem transzcendentális hatványa) az 1 (vagy random) millió tizedesjegy utáni random helyiértékéről indítva random, de min. 64 jegyű számsort kinyerni, és ezt base64-ként vagy hexadecimálisan kódolni, vagy ebből sha512sum-mal előállítani a kimenetet.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Jah, jol kiegszerusitetted belole, hogy az outputnak determinisztikusnak kell lennie, vagyis ha neked az OTP netbankba kell belepni, akkor azt a jelszot adja vissza, ha meg a CIB-be, akkor azt. Igy azert konnyebb! :)
Jó, hát nem volt hozzá IDE támogatás :)
Ezt fogalmazd át, nem értem mit akartál vele mondani. Annyi lejön, hogy nem jó módszer szerinted, de nem értem mi lenne vele a hiba. Azt se világos, hogy az IDE hogy jön ide. Ezt az egész deteminisztikusságot nem értem. Az alapot a /dev/random adja, ami mögött meg a kernelben van egy csomó biztonsági malőr, használja a proci vonatkozó utasításkészletét, meg entropy pool erősítés is van benne, amit mindenféle más forrásból szed. Lehet nem tökéletes módszer, de ha a kernelesek nem tudtak jobban írni, szerinted neked és nekem fog menni egy jobb implementáció?
Vagy csak nem érted a működési elvét. A jelszó nem attól függ, hogy hová akarok belépni, azt random generáltam. A megoldás nem nézi, hogy hová lesz a jelszó. Ilyen szolgáltatása a jelszókezelőknek is van egyébként.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Volt egy megoldas arra, hogy egy statikus secret alapjan determinisztikusan eloallitsunk jelszavakat, adott szolgaltatasokhoz. Vagyis a jelszogenerator az OTP-s netbankomhoz ugyanazt a jelszot generalja ma, mint holnap vagy tegnap. Tehat nem a kesz jelszot taroljuk, hanem egy seedet, amibol derivaljuk a jelszot minden alkalommal.
Te bejelentetted, hogy ez konnyu, majd adtal egy egysorost, ami random karaktereket general. Oke, de nem ez volt a feladat!
Nem beszeltem IDE-krol.
Ja, érem. Végül is ez is egy megoldás, hogy minden belépési alkalommal generáljuk, nem tároljuk magát a jelszót. Végül is lehet megpróbálok majd implementálni egy ilyen megoldást. Egyelőre a saját megoldásomnál maradok, mert a többi jelszómenedzser is így működik, azokkal csak az volt a bajom, hogy vagy más felhőjében van az adat, amit felnyomnak, vagy nem, de nem platformfüggetlen megoldások, vagy terminálban nem működnek jól, stb..
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nem biztos, hogy erdemes. Igazabol errol a dilemmarol szol a thread. :)
Azaz a statikus secret a valódi jelszó. (oké, van egy "titkos" algoritmus, ami generálja belőle a loginhoz használt jelszóstringet.)
Ja, de ezzel onmagaban semmi gond nincs, ha
1. Ember alkotta szavak adják a titkot, tehát kitalálható, és fájlban tárolódik, tehát hozzáférhető.
2. Ha az alkotónak nincs kriptográfiával kapcsolatos képesítése, akkor erre nem vennék mérget.
Ebben a konkret esetben igen, de altalanossagban irtam.
Most azert ne csinaljunk ugy, mintha nem lehetne megoldani, hogy van egy vedett privat kulcs, es abbol valamilyen inputra valamilyen outputot generalunk. :) Smartcard, TPM, FIDO2, CTAP2, stb., azert ezek letezo dolgok, csak hat igen, bonyolultabbak, mint egy text fajbol beolvasni egy passphrase-t.
Kérlek nézzétek meg azt a "text fájl"-t, mielőtt nyilatkoztok róla!
Az nagy különbség, hogy mit lát a felhasználó a program saját editorában, és mit lát, ha egy külső szövegszerkesztővel nézi meg.
Szerintem a tisztesség megkívánja, hogy ne kritizáljunk addig, amíg meg sem néztünk valamit.
(zellertől már kértem, de hiába. https://hup.hu/comment/3025617#comment-3025617)
En csak azt latom, ami a weboldalon kint van, ranezesre kulonbozo formatumokat krealhatsz, 1-4 db kulccsal.
Innentol tippelek, a weboldal tartalma es az itt elhangzottak alapjan, mert nem fogok reverse engineerelni egy zart forraskodu szoftvert megfelelo papirmunka nelkul. Egy szimmetrikus titkositassal van vedve a fajl, ami ha PORTABLE=0 allapotban van, akkor a szoftverben van a kulcs. Itt megelolegezem a bizalmat, es arra tippelek, hogy a szoftver minden instance-nak sajatot general, es nem valahol egy const van beegetve. :)
Nyilvan ezt is el kell tarolni valahol, ami ugyanezeket a kerdeseket veti fel, csak egy absztrakcios szinttel magasabban. Emiatt, illetve a "gepek kozotti masolhatosag" emlegetese miatt a kovetkezo tippem, hogy a kulcs a gep valamilyen tulajdonsagabol derivalodik. Kiveve, persze ha PORTABLE=1, mert akkor a user valaszthatja a szimmetrikus kulcsot ("jelszo"), vagy egyaltalan nem lesz titkositva a fajl.
Kozel volt?
De hat neznenk mi, csak legalis modon nem juthatunk hozza az algoritmushoz.
"a user valaszthatja a szimmetrikus kulcsot ("jelszo")" - Egy olyan sw esetén, ahol az a cél, hogy erős, nehezen megjegyezhető jelszó helyett valami egyszerűn kelljen megjegyezni...
"ne kritizáljunk addig, amíg meg sem néztünk valamit." - Akkor mutasd a forráskódot, hogy legyen mit megnézni. A konfigfájl titkosítása, pont azért, mert csak egy állítás van arról, hogy erős semmit nem jelent a biztonság szempontjából addig, amíg az az "erős" állítás nem bizonyított.
Security területen a tisztesség megkívánja, hogy csak azt nevezzük "erős"-nek, amit tudunk is matematikailag(!) bizonyítani, hogy az, és ezt más is tudja validálni.
Nem értem miért félti a tákolmányát. Fizetni senki sem fog érte, akkor meg minek titkolni?
PS.: Természetesen, ha kiderül a tákolmányról, hogy nem tákolmány, akkor nyilvánosan bocsánatot kérek
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @
Spoiler: nem fog kiderülni
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @
A secret jelen esetben ha jól értem egy konfiguráció meg egy egyszerűen megjegyezhető "jelszó". Mivel a konfig fájlban tárolódik, így a "nem hozzáférhető" kiesik, és hiába jelszavazható a konfiguráció, ha a konfiguráció jelszava nem kellően erős - márpedig pont az a célja a motyónak, hogy ne legyen szükség erős jelszavakat megjegyezni...
"Ennek mi értelme van? Miért jó, ha az előállított hash hosszúságát állíthatod? Nem látom értelmét."
Ha a programon belül saját magam használom, akkor természetesen nincs értelme.
Ha át kell adnom valakinek, akkor sokkal olvashatóbb és könnyebben kezelhető a formázott és az esethez mérten elégséges hosszra korlátozott jelszó.
Mi értelme lenne például azzal kínozni egy új felhasználót, hogy a telefonon keresztül bediktálva egy 30 vegyes karakteres jelszót kell leírnia a belépéshez? Ugyanez a helyzet minden olyan esetben, amikor az általam előállított jelszót más vagy mások is használják.
Ha azt nem érted, hogy miért kell a keylen, minchar, maxchar, ha van format, akkor annak az a magyarázata, hogy korábbi változatban még nem volt format.
Mert az eloallitott hash ("jelszo") utana copypaste-tel bekerul a netbank, vagy akarmi jelszo mezojebe, ahol a legtobb helyen olyan szabalyoknak kell megfelelni, hogy a jelszo csak 9 vagy 11 karakteres lehet, de 11 karakteres csak akkor, ha nagybetuvel vagy paros szammal kezdodik, meg a tobbi marhasag, amit valahol a rendszer melyen rejtozo legacy foshalom cleartext-jelszokezelese miatt implementalni kellett.
Meg is valósítottam ezt (akinek kell, ellenőrzésből vagy bármi célból, bemásolom a pár soros forrást is ide majd).
Üres jelszó:
string(128) "05ae03fd135de159cc512d0a34317d0c5270fc9d0c02ebc648828dec221272d8f20f83485bb16d0dc58acbc4a84ccc8363ef7413885936c8ee7cc943ef65cbd1"
"a" jelszó:
string(128) "0c03febb9f7f98271b9b646c8770f532ef601997bd3b3735c885cd260111342c1761b1cc93f5b608d8f8d02847f779000616a11c26694cd5183ddcccbc41ccc9"
"b" jelszó:
string(128) "ee7caefa8737a9641b6b398ca66c312ca96ea755801687cbbf7ac5742cd3453d0c523b66ff9fbb6a12441c5ebc05213001bffeef2a218b75e26f2bc1cfdb2412"
"9gVgbfFeyCeTxGKNcJkwLn7Jrot80GGZGrdPNh7FdnhuD2TY9y" jelszó:
string(128) "9fd350473d3e7d38cc9fd22397aa531cf0a25d16223b99b5869ae0c26ecf5e3d86b069d086d70fae3f25f2a787ab0950143e18a50a81d57c13a0b0a87d4c163e"
Minden úgy működik, ahogy várható volt.
sha3-512 értéke üres érték esetén, ami egyezik a wikipedia oldalon lévővel:
string(128) "a69f73cca23a9ac5c8b567dc185a756e97c982164fe25859e0d1dcc1475c80a615b2123af1f5f94c11e3e9402c3ac558f500199d95b6d3e301758586281dcd26"
Aki használt már ilyet, az ezekben semmi meglepőt nem lát és feleslegesnek tűnik ezt iderakni. Mégis azért tettem ide, hogy legyen egy példával rendelkező alap, amivel összehasonlítjuk ng123 fejlesztését.
A sha3-512 esetén is, mint a többi hasonló algo alapján elmondható, hogy az avalanche effect miatt 1 karakter módosítás egy teljesen más karakterhasználatot eredményez.
Mivel a fenti példában több sha3-512 van egymásba ágyazva, így nem csak 1 karakter eltérés lesz, nyilván ugyanúgy más lesz az avalanche effect miatt, mindegy, hogy hány karakter az eltérés.
Most, hogy ez itt van, érdemes lenne az ng123 algot is kipróbálni egy fix, ismert értékekkel beállított konfigurációs fájl (és lementett/portable backup kulcsok publikálása, megosztása) esetén, ha ez a 4 fenti bemenet van, bár az üres jelszót nem fogja engedni, akkor 3 marad.
Még ha látunk is majd 3 különböző sztringet, az sem jelent majd semmit, csak már egy lépéssel közelebb leszünk, hogy kiderüljön a működés.
ng123: tudnál ebben segíteni, hogy beállítod úgy, ahogy szerinted jó? Megosztod a lementett konfig fájlt és a kulcs mentéseket (és minden, ami egyedi, vagy kell, hogy másik gépen is használható legyen), majd lefuttatod: "a", "b", és "9gVgbfFeyCeTxGKNcJkwLn7Jrot80GGZGrdPNh7FdnhuD2TY9y" jelszavak esetén, hogy mi a kimenete a programodnak? A cél azt reprodukálni, hogy valaki egy új számítógépen használni akarja, és azonos kimenetet szeretne kapni a megadott jelszava használata esetén, egyedi konfigurációs fájl esetén.
bzt írta: "de talán még a kvantuumgépek ellen is véd"
Én ezt "talán" résszel sem mondanám, mert nem ismerem a kvantumszámítógépek működését, teljesítményét.
konfig fájl:
influencer=keylen:30, key1:_ tudnál ebben segíteni, key2:_hogy beállítod úgy, key3:_ahogy szerinted jó?, key4:_Megosztod a lementett konfig fájlt
------------------------------------------
1. üres jelszó:
LIi>Y^D:7$`Yw4Kr*<.ELw.8)G@ckZ
2. "a" jelszó:
\@(MNGIKQ6C`[:>#n+"rj_G+/xC'>>
3. "b" jelszó:
Vs&"[JzyKW>RlW\4bO0N$IuLUyeBm6
4: "9gVgbfFeyCeTxGKNcJkwLn7Jrot80GGZGrdPNh7FdnhuD2TY9y" jelszó:
fB8ny!)kyS1dz,L=`]uzkf<aaVmR'[
Remélem jól értettem mit kell csinálnom.
Kíváncsian várom mit hozol ki belőle.
Igen, jól értetted, köszi. Jön a következő lépés.
Gyors vizsgálat a fentiek alapján:
30 byte hosszú érték lett az üres, 1 karakteres és 64 karakteres jelszóból is. (Mint egy hash esetén.)
A 4*30=120 karakterben összesen 69 féle karakter volt A leggyakoribb karakter 5 alkalommal fordult elő: ">", míg például a "=" csak 1 alkalommal.
Ha feltételezem, hogy az ABC összes betűjét felhasználja a program, akkor 26 (kisbetű) + 26 (nagybetű) + számok (10) valamint ebben a mintában 24 féle egyéb, látható karakter volt, így 86 karaktert használ legalább kimenetként ez. Azért mondom, hogy legalább, mert előfordulhat az, van még olyan látható karakter, amit használ, csak itt nem jött elő, ebben a 120 karakterben. Elsőre még a megszámolás nélkül ascii85 szabványra tippeltem, de mikor láttam a kapcsos zárójel karaktereket, akkor rájöttem, hogy nem ascii85, mert abban kapcsos zárójel van. A tipp, hogy az általad megadott 86-95 féle karakter a kimenet.
Az "a" és a "b" bemeneti jelszó esetén a jól megírt hash esetén történő avalanche effect felismerhető, tehát nagy eséllyel valamilyen létező hash kerül felhasználásra. sha2, sha3 vagy hasonló.
Az eddigiek alapján a pszeudokód, működés:
1. A bemeneti (akár üres) jelszót a key1, key2, key3 és key4 használatával valahogy összekombinálja, és egy hosszabb karaktersorozattá alakítja (string). Akár itt még kombinálja, stb.
2. Ezt a már létrejött karaktersorozatot (amiben benne van a 4 kulcs + megadott jelszó) bemenetként használja 1 vagy több hash fügvénnyel, amivel létrejön egy bináris kimenet, ami így még nem lenne jó jelszónak, mert a 256 karakterből csak egy része, maximum 95 ideális jelszónak, ebből a fenti 4 jelszó példából 86 vagy több az, ami a program kimenetét adja. Ez vagy saját kód, saját karakter táblával, vagy valami kész fügvény, vagy annak a módosítása.
3. Valamilyen módon (erre egészen sok számítás lehetséges) az előző pontban létrejött bináris kimenetből létrejön ez a 86 vagy akár 95 karaktereket használó jelszó. A hosszúsága le lesz vágva 30 karakternél, a beállítás szerint.
Lehetne még vizsgálni, hogy miként változik a jelszó, ha 30 helyett 29 vagy 31 karaktert adok meg mint az elvárt keylen. Vagy ha 1 vagy 2 helyen módosítom a key1-4 közül valamit, vagy felcserélem a key sorrendet vagy a jelszót a keyN értékével. Stb.
Ezek közül melyik az, amit eltaláltam, és melyik az, amit nem? Jöhet a következő lépés, kérdés? Én előbb érteni szeretném. Köszi.
A kimenetet a konfig fájl alábbi részei határozzák meg:
# format:num-num/chr, [default=no format]
# num=2...5 (3-3; 3*5; 4x3; 5x2; ... )
# chr (optional)=1aB,aBc,ABC,abc,123 [default=1aB]
# minchar:number, [default=0x21='!']
# maxchar:number, [default=0x7a='z']
# keylen:number, (length of the generated keys [default=16])
# key1/4:_yourkeys, (this are parameter for keygen algorithm)
Az adott beállításba csak a keylen:30 szerepelt. Minden más a default érték. Karakterkészlet: 0x21...0x7a.
A keylen maximum 30 lehet.
Minden változtatás teljesen más kimenetet fog adni.
A lényeg nem is igazán ez (de ez is), hanem az, hogy melőtt újabb sha-t hívnál rá, "megsózod". Emiatt válik lehetetlenné a rainbow hashing támadás rá.
Még nem merültem el én sem a témában, de azért követem az eseményeket.
Az biztos, hogy már léteznek olyan hash eljárások, amik még elméletileg sem törhetők kvantuumgépekkel, és az is biztos, hogy hiába növelik a qbitek számát, egyelőre még ott tart a dolog, hogy csak fix bemenetű prímszámfaktorizációt sikerült elvégeztetni (nem egy tetszőlegest, hanem konkrétan fix bemenetre írták meg a programot, azaz az RSA törés még legalább több évtizedre van, ha nem évszázadnyira. Míg a 15 faktorizáláshoz 4 qbitre volt szükségük, addig a 376289 felbontásához már 92-re, szóval nem is fog ez működni még a már rég elavult 1024 bites RSA kulcsok esetén sem, hacsak nem rukkolnak elő egy jobb algoritmussal, mint a Shor-féle. Na de elkalandoztam, bocs).
Köszi ezeket. Majd ha közelebb lesz a téma, megvizsgálom ezeket a kvantumszámítógép biztos kripto hash eljárásokat. Remélhetőleg valódi megoldás lesz. Az is érdekes, hogy mitől lesz az, és a mostaniak mitől nem azok.
Azért ennek a kimenét megjegyezni nem semmi!
Amit írtam hash-t, az arra vonatkozott, hogy mindegy a jelszó hossza, az eredmény mindig ugyanolyan hosszú hash. Persze ha valaki mindenhol ugyanazt a bemenő jelszót használja rá, mert nem tudja, mi az a security domain, na akkor úgyis teljesen minden mindegy...
Annyira nem semmi, hogy tulajdonképpen meg is jegyezhetetlen. Kell hozzá egy jelszókezelő, abba kell felírni. Korábban én is csak egyszerűbb, leleményesebb jelszavakat találtam ki, és aki nagyon erős jelszót használt, generált, azt csak ilyen összeesküvés-elméletes, alufóliasisakos hülyének, meg élméleti buzgómócsingnak tekintettem. Egész addig, míg a FB-om kétszer is nem próbálták feltörni, egyre komplexebb jelszó mellett, utána be kellett látnom, hogy néha valóban kellenek ezek az ultra brutális, overkill jellegű, ágyúval verébre módszerek, ha tutira kell menni.
A hash se rossz ötlet, mint írtam. Pl. rövid jelszót vagy valami salt-tal vagy önmagában hashelni, akár rekurzívan is. Egy ilyen megoldáson is gondolkodtam, de végül ezt azért vetettem el, mert ehhez pl. ha telón akarom használni, kéne valami hash-számoló app, ami meg biztonsági kockázat, mert látszana belőle, hogy valamihez kell, meg lassabb is állandóan hash-re konvertálni, mint egy megjegyezhetetlen, valóban tökéletesen random jelszót egy jelszókezelőből kinézni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nagyon hosszú magyar szavakból, tetszőleges delimitátorokkal meg pár számmal csinálj jelszót. Egyelőre nincs magyar szótár tudtommal (annyire speciális a nyelvünk plusz kevesen vagyunk), a hosszúság a lényeg és az hogy ne szívasd magad.
Más tészta hogy minden szarba backdoort építenek így kérdéses a nehéz jelszó vs államok.
Ez se egy rossz módszer, pont ezt linkelte valaki xkcd-ről. Simán lehet akár versike, mondóka, idézet, rövid vicc, nehezítésnek lehet ecceru hejesiraschi hibbáckkal illetve átsz ótagoláso kkal is megfűszerezni, és máris ellenáll szótárazós támadásoknak is.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
ng123, elolvastam ezt a témát és az itt linkelt előző témádat is. (így a téma kapcsán az ng nekem a Not Generated rövidítés ugrott be)
Zeller írta: " a "zalgoritmus" (ami titok, mert forráskód az nincs) két bemeneti adatból kihány egy n karakteres stringet, még nem jelszógenerátort csináltál, hanem egy sózott "hash"-t, azaz gakorlatilag ha viszi valaki a bemenetet (ami nem a jelszó ugye...), meg a programodat, akkor megvan a jelszóként használt string"
Remélem nem sértem meg a szabadalmadat, ha erről írok. Jól értem, hogy az a lényeg, hogy egy konfigurációs fájlban paraméterek vannak, ami alapján dolgozik a jelszó generátor. Majd amit a felhasználó megad jelszót, akkor a jelszó generátor az konfigurációs fájlban lévő paraméterek és szabályok szerint hosszabb, mindig azonos karakterekké alakítja, generálja?
Ha a "biztonságos" szó a felhasználó jelszava, majd akár a működéstől és a fájlban megadott paraméterek alapján előállítja a "9gVgbfFeyCeTxGKNcJkwLn7Jrot80GGZGrdPNh7FdnhuD2TY9y" jelszót, és ezzel a konfigurációs fájl esetén mindig ezt? Véletlenszerű működés nélkül?
Ha elveszne ez a konfigiurációs fájl, és nem tudnám, miket írtam a konfigurácós fájlba, hiába tudom a "biztonságos" jelszót, nem fog létrejönni a hiányzó beállítások miatt soha a "9gVgbfFeyCeTxGKNcJkwLn7Jrot80GGZGrdPNh7FdnhuD2TY9y" jelszó?
Lenne több lépésem, de az alapvető működést szeretném első körben érteni. Köszi.
ng=Nagy Gábor
Amit zeller ír, azt felejtsük el. Nekem úgy tűnik, te jobban érted, mit csinál.
"ezzel a konfigurációs fájl esetén mindig ezt? Véletlenszerű működés nélkül?" Igen
"Ha elveszne ez a konfigiurációs fájl, és nem tudnám, miket írtam a konfigurácós fájlba, hiába tudom a "biztonságos" jelszót, nem fog létrejönni a hiányzó beállítások miatt soha a "9gVgbfFeyCeTxGKNcJkwLn7Jrot80GGZGrdPNh7FdnhuD2TY9y" jelszó?"
Igen, ezért van az import/export és a PORTABLE=1/0 lehetőség + a konfig fájl jelszóvédelme. Vagyis mindenki csinálhat biztonsági másolatot.
És ezért van a key1...4-re vonatkozó jelszóellenőrzési lehetőség a programban. A kulcsokat ugyanis senki nem tudja visszaolvasni, de ellenőrizheti, hogy emlékszik-e még rájuk.
A zárt, nem publikus forrású/nem auditált kódot felejtsük el.
Most miért? Nagy Gábor azt mondja biztonságos és erős. Kell ennél több?
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @
Meleg víz feltalálása akar lenni ez itt, csak nem lett meleg se. :)
Csináltál a securerandom + base64 (vagy akármi kódolás) helyett egy jóval gyengébb dolgot.
- Ha nem alkalmazol megfelelő minőségű véletlenszám forrásból, megfelelő mennyiségű számot a jelszó generálása során, akkor nagyon sok ütközés lesz a generált kiementben -> gyengül a biztonság.
- A felhasználó által megadott szabályok tovább gyengítik az előbbit, mert azok mindig korlátozni fogják a lehetséges kiementeket -> gyengül a biztonság.
"nagyon sok ütközés lesz a generált kiementben -> gyengül a biztonság."
Megneveznél egy számot?
Ha csinálok egy tesztet, hogy egy milliárd generált jelszóból hány egyforma van, mennyi lesz az a nagyon sok ütközés?
Ha megmutatod az algoritmust, akkor egyszerűbb lesz a matekját átnézni...
a biztonságosság feltétele a nyílt forrásúság. nem a garanciája, de feltétele.
ha meg mégse olyan biztonságos, mint amilyennek képzeled, akkor mehet feléd a károkból adódó per?
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
A biztonság feltétele a felelősségteljes fejlesztés. Ez itt hiányzik. Poli jut eszembe róla, meg a Furor (ami attól lett Turing teljes nyelv, hogy be tudott hívni C libeket).
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @